Verschlüsseltes RAID 5 retten

[Hagbard88]

Guten Abend,

ich habe einen kleinen Server daheim mit einer alten SuSe 9.1 Distri auf der Systemplatte und einem Software-RAID 5 aus 3 80er Platten. Dies lief auch seit fast 4 Jahren sauber durch, bis die Systemplatte gestern den Geist aufgab.

Nun versuche ich mit der Open Suse 11 Live CD das RAID zu mounten was mir aber nicht wirklich gelingt.
SuSE erkennt das RAID selbständig :

linux:~ # cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[0] sdc1[2] sdb1[1]
      156301056 blocks level 5, 128k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Nun habe ich versucht mit folgendem Befehl ein passendes Loop-Device zu erstellen, um die verschlüsselte Partition zu mounten:

losetup -e twofish256 /dev/loop0 /dev/md0

Nun stellt sich für mich die Frage ob ich evtl. durch die nachfolgende Passwortabfrage, was ja leider eher ein setzen ist, das RAID zerstört haben wenn ich das Passwort falsch gesetzt habe?

Denn ich denke dieses wäre der richtige Weg:

losetup /dev/loop0 /dev/md0

mount -t reiserfs -o encryption=twofish256 /dev/md0 /mnt
Password:
mount: /dev/loop2: can't read superblock

Doch wie ihr seht kann er wohl den superblock nicht finden ... Hat jemand ne Idee was hier passiert ist oder was ich noch machen kann?

Danke und Gruß
Hagbard

 

[Anonymous]

Deine Befehle sind unvollständig oder durcheinander.

losetup -e twofish256 /dev/loop0 /dev/md0

ist ok, und verändert auch nichts an deinen Daten, solange du nichts auf /dev/loop0 schreibst, allerdings musst du dann anschließend

mount /dev/loop0 /mnt

noch machen, also dein Device auch mounten wenn du zugreifen willst.
Diese Methode wird uA. dann verwendet, wenn man das Filesystem reparieren will oder muss, da man vor dem mounten auf das loopdevice zB ein fsck machen kann.

losetup /dev/loop0 /dev/md0
mount -t reiserfs -o encryption=twofish256 /dev/md0 /mnt
Password:
mount: /dev/loop2: can't read superblock

