Datenrettung eines Btrfs-Filesystems auf einem Raid 5

Hinweis: In dem Thema Datenrettung eines Btrfs-Filesystems auf einem Raid 5 gibt es 7 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Ich habe mein Problem ursprünglich in der Gruppe

    Server

    geschildert, bin aber zu der Überzeugung gekommen, dass mein Problem in dieser Gruppe besser aufgehoben ist. Zudem habe ich neue Erkenntnisse gewonnen, die ich im Folgenden schildern möchte.

    Nachdem eine Partition eines Raid 5, welches ich in YaST 2 erstellt und mit BTRFS formatiert habe, ausgefallen ist, versuche ich dieses FS wieder ans Laufen zu bekommen.

    Das Raid besteht aus 4 Platten der Größe 1TB.

    Meine Analyse ergab foldendes:

    Wenn ich das Raid durch

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

    neu zusammenbaue, wird der Superblock an den Stellen 0x10.000, 0x4.000.000 und 0x4.000.000.000 nicht gefunden. Mein Versuche, dies duurch geschickt gewählte Chunk-Größen in Ordnung zu bringen, habe ich bereits in der Server-Gruppe geschildert.

    Ich stellte dann mittels

    Code
    mdam -add /dev/md0 /dev/sdd1

    die verlorengegangene Partition wieder her, jedoch scheiterte auch der Versuch, die Chunk-Größe dadurch herauszufinden, dass ich untersuche, wo ASCII-Text oder z.T. leere Blöcke nebeneinander lagen, um zu sehen, an welchen Positionen die durch XOR entstandenen Paritätsblöcke liegen könnten. Es kam immer nur heraus, dass es die neu hinzugefügte Partition sdd1 sein muss.

    Dann hatte ich Glück, dass in der ältesten noch gespeicherten Log-Datei von Yast2 der folgende Eintrag zu finden war:

    Da die Info zu lang ist, muss ich ein zweiteiliges Posting daraus machen.

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

  • Fortsetzung:

    Merkwürdigerweise war dies ein Raid 0, ich war allerdings der festen Überzeugung, in Yast2 ein Raid 5 erstellt zu haben.


    Im Ordner

    Code
    /home/bz/crash/YaST-log/yast-installation-logs/YaST2/storage-inst/

    konnte ich eine weiter Information finden:

    Code
    - md:    name: "/dev/md/md0"    md_level: raid0    md_parity: default    chunk_size: 64 KiB    md_uuid: ccfbb85f:5730a070:74cd0dee:e323dd90    in_etc_mdadm: false    metadata: '1.0'    file_system: btrfs    btrfs:      subvolumes:      - subvolume:          path: ".snapshots"      - subvolume:          path: ".snapshots/1/snapshot"      - subvolume:          path: ".snapshots/2/snapshot"      - subvolume:          path: ".snapshots/2251/snapshot"      - subvolume:          path: ".snapshots/3036/snapshot"      - subvolume:          path: ".snapshots/3642/snapshot"      - subvolume:          path: ".snapshots/4370/snapshot"      - subvolume:          path: ".snapshots/5202/snapshot"      - subvolume:          path: ".snapshots/5979/snapshot"      - subvolume:          path: ".snapshots/6779/snapshot"      - subvolume:          path: ".snapshots/7529/snapshot"      - subvolume:          path: ".snapshots/7667/snapshot"      - subvolume:          path: ".snapshots/7668/snapshot"      - subvolume:          path: ".snapshots/7700/snapshot"      - subvolume:          path: ".snapshots/7701/snapshot"      - subvolume:          path: ".snapshots/7776/snapshot"      - subvolume:          path: ".snapshots/7777/snapshot"      - subvolume:          path: ".snapshots/7846/snapshot"      - subvolume:          path: ".snapshots/7847/snapshot"      - subvolume:          path: ".snapshots/7940/snapshot"      - subvolume:          path: ".snapshots/7941/snapshot"      - subvolume:          path: ".snapshots/7967/snapshot"      - subvolume:          path: ".snapshots/7968/snapshot"      - subvolume:          path: ".snapshots/8124/snapshot"      - subvolume:          path: ".snapshots/8125/snapshot"      - subvolume:          path: ".snapshots/8293/snapshot"      - subvolume:          path: ".snapshots/8294/snapshot"      - subvolume:          path: ".snapshots/8295/snapshot"      - subvolume:          path: ".snapshots/8719/snapshot"      - subvolume:          path: ".snapshots/8720/snapshot"      - subvolume:          path: ".snapshots/8721/snapshot"      - subvolume:          path: ".snapshots/8722/snapshot"      - subvolume:          path: ".snapshots/8776/snapshot"      - subvolume:          path: ".snapshots/8777/snapshot"      - subvolume:          path: ".snapshots/8827/snapshot"      - subvolume:          path: ".snapshots/8828/snapshot"      - subvolume:          path: ".snapshots/8869/snapshot"      - subvolume:          path: ".snapshots/8870/snapshot"      - subvolume:          path: ".snapshots/8950/snapshot"      - subvolume:          path: ".snapshots/8951/snapshot"      - subvolume:          path: ".snapshots/9002/snapshot"      - subvolume:          path: ".snapshots/9003/snapshot"      - subvolume:          path: ".snapshots/9044/snapshot"      - subvolume:          path: ".snapshots/9045/snapshot"      - subvolume:          path: ".snapshots/9055/snapshot"      - subvolume:          path: ".snapshots/9143/snapshot"      - subvolume:          path: ".snapshots/9144/snapshot"      - subvolume:          path: ".snapshots/9248/snapshot"      - subvolume:          path: ".snapshots/9249/snapshot"      - subvolume:          path: ".snapshots/9251/snapshot"      - subvolume:          path: ".snapshots/9252/snapshot"      - subvolume:          path: ".snapshots/9328/snapshot"      - subvolume:          path: ".snapshots/9329/snapshot"      - subvolume:          path: ".snapshots/9428/snapshot"      - subvolume:          path: ".snapshots/9429/snapshot"      - subvolume:          path: ".snapshots/9516/snapshot"      - subvolume:          path: ".snapshots/9517/snapshot"      - subvolume:          path: ".snapshots/9526/snapshot"      - subvolume:          path: ".snapshots/9527/snapshot"      - subvolume:          path: ".snapshots/9529/snapshot"      - subvolume:          path: ".snapshots/9553/snapshot"      - subvolume:          path: ".snapshots/9577/snapshot"      - subvolume:          path: ".snapshots/9590/snapshot"      - subvolume:          path: ".snapshots/9591/snapshot"      - subvolume:          path: ".snapshots/9603/snapshot"      - subvolume:          path: ".snapshots/9627/snapshot"      - subvolume:          path: ".snapshots/9651/snapshot"      - subvolume:          path: ".snapshots/9675/snapshot"      - subvolume:          path: ".snapshots/9676/snapshot"      - subvolume:          path: ".snapshots/9677/snapshot"      - subvolume:          path: ".snapshots/9701/snapshot"      - subvolume:          path: ".snapshots/9725/snapshot"      - subvolume:          path: ".snapshots/9749/snapshot"      - subvolume:          path: ".snapshots/9752/snapshot"      - subvolume:          path: ".snapshots/9753/snapshot"      - subvolume:          path: ".snapshots/9754/snapshot"      - subvolume:          path: ".snapshots/9755/snapshot"      - subvolume:          path: ".snapshots/9756/snapshot"      - subvolume:          path: ".snapshots/9757/snapshot"      - subvolume:          path: ".snapshots/9758/snapshot"      - subvolume:          path: ".snapshots/9759/snapshot"      - subvolume:          path: ".snapshots/9760/snapshot"      - subvolume:          path: ".snapshots/9761/snapshot"      - subvolume:          path: ".snapshots/9762/snapshot"      - subvolume:          path: ".snapshots/9763/snapshot"      - subvolume:          path: ".snapshots/9764/snapshot"      - subvolume:          path: ".snapshots/9765/snapshot"      - subvolume:          path: ".snapshots/9766/snapshot"      - subvolume:          path: ".snapshots/9767/snapshot"      - subvolume:          path: ".snapshots/9768/snapshot"    md_devices:    - md_device:        blk_device: "/dev/sda1"    - md_device:        blk_device: "/dev/sdb1"    - md_device:        blk_device: "/dev/sdc1"    - md_device:        blk_device: "/dev/sdd1"

    Ich kann nicht beurteilen, in wie weit dies bei der Reparatur hilfreich ist.


    Nachdem ich nun das Raid neu durch

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

    (Die Angabe

    "missing"

    anstelle der 4. Partition führe zu der Fehlermeldung:

    mdadm: This level does not support missing devices


    ) neu zusammengebaut habe, führte dazu, dass die Untersuchungen

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

    und

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

    erfolgreich waren, die Ausgaben sind die selben, die ich bereits in der Gruppe Server gepostet habe.

    Der Versuch, mittels btrfsck eine Reparatur durchzuführen scheitert auch, wenn ich die 1. Backup-Kope des Superblocks verwende:

    Code
    btrfsck /dev/md0
    Opening filesystem to check...
    No valid Btrfs found on /dev/md0
    
    btrfsck -s 1 /dev/md0
    using SB copy 1, bytenr 67108864
    Opening filesystem to check...
    bad tree block 26312704, bytenr mismatch, want=26312704, have=25591808
    ERROR: cannot read chunk root
    ERROR: cannot open file system

    gleiches gilt für den Versuch mit der 2. Backup-Kopie.


    Ist es noch möglich, Teile des Dateisystems wiederherzustellen?

    Welche Optionen des Kommandos btrfs sind hilfreich?


    Ich bin für jeden Tipp dankbar

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

  • Heißt jetzt, du hast kein Raid 5 sondern lediglich ein Striping-System, also Raid 0 ?

    gleiches gilt für den Versuch mit der 2. Backup-Kopie.

    damit meinst du den BTRFS-Snapshot?

    Gruß Jürgen

    Für den Inhalt des Beitrages 320866 haftet ausdrücklich der jeweilige Autor: JSC

  • Hallo JSC

    Es sieht so aus, dass es ein Raid 0 ist.


    So weit ich es verstehe, gibt es drei btrfs-Superblöcke, ein Original bei 0x10.000 und zwei Kopien bei 0x4.000.000 und 0x4.000.000.000. Bei mir sind nur die letzten beiden vorhanden.

    Angeblich soll es möglich sein, mit btrfs-select-super aus den Kopien das Original bei 0x10.000 wiederherzustellen.

    Obwohl das Kommando btrfs-select-super im Manual von btrfs aufgelistet ist, existiert dieses bei mir nicht.

    Hier die Dateiliste aus yast (aus Leap 15.6):

    Im Paket btrfsprogs ist lediglich die man-page enthalten.

    Ich habe deshalb ein Paket btrfsprogs heruntergeladen.

    Leider bricht dieses Programm mit der Fehlermeldung ab:

    Code
    ./btrfs-select-super -s 2 /dev/md0
    ERROR: cannot read chunk root
    ERROR: open ctree failed

    Liebe Grüße

    Reinhard

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

  • Bei einem Ausfall einer Platte innerhalb eines Raid0-System, das zudem noch btrfs ist, kannst du eigentlich nur noch beten, dass dein Backup, wenn du denn eines gemacht hast, zu restoren ist.

    Aber vermutlich hast du kein Backup gemacht, da du davon ausgegangen bist, das brauchst du bei einem Raid 5 nicht.

    In deinem Fall wäre ein Raid 1 wohl besser und weniger aufwändig gewesen, aber im Nachinein...

    Gruß Jürgen

    Für den Inhalt des Beitrages 320872 haftet ausdrücklich der jeweilige Autor: JSC

  • Wenn ich ein komplettes Backup hätte, würde ich diesen Aufwand nich betreiben, aber vielleicht gelingt es ja doch noch, den nicht gesicherten Teil z.T. zurückzugewinnen. Natürlich war ich bei einem Raid 5 davon ausgegangen, mit wenig Aufwand die ausgefallene Platte zu ersetzen.

    Ich bin aber enttäuscht, dass noch nicht mal das restaurieren des Superblocks gelingt. Angeblich soll doch btrfs viele Reparaturmöglichkeiten bieten.

    Zumindest läuft chunk-recover ohne Fehlermeldung durch.

    LG

    Reinhard

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

  • Hallo Reinhard,


    nur mal so als Tipp:


    Ein Backup beinhaltetet nicht nur den Knopfdruck, das Backup anzustoßen, sondern ebenfalls zu testen, ob ich die vermeintlich gesicherten Daten auch wiederherstellen kann!

  • ob ich die vermeintlich gesicherten Daten auch wiederherstellen kann!

    Backup und (hauptsächlich) Restore mus man auch üben. Ein Backup, das sich nicht wiederherstellen lässt ist kein Backup.

    Gruß Jürgen

    Für den Inhalt des Beitrages 320875 haftet ausdrücklich der jeweilige Autor: JSC