Datenrettung bei Hardware RAID+ SoftRAID+FakeRAID+HostRAID 0 + 1 + 1+0 +1E (und prinzipiell auch darüber. 3,4,5,6) bei NTFS Datenträgern (und teils auch XFS, btrFS, EXTx, HFS+, FAT.)

Anfangssituation:

HD1-4 (SAS, 3TB, 7k2) waren in einem LSI basierenden Host-RAID (R1+0), welches durch einen falschen OS Treiber die RAID Infos verloren hat (in Verbindung mit einem Windows SelfRepair und fixmbr und Co auch noch GPT + MFT Schäden davon getragen hat).

Vorgehensweise:

a) ich erhalte die HDs und beschrifte/nummeriere diese eindeutig! Die S/N sind leider in keiner Software native Sichtbar, daher sind kleine (farbige) Aufkleber (gut klebend) hier hilfreich und hilft auch beim optischen Unterscheiden

b) an einen dummen SAS HBA anschließen und jeweils im dd Image ziehen

c) sicher (im Netz) ablegen (SAN bei mir); dies erleichtert die spätere Verarbeitung + evtl. Duplizierung enorm

d) herausfinden welche HDs Stripes und welche Mirror sind=>Annahme: Stripes haben immer unterschiedliche Blockinfos; Mirrors immer gleiche; Einschränkung: die ersten 32kB sind aber immer unterschiedlich, da dort die Part (nur MBR) + RAID Infos liegen
"ddrescue -f -i=2MiB -s4MiB /dev/sda /SAN/HD1_2MiB_block.bin"
die entstehenden 4 dumpfiles mittels filecompare (diff) oder einer MD5 Quersumme sollten je zwei Paare gleiche Summen und zwei unterschiedliche haben. Interessant sind hier die unterschiedlichen (=Stripepartner); sofern eine HD beschädigt ist nimmt man natürlich die fehlerfrei gelesene für die weiteren Operationen. Ich nehme einfach HD1 und HD2 als Stripepartner für die Beschreibung.
=> Sofern hier vier unterschiedliche md5 Summen herauskamen (oder diff fand immer unterschiede), ist dies kein reines RAID1+0, sondern evtl. ein RAID1E (eine Spezialität von IBM/Lenovo) und 3ware/LSI oder eben doch ein RAID3/4/5 mit je einem Hotspare oder ein (recht sinnvolles) RAID6 (zwei beliebige Members dürfen ausfallen; die Rechenpower dafür ist aber deutlich konsumierender).

e) herausfinden welche Cluster (Stripe) size benutzt wurde; dazu gibt es zwei Ansätze
1) ein käufliches Tool (wie Runtimes RAID Reconstructor)
2) man steckt vier HDs in den nun leeren RAID Controller und geht den Erstellungsprozess des Kontrollers durch (in der Annahme das die meisten Admins sowieso nur defaults nehmen, da sie keine Ahnung von der Wirkung der Parameter haben...daher lieber default da sicher) und schaut was als default Cluster-/Block-/Stripesize eingestellt ist (je nach Controller bietet sich auch noch Interleaving als Parameter an). Ein Echtes erstellen ist nicht notwendig; wichtig ist nur die Memberzahl gleich wie das Original zu haben. Typisch sind bei RAID1+0 oder nur 0 Blocksizes im Bereich von 64kiB bis hin zu 2MiB. Da der Cacheverbrauch mit der Size ansteigt ist 64KiB oder 128KiB immer noch Standard; ich nehme im Beispiel 64KiB an (was auch Intels FakeRAID nutzt per Default).
3) man frägt im Herstellerforum nach, was denn typisch default ausgeliefert wird (OS bereits installed) oder wenn jemand einen baugleichen Server/Workstation hat in dessen RAID Settings (webGUI, CLI,....) nach.