Was soll dass denn, im ersten Befehl verknüpfst du das Raid mit dem loop0.
im 2 Befehl mountest du das Raid - dazu wird das nächste freie loopdevice automatisch genommen. Der erste Befehl ist total überflüssig, und würde nur eine zusätzliche Pipeline für das zerstören des Filesystems aufmachen. Wenn die unterste Zeile die Fehlermeldung des 2. Befehls ist, wurde in diesem Fall hier loop2 automatisch benutzt. (bleibt dann aber die Frage was hast du denn jetzt noch zusätzlich auf loop1 gehängt, nicht noch einmal in irgend einer Art dieses Raid, oder ? Vorausgesetzt beim 2. Befehl ist das verwendete System bei der Verschlüsselung 100% kompatibel zu deinem urspünglichen System, würde dieser Fehler aussagen, dass entweder die Verschlüsselungsmethode oder das Passwort falsch war, die Mountoption reiserfs falsch ist, oder das Filesystem (jetzt) komplett defekt ist.

Der 2. Befehl an sich würde vollkommen ausreichen, solange das Filesystem und alle Optionen ok sind.


Da dieser Befehl jedoch nicht funktioniert, ist irgend etwas faul. Zuerst mal mit losetup -a anzeigen, was du jetzt alles für loops zusammenkonfiguriert hast. Dann mit losetup -d /dev/loop? alles erst mal wieder löschen, wenn es nicht irgend was anderes ist, was mit diesem Problem nichts zu tun hat.

Dann den

losetup -e twofish256 /dev/loop0 /dev/md0

und jetzt kannst du nachschauen ob das funktioniert, oder nicht.

file -s /dev/loop0

sollte dir anzeigen das dort ein Filesystem ist, steht dort Data ist das Passwort, die Verschlüsselungsmethode oder sonst irgendwas komplett verkehrt, oder das Filesystem komplett hin. Dann loop wieder löschen, und Verschlüsselung und Passwort überprüfen, dann neu versuchen
Dieses Filesystem dann eventuell noch reparieren also zB fsck -eventuellOptionen /dev/loop0
Und wenn das Filesystem dann irgendwann ok ist, dann kannst du es mounten mount /dev/loop0 /mnt

robi

 

[Hagbard88]

Hey,

erstmal Danke für die ausführliche Antwort.

Nun habe ich folgendes gemacht:

linux:~ # losetup -d /dev/loop0
linux:~ # losetup -e twofish256 /dev/loop0 /dev/md0
Password:xxx

linux:~ # file -s /dev/loop0
/dev/loop0: ReiserFS V3.6

Dann den Filecheck:

linux:~ # fsck /dev/loop0
fsck 1.40.8 (13-Mar-2008)
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/loop0
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Fri Jul 25 00:04:20 2008
###########
Replaying journal: No transactions found
Zero bit found in on-disk bitmap after the last valid bit.
Checking internal tree.. \block 37748759: The level of the node (188) is not correct, (4) expected
 the problem in the internal node occured (37748759), whole subtree is skipped                                                                     finished
Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.
Bad nodes were found, Semantic pass skipped
1 found corruptions can be fixed only when running with --rebuild-tree
###########
reiserfsck finished at Fri Jul 25 00:04:32 2008
###########

Tja, und dann den Rebuild:

linux:~ # fsck.reiserfs --rebuild-tree /dev/loop0
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will rebuild the filesystem (/dev/loop0) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal: No transactions found
Zero bit found in on-disk bitmap after the last valid bit. Fixed.
###########
reiserfsck --rebuild-tree started at Fri Jul 25 00:07:10 2008
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 19555146 blocks marked used
Skipping 9395 blocks (super block, journal, bitmaps) 19545751 blocks will be read
0%....20%....40%....60%....80%block 31432704: The number of items (3836) is incorrect, should be (1) - corrected
....100%                        left 0, 6592 /sec
Could not find a hash in use. Using "r5"
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 19545751
                Leaves among those 1
                        - corrected leaves 1
                pointers in indirect items to wrong area 7 (zeroed)
                Objectids found 4

Pass 1 (will try to insert 1 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                           left 0, 0 /sec
Flushing..finished
        1 leaves read
                1 inserted
####### Pass 2 #######
Flushing..finished
Pass 3 (semantic):
####### Pass 3 #########
Flushing..finished
        Files found: 0
        Directories found: 2
Pass 3a (looking for lost dir/files):
####### Pass 3a (lost+found pass) #########
Looking for lost directories:
Flushing..finishede 1, 1 /sec
Pass 4 - finished       done 0, 0 /sec
        Deleted unreachable items 1
Flushing..finished
Syncing..finished
###########
reiserfsck finished at Fri Jul 25 00:56:51 2008
###########

Jetzt kann ich das auch mounten, aber ALLE Daten sind weg und auf dem gemounteten RAID gibts nur einen lost+found Ordner, der auch noch leer ist ...

MIST ... warum ist jetzt alles wech? Die 3 Platten haben doch nix abbekommen ....

Gibts noch Wege zum Probieren / Basteln?

 

[Anonymous]

;ups;
sieht irgendwie gar nicht gut aus, wenn nicht vor dem fsck

**Do not run the program with --rebuild-tree unless **
** something is broken and MAKE A BACKUP before using it. **

beachtet wurde, dann währe jetzt der passende Moment dazu.

Ich würde sogar 2 mal Backup machen, eimal vom md0 und einmal vom loop also einmal verschlüsselt und einmal unverschlüsselt.

Was genau nicht funktioniert hat ? habe wenig Reiserfs-Erfahrung, Versionsunverträglichkeiten ? Aber möglich auch das da am Raid5 was nicht ganz passt, oder du bei irgend einer Aktion was im Filesystem zerstört hast. Die Verschlüsselung halte ich für unwahrscheinlich, sonst hätte er wohl nicht mal den Filesysttype erkannt.
Einzige Idee die ich dazu noch hätte, versuche mal eine LIVE-CD von dem altem 9.1 zubekommen, und schau mal ob er dort das Raid genauso aufstetzen würde, oder ob die letzten beiden vielleicht bei der 11.0 vertauscht wurden, zB. weil er die Hardware in anderer Reihenfolge erkannt hat?

PS: Vergiss meine einzige Idee, habe ich probiert, geht nur mit brachialer Gewalt das man die Devices in eine falsche Reihenfolge bekommt selbst wenn man sie umbenennt oder auf andere Platten verschiebt und bringt dann obendrein ein ganz anderes Fehlerbild.

robi (etwas ratlos)

 

[Hagbard88]

Hmm,

ja also das mit der Reihenfolge wäre auch mein Ansatz gewesen. Aber dadurch dass er sich mit dem richtigen Passwort auch "richtig" verhalten hat machte mich sicher.

Nur in welchem Punkt habe ich alle Daten zerstört bzw. die Struktur des reiserFS?

Außerdem: Die Daten liegen doch irgendwie noch drauf. Gibts nen "brachiales" Programm welches dort nochmal nach denen sucht und alles wiederherstellt was geht?

Gruß

 

[Anonymous]

Außerdem: Die Daten liegen doch irgendwie noch drauf. Gibts nen "brachiales" Programm welches dort nochmal nach denen sucht und alles wiederherstellt was geht?

Also mit Datenwiederherstellung von Reiserfs kenn ich mich nicht so gut aus, aber es sollte da einige Howtos geben, müsstest du mal suchen. Ich würde aber nur mit einer Kopie des unverschlüsselten /dev/loop arbeiten und nicht mit dem Orginal. Ganz böse Zungen behaupten, bei Reiserfs ist das so ne Art Volkssport, wie gesagt - ich arbeite nicht damit.

Was war denn auf dem Raid, nur bestimmte Dateitypen, dann kannst du auch mal das hier probieren. http://www.cgsecurity.org/wiki/PhotoRec
Das funktioniert Filesystemunabhänig und scant die Blöcke und versucht Dateien so wiederzufinden und zusammenzubauen. Wenn die Dateien nicht allzusehr fragmentiert sind, leistet es ganz gute Arbeit. Arbeitet mit Reiserfs zwar nicht besonders gut zusammen. kommt auch darauf an, was es für Dateien waren, die dort rumlagen. Aber wie gesagt, auf der Kopie

Ansonsten die schweren Geschütze? Mal mit Google suchen, gibt einiges an _ReiserFS_Data_Recovery_Software :roll: Aber auch sonst recht gute Howtos, Aber erstmal müsstest du überhaupt mal was ausprobieren, damit du eventuell erkennst wo das Problem liegen könnte, und ob die Dateien überhaupt noch da sind.

robi