Datenrettung eines Btrfs-Filesystems auf einem Raid 5

Hinweis: In dem Thema Datenrettung eines Btrfs-Filesystems auf einem Raid 5 gibt es 3 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.

    Ein Raid 5 mit 4 Partitionen (jede 1 TB groß, so dass der effektive Speicher des Raids insgesamt 3 TB ergab). welches ich vor längerer Zeit in OpenSUSE 15.??? (evtl auch in Thunderbold) mit YaST2 angelegt habe, habe ich seinerzeit ebenfalls mit Yast2 ein BtrFS über den kompletten zur Verfügung stehenden Speicher angelegt.

    Nachem kürzlich die Partition sdd1 ausfiel, konnte ich zu Anfang das FS noch einmal mounten, danach ging plötzlich nichts mehr.

    Ich habe dann dummerweise das Raid mit Hilfe von mdadm gestoppt.

    Ein Versuch, dieses mit Hilfe von

    Code
    mdadm --create /dev/md0 --level=5 --raid-devices=4 --chunk=128 /dev/sda1 /dev/sdb1 /dev/sdc1 missing --assume-clean

    wiederherzustellen, führte dazu, dass das BtrFS nicht mehr ansprechbar war.

    btrfsck scheiterte, da kein Superblock gefunden wurde. Auch der Versuch, den Superblock in einer der anderen beiden möglichen Positionen zu entecken (z.B.:)

    Code
    btrfs inspect-internal dump-super -s 1 /dev/sda1

    führte zu keinem Erfolg.

    Die Suche mit Hilfe von wxHexEditor nach der Signatur

    Code
    _BHRfS_M

    führt dazu, dass ich an den Positionen 0x1.000.000 und 0x1.000.000.000 die einzigen Stellen auf sda1 finden konnte, die die Signatur enthalten.

    Ich erhalte folgende Ausgabe durch:

    Die Untersuchung an der Position 0x1.000.000.000 zeigte ereartungsgemäß die folgenden Unterschieden:

    Der 2. Superblock sollte jedoch bei einem Raid 5 aus 4 Partitionen an der Stelle 1.400.000.000 liegen, damit er nach dem Zusammenbau des Raids an der gewünschten Position 0x4.000.000.000 zu liegen kommt (Ähnlich für den 3. Superblock).

    An diesen Stelle finde ich jedoch mit wxHexEditor nichts Brauchbares.

    Was muss ich beim neu zusammenbauen des Raid 5 aus den drei intakten Partitionen anders machen, damit die noch vorhandenen intakten Superblöcke an den zu erwartenden Positionen auftauchen?


    Ich bin für jede Hilfe dankbar.

    Für den Inhalt des Beitrages 320625 haftet ausdrücklich der jeweilige Autor: rebzdu

    Zuerst einmal eine Krrektur. Im btrefs-Befehl musste es natürlich sda1 und nicht md0 heißen, wie auch beim diff-Befehl korrekt angegeben.


    Mittlerweile habe ich zumindest eine kleinen Fortschritt gemacht.


    Durch Untersuchung langer ASCII-Folgen mittels


    Code
    strings -a -n 30 /dev/sda1

    und entsprechend auch für sb1 und sc1 habe ich herausgefunden, dass der Bereich 0x40000-0x2dff00 unterschiedlichen fortlaufenden ASCII-Text enthält, der nicht durch Paritätsberechnung zu Stande gekommen sein kann. Somit muss zumindest dieser Bereich aus sdd1 die Paritätsinformation enthalten. Der Bereich ist über 2,6 MB groß, also meine Chung-Größe mindestens 4 MB groß sein.

    Die beiden Chunk-Größe von 8 MB und 16 MB führen nun dazu, dass der Superblock, der auf sda1 an der Stelle 0x1.000.000 liegt, im Raid 5 mit 4 Platten an der Stelle 0x4.000.000 landet. Dies ist die gewünschte Lage des 2. Superblocks. Dies sind die beiden einzigen Chunk-Größen.

    Dadurch liefert der Befehl

    Code
    btrfs inspect-internal dump-super -s 1 -f /dev/md0

    bei einer Chungk-Größe von 8 MB (oder auch 16 MB) die folgende, aus meiner Sicht brauchbare Ausgabe,

    wobei ich bei den durch die Option -f erzeugten zusätzlichen Ausgaben von

    sys_chunk_array[2048]:

    und

    backup_roots[4]:

    nicht weiß, ob diese sinnvoll sind und ob ich aus obiger Ausgabe nähere Angaben über die korrekte Chunk-Größe ablesen kann.

    Jedoch habe ich kein Glück mit dem zweiten gefundenen Vorkommen des 3. Superblocks auf der Partition sda1 an der Stelle 0x1.000.000.000.

    Diese landet im Raid sowohl bei einer Chunk-Größe von 8 Mb als auch bei 16 MB an der Stelle 0x3.000.000.000 und nicht bei 0x4.000.000.000


    Weiß jemand, wo u.U. im Quelltext von YaST die Erstellung eines Software-Raids zu finden ist, damit ich in den älteren Leap-Versionen möglicherweise fündig werde?


    Ich bin weiterhin für jeden Tipp dankbar, der mir weiterhelfen könnte.

    Für den Inhalt des Beitrages 320796 haftet ausdrücklich der jeweilige Autor: rebzdu

    Nach reiflicher Überlegung bin ich zu der Überzeugung gekommen, dass der durch Text gefüllte Bereich von 0x40000-0x2dff00 auf den Partitionen sda1, sdb1 und sdc1 nachträglich zu Stande gekommen ist und diese drei Partitionen überschrieben haben muss (es scheinen Fehlermeldungen von wine zu sein, da alle Zeilen die Form

    Code
     [0620/175715.803:ERROR:exception_handler_server.cc(524)] ConnectNamedPipe: Ungültiges handle

    haben), so dass die ursprünglichen Daten verloren gegangen sind, denn an der Stelle 0x40000 steht ja die erste Kopie des Superblocks des Raid 5. Somit muss ich jetzt versuchen, die ursprüngliche Chunk-Größe anderweitig zu ermitteln.

    Für den Inhalt des Beitrages 320825 haftet ausdrücklich der jeweilige Autor: rebzdu