defektes Raid5 mit Restinformationen Topic is solved

TestDisk benutzen um verlorene Partitionen wiederherzustellen
Locked
Message
Author
capathor
Posts: 5
Joined: 21 Oct 2015, 21:02

defektes Raid5 mit Restinformationen  Topic is solved

#1 Post by capathor » 21 Oct 2015, 21:47

Hallo liebe Wiederherstellungsgemeinde,

ich versuche seit wochen ein (teilweise aufgrund völliger Dummheit) zerschossenes Software-Raid5 wiederherzustellen.
Leider blieb der Erfolg bisher aus. Zuerst ein paar Eckdaten:

Das Raid besteht aus 4 x WD Red 3TB.
Im Raid5 sind damit netto gute 8TB nutzbar gewesen.
Erstellt wurde es über die GUI von Openmedia Vault.
Formatiert war es ohne Partitionierungsschema (mehr dazu später) und mit ext4.
Bei der Erstellung wurden /dev/sd[bcde] verwendet (e ist defekt und nicht mehr aktiv). Also OHNE die sonst übliche 1.
Das Raid wird unter /dev/md0 assembled.
Nun ist eine Platte ausgefallen (Hardwaredefekt aufgrund eines sturzes des Systems bei einem Umzug).
Der ReSync mit einer neuen Platte hat nicht mehr funktioniert. Das Mounten wurde leider auch mit einer Fehlermeldung (Filesystem ungültig) quittiert.

Stand jetzt:
Ich durchsuche mit unterschiedlichen Settings seit einigen Wochen den Raid, in der Hoffnung, die ursprüngliche Partionion wiederherstellen zu können. Dummerweise habe ich in einem Anflug von Panik nicht richtig gelesen und einen Vorschlag verfolgt, der den Raid neu initialisiert hat und dabei alle Superblöcke genullt hat.
Unter einer MBR- und auch unter einer GPT-Suche findet testdisk nun nichts brauchbares. Durchsuche ich den Raid mit dem Partitionsschema None, findet er Angaben zu der alten Partitionierung. Dazu gehört unter anderem der alte Name des Raid5 ("datengrab").
Nachdem testdisk mehrere Tage durchgelaufen ist bekomme ich dann am Ende eines Deeper Searches leider immer:

Code: Select all

[...]
72440:The following partitions can't be recovered:
72441-     ext4                 137293742   0  3 412006094   0  2 2197698816 [datengrab]
72442-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
72443-     ext4                 137293792   1  4 412006144   1  3 2197698816 [datengrab]
72444-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
72445-     ext4                 137293808   1  4 412006160   1  3 2197698816 [datengrab]
72446-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
72447-     ext4                 137293824   0  2 412006176   0  1 2197698816 [datengrab]
72448-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
72449-     ext4                 137293905   0  3 412006257   0  2 2197698816 [datengrab]
72450-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
72451-     ext4                 137293912   0  3 412006264   0  2 2197698816 [datengrab]
72452-     EXT4 Large file Sparse superblock Recover, 9001 GB / 8383 GiB
[...]
Kann ich nun mein Datengrab wiederherstellen? Wenn ja, wie?

Vielen Dank für eure Hilfe!

EDIT (23.10.2015):
Ich habe noch einmal einen Deeper Search durchlaufen lassen, bei dem ich vorher den die Zylinderanzahl wie hier:http://forum.cgsecurity.org/phpBB3/ntfs ... t2077.html von Fiona beschrieben manipuliert habe. Dabei wurde nur noch 5x angegeben, dass mein Datengrab nicht wiederhergestellt werden könne. Nachdem ich dies quittierte, konnte ich in der endlos langen Liste an gefundenen Partitionen einmal einen Eintrag für mein datengrab finden. Jedoch, wenn hier über "p" die Daten auflisten lassen möchte, bekomme ich leider nur gesagt: "Can't open filesystem. Filesystem seems damaged."
Besteht dabei nun noch Hoffnung?

Hier zwei Screenshots dazu:
DSC_0157.jpg
DSC_0157.jpg (252.49 KiB) Viewed 1280 times
DSC_0158.jpg
DSC_0158.jpg (212.26 KiB) Viewed 1280 times

Sponsored links

capathor
Posts: 5
Joined: 21 Oct 2015, 21:02

Re: defektes Raid5 mit Restinformationen

#2 Post by capathor » 27 Oct 2015, 18:38

Hat wirklich keiner eine Idee oder Ahnung, ob und / oder wie da noch was zu machen ist?
Fehlen noch Angaben, um dazu etwas sagen zu können? Für jeden Tipp wäre ich sehr dankbar!

User avatar
Fiona
Posts: 2836
Joined: 18 Feb 2012, 17:19
Location: Ludwigsburg/Stuttgart - Germany