f) herausfinden der Reihenfolge=> das geht dank der tollen Beschreibung von MBR und GPT recht einfach, indem auf dem ersten Member (ich nenne es mal HD0) diese Infos direkt lesbar darauf liegen und super mit einer nonRAID Boot HD vergleichbar sind (erste 63 Sektoren zumindest). Bei mehr als 2/4 Membern wird es etwas mehr Arbeit, da dann der Mittelteil ausprobiert werden muss.
Ich nutze dafür den RAID Reconstructor und lasse mit den ersten paar GB die drei Möglichkeiten zusammenbauen und gehe dann mit den Images an eine Recovery Software. Ab 10 (=5 aktive) Membern wird das deutlich aufwendig (2^4 Möglichkeiten) und dann hilft mir DiskInternals RAID Recovery weiter, da dieser dies automatisch probiert.

g) nun kann man Perl Skripte benutzen, welche via dd einen Intermix des RAID0 Systems durchführen aufgrund der Parameter die wir ermittelt haben. Nach ein paar GB sollte man den Task erst einmal abbrechen und mit tools wie photorec sehen, ob er integre Dateien findet; wenn nicht sind die Parameter falsch (oder ein Controller wie 3ware nutzt Interleaving um im Lese/Schreibbetrieb bei 4 Membern die 4 fache anstatt doppelte Geschwindigkeit rauszuholen)=> rumprobieren und viel Spaß
ICH nutze dazu aber lieber den UFS Explorer von SysDev (ich zahle ja auch dafür....). Wenn man dort dann die beiden Stripe Images mounted kann man nach einigen Sekunden sehen, ob das Image integer ist. Je nachdem wann/wie das Volumen zerbrach, kann es sein das wir ein "schmutziges" Dateisystem vorfinden, teils mit beschädigtem Bitmap oder Journaling Inkonsistenzen. In dem Fall ziehe ich erst einmal ein Vollimage (bei mir dann mit 2*3TB=6TB) und danach arbeite ich mit einer Kopie des Gesamtimages (bei modernen HD Größen oder entsprechender Memberzahl kommen da schon dicke Speicheranforderungen raus; bei geringbefüllten Images rentiert es sich, mit gzip/bz2 streamkomprimierte Abbilder zu nutzen) und ich lasse entweder typische Datenrecoveryprogramme (Quetek's Filescavenger, Runtime's GDB, cgSecurity's Photorec, FSYS's DFSee, Piriform's Recuva, X-Way's WinHEX oder O&O's DiscRecovery) laufen. Oft mehrere parallel, da jedes Programm andere Parameter zur Suche nutzt. In den normalen Fällen aber reicht eines, da ein schwer beschädigtes Filesystem doch eher selten ist, wenn das Array nicht während des (Shutdown=Cache Flush) Schreibvorgangs auseinander gerissen wurde (und selbst dann sind alle Journaling Filesysteme gut gewappnet).
Ich persönlich bevorzuge den Filescavenger und GDB (für NTFS).

h) sofern man das bootfähige System wieder voll braucht (also nicht nur den Dateiinhalt) bleiben (Perl)skripte (um die Blöcke zu einem Image zusammenzufassen) oder der erwähnte RAID Reconstructor (Diskinternal's RAID Recovery kann dies auch, allerdings ist die Erkennung der RAID Sets bei meinen Benutzungen schon mehrfach falsch oder gar nicht erkannt worden, wo Runtime einwandfreie Ergebnisse lieferte), welcher eine HD oder ein Image bespielen kann.
Mittels dd/winRAWcopy/... kann man dieses dann einfach auf das neue Volumen (via Netz geht das ganz einfach) aufspielen und booten oder virtualisieren (VirtualBox bietet eine schöne Sammlung an RAW nach VM kompatiblen Images an).
Für Linux (EXT2/3/4; btrfs; xfs) User dürfte das Tool Linux Recovery von Diskinternals interessant sein, welches als Freeware released wurde.

i) Dateiprüfung: Der Kunde hat damit zwar viel zum manuellen Sortieren (ich nutze in der Arbeit ein Programm, welches alle Dateien durch ein libreoffice, pepperflash, Browser, CADVDM, pdfForge, ghostscript, PMView,.......... durchläßt und auf Integrität prüft; daheim will ich aber ein solches IO+CPU Monster nicht halten), daher kommt hier der Kunde in eine Pflicht, die Daten zu sichten und auszusortieren. Durch die vielen (parallel) nutzbaren Rettungsprogramme kann man auch viele Systemstände abliefern.
Aus einer vollen 160GB HDs habe auch schon 700GB Daten abgeliefert (Teils waren die Namen zerstört, teils der Inhalt, teils die Ordnerstruktur, teils waren alte + neue Stände vermischt), aber es wurden trotz schwerer MFT Beschädigung alle Daten wieder zur Verfügung gestellt.

