Beiträge von rebzdu

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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.

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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.

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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.

  • Datenrettung eines Btrfs-Filesystems auf einem Raid 5

    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.

  • Kdenlive startet nicht unter Tumbleweed

    Ich arbeite unter kde und hatte auch das Problem, dass kdenlive das Hauptfenster öffnete und dann nicht mehr reagierte, auch das kleine Bild, dass immer beim Programmstart erscheint und normalerweise von selbst verschwindet, musste ich erst anklicken, damit es verschwand. Das Hauptfenster reagierte aber überhaupt nicht.


    Nachdem ich über


    Code
    strace kdenlive>& kdenlivefehlerIch


    die Probleme analysierte, stellte ich fest, dass u.a die folgende Fehlermeldung auftauchte:


    Code
    openat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v3/libpulsecommon-17.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)

    Da meine Soundkart immer manuell gestartet werden muss (in YaST rausschmeißen und anschließend bearbeiten, dann mit


    Code
    pulseaudio --kill
pulseaudio --start

    evtl. mehrmals, bis das kleine Bild mit der Meldung "Simulanous Output" erscheint, habe ich pulseaudio gestartet. (Dies ist übrigens auch bei einigen anderen Programme nötig)

    Danach startete kdenlive ohne Probleme.