Seit Leap 15 wird ext4 von Fremdsoftware nicht mehr erkannt

Hinweis: In dem Thema Seit Leap 15 wird ext4 von Fremdsoftware nicht mehr erkannt gibt es 27 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • An ext4 wurde ein wenig rumgeschraubt, da ein kleiner, scheinbar uralter Bug aufgetaucht ist.


    Ob neuere Versionen von Paragon das können, weiß ich nicht. Ich setze sowas nicht ein.

    Da ist etwas daran.
    Vor etwa 10 Jahren habe ich mit einem veralteten Programm ein System (nicht meins) zerschossen.
    Ich sollte unbedingt sein veraltetes Win Programm nutzen. Es war mir eine Lehre.
    Wer heute so etwas möchte soll in den Computerladen gehen und dafür bezahlen.


    Meine Hilfe für Freunde ist nicht umsonst aber kostenlos, weil ich alles mit Opensource mache.

    Für den Inhalt des Beitrages 127666 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Wenn ein fschk keine Fehler meldet, brauchst du nichts weiter zu tun.
    Das Ding läuft dann, genau so stabil oder instabil, wie ohne dieses fragwürdige Programm.


    Das einzige, was du wirklich machen könntest, ist deine eigenwillige Einstellung dazu zu überdenken.
    Es ist nicht sonderlich sinnvoll ein altes Programm, das proprietär ist, einzusetzen, weil man es nicht zahlen musste und es einem schneller erscheint.
    Irgendwann wird es dir gar nichts mehr nutzen. Je früher du es in die Tonne trittst, desto gut.


    Der Zweck, warum du das tust, ist mir nicht so ganz klar.
    Du scheinst keinen Unterschied zwischen Backup und schneller Systemwiederherstellung zu machen.
    Ich meine jedenfalls, dass du das mit den jeweilig dafür zuständigen Linuxprogrammen mindestens genauso schnell machen könntest.
    Fordert halt ein wenig mehr Gepfriemel anfangs.

  • Nun, ganz so ist es nicht.


    Ich halte schon Ausschau nach einer vergleichbaren Linux-Lösung, habe aber bislang nichts wirklich Gleichwertiges/Funktionierendes gefunden. Auch unterscheide ich zwischen Systemsicherung/-wiederherstellung und der Datensicherung. /home sichere ich zyklisch online mittels rdiff-backup auf unterschiedlichen Medien. Den Rest halt mit diesem Tool und der Sicherungsvorgang braucht knapp 1,5 Minuten. Diese Zeit brauche ich bei Clonezilla allein für die Vorgabe, was zu tun ist ... Ein Restore ist ebenso schnell.


    Ich sichere das System oft, immer wenn sich etwas ändert. Mit dieser Strategie habe ich bisher jede Situation bewältigen können, die mich das System nicht mehr booten oder sinnvoll bedienen ließ. Sowas war zwar selten in den letzten Jahren, hat mir dann aber komfortabel den Hintern gerettet.


    Evtl. kämen noch snapshots in Frage, aber dafür müsste ich zu btrfs wechseln und das möchte ich eigentlich nicht tun. Die jetzige Lösung ist schnell und ressourcenschonend und ich weiß bei jedem gesicherten Stand genau, was ich da habe.

  • Ich weiß nicht, was du da machst, aber 1,5 Minuten um eine ganze Partition zu klonen?
    Mag möglich sein, wenn die nicht größer als ein paar MB ist.
    Und bei einem Restore halte ich diese Zeit erst recht für ausgeschlossen.


    Wenn Paragon das differentiell macht, dann wäre wohl ein modernes Backup Programm sinnvoller.
    Keine Software kann "schneller" sein, als es die Hardware erlaubt. Und moderne Linuxprogramme nutzen die Hardware schon sehr effizient.


    Aber, wie du meinst...
    So wirklich verstehe ich weder was du wirklich da tatsächlich treibst, noch, was das für einen Nutzen haben soll. Zumal für mich die Dauer eines Backups völlig egal ist. Läuft so oder so vollautomatisch im Hintergrund.

  • Ich weiß nicht, was du da machst, aber 1,5 Minuten um eine ganze Partition zu klonen?
    Mag möglich sein, wenn die nicht größer als ein paar MB ist.

    Das ist kein klonen. es werden nur die belegten Sektoren im Imagefile hinterlegt. TrueImage, Paragon und alle anderen Anbieter von Idiesen Backup&Restore-Tools machen dasselbe.


    def -h
    liefert u. a. das hier:
    /dev/sda2 59G 11G 46G 19% /


    Das ist schon etwas mehr als ein paar MB. Quell- und Zielmedium sind zwei SSD.
    Und was die Ausführungs-Zeiten in beiden Richtungen angeht: btdtgt
    Ich kann nicht nachvollziehen, wieso meine Angaben hier derart angezweifelt werden, ich habe mir die nicht ausgedacht!


    Und da ich - wie beschrieben - damit offline sichere, ist da kein Hintergrund, in dem etwas läuft. Insofern ist Schnelligkeit durchaus ein Thema. Dafür kann ich einen Systemstand aber auch blitzschnell restaurieren. Ganz ohne überhaupt ein System zu haben, dass ich booten muss. Wie restaurierst du ein System, das irgendwie online gesichert wurde, das sich aber nicht mehr booten lässt? Dann musst du ein anderes System (ein Live-System?) booten und das Dateisystem wieder neu aufbauen. Sicher, kann man machen.


    Aber ein Image zu laden geht deutlich fixer, besonders, wenn an mal etwas ausprobieren will und das evtl. mehrmal tun muss. Und ich kann so ein Image-Archiv einfach zusätzlich auf externe Datenträger vervielfältigen (wo ich eine Kopie von /home habe), die ich bequem auswärts aufbewahren kann, z. N. im Bankschließfach oder der Zweitwohnung. Damit bin ich auch für den worst case ziemlich gut vorbereitet.


    In alten Windows-Tagen habe ich auch die Datenlaufwerke stets so in Images gesichert, da geht das ohnehin schon immer online und im Hintergrund. Seitdem ich so verfahre (15 Jahre?), hatte ich nie einen Datenverlust zu beklagen. Bei rdiff-backup hingegen kommt es gelegentlich schon zu Unpässlichkeiten, vielleicht weil der Rechner ausfiel während eines Sicherungslaufes. Darum mache ich das alle 20 Minuten auf je einer anderen Platte nebenbei. Hin und wieder zur Sicherheit als Image wieder offline mit dem FM15. Das läuft dann für


    /dev/sdc1 443G 229G 214G 52% /home


    in ca. 20 Minuten durch, da ist das Ziel dann keine SSD. Das Ergebnis davon könnte auch inkrementell ergänzt werden, aber das praktiziere ich derzeit nicht.

  • Ich hatte schon mehrfach geschrieben: Ist deine Wahl.
    Dass ich den gnadenlosen Geschwindigkeitsvorteil weder glaube, noch für nötig halte, sei mir aber bitte doch auch unbenommen.


    Außerdem würde ich einer Backup/ISO - Restore Lösung, die keine normale Linux- Formatierung erkennt, niemals trauen.
    Für den Ernstfall schon gar nicht.


    Der Unterschied mag darin liegen, dass meine Server nicht bei mir im Wohnzimmer stehen, sondern in einem Rechenzentrum, auf das ich schon aufgrund der Entfernung keinen Zugriff habe. Komplett remote unter Kontrolle, oder gar nicht.


    Mag ja sein, dass du damit trotzdem recht hast. Wie gesagt: Ich kenne und verwende Paragon nicht.
    Nur meine open source Lösung dauert beim täglichen Backup grade mal 5 Minuten und wird auf dem Server selbst und auf zwei weiteren Kisten gespeichert. Dabei vollständig dedupliziert und verschlüsselt. Und es ist mir dennoch völlig egal, wie lange das dauert.


    Wie heißt es so schön: Your mileage may vary.

  • Ich hatte schon mehrfach geschrieben: Ist deine Wahl.
    Dass ich den gnadenlosen Geschwindigkeitsvorteil weder glaube, noch für nötig halte, sei mir aber bitte doch auch unbenommen.


    Außerdem würde ich einer Backup/ISO - Restore Lösung, die keine normale Linux- Formatierung erkennt, niemals trauen.
    Für den Ernstfall schon gar nicht.

    Etwas nicht für nötig halten, ist eine Sache. Einem nicht zu glauben eine andere. Ich bin gerne bereit, es live zu demonstrieren ... eine Flasche Wein ist immer im Keller ... Den Ernstfall habe ich mehrfach erprobt und überwunden.


    Und bis vor 2 Wochen unter Leap 42.3 gab es dieses Problem nicht. Und bei allen anderen Vorgänger-Versionen bis zur 13.2 garantiert auch nicht. Es ist erst mit Leap 15 aufgetaucht. Mit dem 4.12er Kernel und bevor das jüngst in den Medien beschrieben ext4-Problem diskutiert wurde (ich habe eine Weile Leap 15 und Leap 42.3 parallel vorgrhalten). Mit den Patches dazu kann es also auch nicht zu tun haben.


    Ich gehe inzwischen davon aus, dass irgendein Verwaltungsbit/Statusbyte/bisher unbenutztes Bit/Byte einen Zustand bekommen hat, den es so bislang nicht gab oder so nicht benutzt wurde und deshalb zu einer falschen Interpretation führt. Sogar diesen Zustand kann ich sichern, ich muss in den Einstellungen dann vorgeben, jeden Sektor ins Image aufzunehmen. Ja, habe ich ausprobiert, klappt. Auch der Restore klappt. Dauert dann halt 5-6 Minuten.


    Am 3.7-Kernel des Bootsticks liegt es auch nicht, das habe ich inzwischen herausgefunden, in dem ich dafür den aktuellen 4.19er der openSUSE unterjubelte, was zu meiner Verblüffung sogar ganz gut klappte. Auch dann wird ein ext4-FS des Leap-15-Partionierer als unformatiert angesehen.

  • Ich glaube dir sehr wohl. Sogar von Anfang an.


    Aber ich bezweifle, dass die Methode schneller als alle anderen wäre.
    Magst ja recht haben, ich zweifle dennoch.


    Letztlich kommt es halt auf den Zweck an.
    Dir ist eine schnelle Sicherung im Vordergrund wichtig, die mir völlig egal ist.
    Auf meinem Server, der weit entfernt in einem RZ steht, hätte ich mit deiner Methode eher keine Chance.
    Und würde ich den mit deiner Methode restoren, würde das sicher wesentlich länger dauern,
    als mit meinen Backups. Ich müsste dann ja den kompletten Sektortransfer erst über das Netz vollenden, während ich bei meinem Restore die einzelnen Serverdienste schon wieder online schalten kann, obwohl er mit dem Backup- einspielen noch gar nicht fertig ist.
    Aber egal.


    Nochmal:
    Mach' ruhig zu. Ist dein Ding. Nicht meines.

  • Dann mach bei Paragon nen Bugreport auf.

    Ich denke aber, das Problem liegt bei openSUSE, nicht bei Paragon. Soeben habe ich GParted (0.31.0-lp150.1.2) aus dem Leap-Repository installiert und damit ein ext4-fs erzeugt. Und siehe da, das wird vom Paragon-Tool auch richtig erkannt. Zustand, Füllungsgrad, Partitionsgrenzen, alles i. O.


    Das Problem taucht ausschließlich im Umgang mit dem Leap15-Partitionierer auf. Da ist m. E. openSUSE als erster Ansprechpartner zuständig.