Re: defektes Raid5 mit Restinformationen

#3 Post by Fiona » 31 Oct 2015, 10:50

Sry for late.
TestDisk 6.13 ist bereits ziemlich veraltet und von 2011.
Kann sein das zur Zeit noch kein ext4-Support richtig beinhaltet war.
Interessant ist für mich die alte Platte.
Teile mir bitte die Probleme der alten Platte mal näher mit.

Auch denke ich, das in der Version TestDisk 6.13 noch nicht für PC mit UEFI integriert war, sonder höchstens EFI-GPT für Apple.
Neuere Version über Knoppix oder Ubuntu könnte helfen.
Bei partition table type None wird jeder Sektor durchsucht.
Die Platte fängt aber nicht bei der ersten Partition an, sondern direkt am Plattenanfang.
Auch kann keine Partition in die Partitionstabelle geschrieben werden.
Aber bei neuere Versionen wird ext4 und auch über den Partitionstabellentyp EFI GPT unterstützt.
Würde hier praktisch auch jeden Sektor wie bei None durchsuchen und Partitionen anzeigen.
Teiler mir mal dein OS mit.
Formatiert war es ohne Partitionierungsschema (mehr dazu später) und mit ext4.
Teile mal dazu mehr mit?
Hast du ein Array/RAID5 mit der neuen Platte genau wie zuvor wieder erstellt?
Ohne Resnc wenn eine Platte fehlt und ersetzt wurde, kann nur über Datenrettungssoftware versucht werden, unterliegende Dateien welche noch funktionieren wiederherzustellen.
Unter Windows kann ein NAS welches kein günstiges Cloud-Laufwerk ist über eine Secureshell wie SSHFS (SecureShellFileSystem) und der Dokan Library zugegriffen und mounted werden.

Wichtig ist, hattest du dein RAID genau wie vorher wieder erstellt?

Fiona


Fiona

capathor
Posts: 5
Joined: 21 Oct 2015, 21:02

Re: defektes Raid5 mit Restinformationen

#4 Post by capathor » 02 Nov 2015, 12:18

HI Fiona,

erst einmal danke dafür, dass du dir die Zeit nimmst!