j) Datenablage: da man ja schon einen Notfall hatte, bietet es sich an nicht genauso fahrlässig mit den schwer erbeuteten Daten umzugehen: immer erst löschen wenn eine nutzbare Vollsicherung auf dem Zielsystem gefahren wurde!


Spezialfall RAID0 mit einem/mehreren Membern Missing:
Ich kenne hierfür keine käufliche Software, welche das soweit machbare wieder 'pro forma' zusammensetzt (bis auf eine Eigenentwicklung eines bekannten Datenrettungsunternehmens namens BitAlligner).
Bei ICP Vortex, bzw. heute noch Areca und Highpoint gibt es ein solches Tool, erfordert aber die Hardware und die Basis (Sourcekontroller), dass dieses RAID0 dort einmal genutzt wurde... Prinzipiell wäre es mit dem selben Perl skript für dd abzuwandeln um damit dann aus 4 Membern á 1TB ein 4TB großes Imagefile zu erhalten indem halt ein/zwei defekt/missing sind. Da diese Skripte zwar nett sind, mir aber das Doing nicht immer schlüssig ist, nehme ich einen Umweg über gleich große Leere Images:
dd if=/dev/zero of=Image_missing_HDx.bin bs=512 count=2147483648
Alternativ wäre das Image mit anderen Standardzeichen (XXX....X) zu füllen, welche man später sehen/suchen kann. Mit den nun vier Images kann man ein korruptes Gesamtimage erzeugen, welches dann mit den üblichen Tools durchsuchbar/rettbar ist. Prämisse ist weiterhin: die Daten sind evtl. alle korrupt da unvollständig, ABER alles unterhalb der Clustersize * vorhandene Members ist hochwahrscheinlichrettbar.


Tipp: woran erkennt man, wie viele Daten maximal rettbar sind: An der Entropie H (Informationsdichte).
Ein schöner Maßstab ist eine komprimierte Imagedatei (zip ganz simpler Modus). Dazu wird das Image um alle unnötigen Informationen (leere Blöcke) erleichtert. Das ist wichtig wenn HDs/Thumbdrives/SSDs, ..... "gelöscht/formatiert" wurden.
Wichtig ist dabei die Frage wie gelöscht wurde (was die wenigsten dann beantworten können), sprich "Is denn noch was vorhanden zum Retten". Durch den Durchschnittswert bei Kompression von 1:2 kann man als Daumenwert recht gut vorhersagen wie viel man da noch rausbekommen kann:
Gute Kompressoren (wie 7-zip)können aus einem (bis auf's FAT32 Dateisystem) leeren 4GB CFLASH Einschub kompakte 120kB machen. Sofern da nicht simple Textdateien vorher drauf waren, ist die Erstaussage recht schnell klar: da ist nichts zu retten.
Ein als Beispiel 4TB großes NTFS Volumen mit komprimierten 210MB dürfte sehr leer sein bis auf die obligatorischen Volumenbitmap, Logfile und die minimalen MFT Einträge + Superblocks).
Bei 35GB Größe kann da schon ein dickes ServerOS mit Pagefile und evtl. einer Datenpartition oder Profiles liegen und noch recht frisch (=keine gelöschten Dateien) sein. Bei 2,4TB dürfte das Filesystem schon recht voll sein (das enthält ja weiterhin auch alle gelöschten Dateien) und sofern moderne Office Dateien (sind ja nun alle vorkomprimiert) drauf waren wohl im Bereich von 2,5TB Daten, die man da rausbekommen kann.

Spezialfall: bei Unixoiden Filesystemen ist meist schwer was zu sagen: gelöschte Blöcke liegen auch hier vor, lassen sich aber durch die fehlenden Inodes nicht mehr rekonstruieren, erhöhen aber die Entropie.


Gruß
Sam