Dass ich hier TestDisk 6.13 verwendet habe liegt daran, dass es die Version aus dem Debian 7.9 Repository ist. Ich hatte auch schon ein Rescue-System (http://www.sysresccd.org/SystemRescueCd_Homepage) angeworfen, da war Testdisk in Version 7 dabei. Das brachte keinen nennenswerteren Erfolg als die Version 6.13. Ich werde aber deinen Tipp befolgen und die neuste Version installieren. die alte Platte hat einen Hardware-Defekt. Aufgrund eines Sturzes des gesamten Rechners, hat es hier wohl den Lesekopf erwischt. Das habe ich leider viel zu spät bemerkt. Nach einem Neustart wurde diese Platte dann zu einem Spare-Laufwerk gesynced. Da ich nicht rechtzeitig bemerkt habe und verstanden habe, was da vor sich geht, passierte das ein paar mal (über mehrere Wochen hinweg). Das war vermutlich schon fatal.
Als ich diese Platte dann durch eine "frische" erestzt habe, ging natürlich ein neuer Resync los. Als dieser beendet war, konnte ich das Raid nicht mehr mounten - angeblich war kein Filesystem mehr da (auch mit mount -text4).

Die Sache mit dem GPT war mir nicht bewusst. Da es sich um 3TB Festplatten handelt, bin ich ja prinzipiell gezwungen GPT zu nehmen. Ich muss also alleine hierfür einmal die neuere TestDisk-Version installieren.

Partition table type none war die einzige der drei Suchmodi die ich versucht habe, die ext4 Partitionen gefunden hat. Unter einer MBR Suche wurden Partitionen vom Typ "Linux" gefunden und unter einer GPT-Suche fast ausschließlich Partitionen vom Typ "MS-Dos". Deswegen ging ich am Ende davon aus, "None" sei die richtige Wahl. Dazu kommt, dass das Raid mit den RAW-Devices erstellt wurde (also mit /dev/sd[bcde]) ohne (!) eine Zahl dahinter. Wenn keine neue Partitionstabelle geschrieben werden kann, ist das erst einmal kein Problem, wenn ich die Daten wenigstens sehen und auf eine neue Platte kopieren kann (ich habe hier eine 8TB-HDD dafür liegen, auf der befinden sich derzeit aber (viel zu spät) erstellte dd-Images von zwei der drei noch funktionierenden Raid-Platten).

Das Betriebssystem mit dem ich jetzt die Operationen durchführe ist Debian 7.9. Es ist eine leicht angepasste Version durch http://www.openmediavault.org/.

Beim Neuerstellen des Raids habe ich keinerlei Dinge geändert. Da es ursprünglich über die Openmediavault Oberfläche erstellt wurde, habe ich das zuerst damit auch noch einmal gemacht. Als das keinen Erfolg brachte, habe ich eine Schnellformatierung durchgeführt und (<ironie> jetzt weiß ich, dass das superintelligent war</ironie>) noch einmal neu angelegt. Nun konnte ich mein Raid wieder verwenden, aber es waren halt keine Daten mehr da. In der Hoffnung, meine Daten wieder erreichbar zu machen, habe ich das noch einmal manuell wiederholt mit der Option die Superblöcke zu "nullen" (mdadm --create --zero-superblock [...]) Das ist quasi der Zustand den das Raid jetzt hat.

Seit dem habe ich keine Schreibvorgänge mehr auf den Platten zugelassen und vor dem --zero-superblock habe ich die dd-images erstellt. Das ist jetzt ca. 4-5 Wochen her. Seit dem habe ich die Platten mit unterschiedlichen Settings in Testdisk mehreren deeper searches unterzogen.

Mein "NAS" ist ein richtiger Computer (Xeon e5472, 8GB RAM) auf dem ESXi Version 6 läuft. Das System ist auf einer SSD installiert und dient als Host für derzeit 5 Systeme. Eines davon ist das oben beschriebene Openmediavault Debian 7.9. Die Raid-Festplatten sind direkt an diese VM durchgereicht, sodass diese als einzige VM (nativen) Zugriff auf die Platten hat. Von dieser VM wurden via NFS, Samba usw. Freigaben für mein gesamtes Netzwerk verwaltet.

Ich kann also via SSH direkt auf das System zugreifen und habe auch schon versucht das Raid mit unterschiedlichen Festplattenreihenfolgen zu "assemblen". Leider kann ich damit nicht experimentieren, da mdadm immer die "ursprüngliche" (nämlich die des letzten --create) Reihenfolge der Platten verwendet. Sogar wenn ich die --force Option dazu angebe.

Das habe ich letzte Woche mehrmals versucht, da ich mit Testdisk keine Fortschritte mehr erzielen konnte und statt dessen mit Photorec Daten suchen wollte. Das super funktioniert, solange diese Daten kleiner als 512kb waren. Mit Ausnahme von zwei Bildern die jeweils ca 900kb groß waren, sind alle anderen Dateien >512kb mehr oder weniger Datenmüll. So werden PDFs gefunden, die ich teilweise öffnen kann, die auf einmal mehrere 100MB groß sind aber nur aus 3 Seiten Text bestehen. Auch mehrere PDFs mit teilweise >5GB größe hat photorec gefunden. Das ist natürlich quatsch und öffnen konnte ich die leider auch nicht. Somit bin ich davon ausgegangen, dass eventuell der Raid in einer falschen Reihenfolge assembled ist.

Ich hoffe das hilft beim Helfen etwas weiter?

Viele liebe Grüße und schon einmal vielen Dank!

capathor
Posts: 5
Joined: 21 Oct 2015, 21:02

Re: defektes Raid5 mit Restinformationen

#5 Post by capathor » 22 Nov 2015, 16:19

Hi zusammen,

ich habe mich in der Zwischenzeit mal alternativer Software umgesehen. Dabei bin ich (unter anderem) auf ReclaiMe (Free RAID Recovery) gestoßen. Dies hat mir nach einer Analyse folgende Eckdaten für meinen verlorenen Raid ausgespuckt:
2015-11-22-raidrettung.png
2015-11-22-raidrettung.png (174.34 KiB) Viewed 586 times
Gibt es nun eine Möglichkeit mit testdisk diese Konfiguration einmal zu analysieren? Habt Ihr vielleicht einen Tip, wo ich weiter in die Materie einsteigen kann oder was es für Datenrettungssoftware gibt mit der ich hier ansetzen kann?

Vielen Dank für jede hilfreiche Art Hinweis!

Viele Grüße!

capathor
Posts: 5
Joined: 21 Oct 2015, 21:02

Re: defektes Raid5 mit Restinformationen

#6 Post by capathor » 18 Dec 2015, 02:13

Nach reiflicher Überlegung habe ich mir eine Datenrettungssoftware gekauft. Diese hat (wie ich bereits berichtete) die Originalzusammensetzung des RAID5 gefunden. Mit Hilfe des Programms konnte ich dann ca. 95% der Daten retten. Da die Software sehr teuer ist, habe ich lange hin und her überlegt. Aber falls jemand vor ähnlichen Problemen steht, kann ich nun vielleicht weiterhelfen :) .

Locked

Who is online

Users browsing this forum: No registered users and 0 guests