samvanratt
Goto Top

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

Content-Key: 340311

Url: https://administrator.de/contentid/340311

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: falscher-sperrstatus
falscher-sperrstatus 12.06.2017 um 10:56:01 Uhr
Goto Top
Hi Sam,

danke für deine Ausarbeitung - HTML benötigst du nicht, dafür hat @Frank diverse WYSIWYG Elemente eingebaut.

Zum anderen: Wenn ein RAID zerstört ist kann man das schon früher abfangen. FixMBR+FixBoot usw usf sind da nur schlimmer - am besten auf das eingebaute Raidmenu zurückgreifen und die Foreignconfig wieder laden.

Final: Backup(!)

VG
Mitglied: SamvanRatt
SamvanRatt 12.06.2017 um 12:10:53 Uhr
Goto Top
Hallo certifiedit.net
dazu sollte ich scripting aktiv haben... face-smile=

Das "fixmbr und Co" war der Zustand (wie geschrieben), wie ich es x Mal erhalten habe. Klassisch wird ja von den IT'lern vorher schon rumprobiert, bis hier eben Zerstörung (GPT+MFT). Ich will damit das "ist gar nicht so schlimm" Flag setzen, auch wenn kein normales OS oder Rettungstool das mehr erkennt.

Das Foreign Config kennst du von den vollwertigen LSI basierenden RAID Controllern (wie auch den HP Pxyz Serien); leider haben das Softraids eher selten und Hostraids eben auch eher per Zufall. Adaptec, Highpoint, 3ware, ... eben gar nicht vorgesehen... wie halt geschrieben; dank dem obigen "Reparatur" Vorgang ist dann auch die Info in den Kontrollern nicht mehr erkennbar (meist ist die Info ja nicht im NVRAM untergebracht, sondern ganz vorne oder hinten an den jeweiligen HDs).

Archivierung ist immer eine gute Lösung; bei komplexen Installationen (WTS) hat man damit aber doch nur die Daten, nicht das Image oder bestimmte Toolketten. Wenn die Archivierung auch noch fehlerhaft ist....

Wie geschrieben verdiene ich mein Geld mit Datenrettung (wenn auch meist Tape/MO), insofern sollte ich mich darüber freuen, aber viele würden es ja gerne selber probieren; dafür diese Anleitung hier face-smile

Gruß
Sam
Mitglied: falscher-sperrstatus
falscher-sperrstatus 12.06.2017 um 12:17:02 Uhr
Goto Top
Hi Sam,

naja, dann solltest du dir zumindest die Mühe machen und es manuell anpassen - ist nicht schwer <tag></tag>, sonst attestiere ich dir, dass deine ganze Mühe für das Schreiben "auf die Miste gedunkt ist", wie es hier im schwäbischen so schön für "umsonst getan" heisst.

VG

PS: Wer kein Backup hat und auf Billig Raidcontroller setzt ist imho selbst Schuld.
Mitglied: SamvanRatt
SamvanRatt 15.06.2017 um 14:54:49 Uhr
Goto Top
Hallo certifiedit.net
dann mache ich mich mal ans schön zeichnen.

Gruß
Sam

P.S.: Du hast keine Ahnung wie viele (durchaus teuer bezahlte) Admins denken sie hätten Hardware unter sich, da die Specs ja seltenst was dazu aussagen. Die Zeiten als noch echte XOR Logik in Silizium vergossen war, ist ja lange her und dicken universal IO Kontrollern (ARM/MIPS) gewichen, welche streng genommen auch nur ein SoftRAID machen, aber halt Transparent nach außen hin). Backup haben und Backup überprüfen sind zwei lustige Themen und würde mir viel Arbeit ersparen....
Mitglied: falscher-sperrstatus
falscher-sperrstatus 15.06.2017 um 15:01:24 Uhr
Goto Top
du meinst <dicke> Hardware unter sich? Ja, glaube ich dir und auch bei dem Nebensatz "[glauben] Backup zu haben und Backup zu überprüfen"...hast du absolut Recht, aber Backup prüfen kostet Zeit...weisst du ja...
Mitglied: SamvanRatt
SamvanRatt 16.06.2017 um 16:15:54 Uhr
Goto Top
Hi
wie wahr, wie wahr. Wie gesagt lebt meine Firma davon, aber es ist auch für gute Admins (wer will da noch gerne auf Layer1 rumkrebsen, wenn Layer4 (=OS) bezahlt wird) sind die früheren Unterscheidungen (OS Transparenz, seperater Platinenplatz, eigener RAM, eigenes NVRAM, eigener IO Controller, kleine Treiber) schon lange nicht mehr gelten, dank RAM on Chip, RAID on Chip, HardwareReady IO Controllern (dumm ohne Lizenz, gut mit Lizenz) und ständige "schlechter" werdenden Treibern (=Größe im Sinne von schöneren Programmiersprachen) haben die meisten Profis da auch nur den Geldansatz um Hardware von Software RAID zu unterscheiden. Wo früher noch SATA = billig galt, gibt es nun genügend unschöne SAS Controller (Marvell ganz voran) welche viele SAS Features einfach unbeachtet lassen; Blocktransfer aber gut funktioniert und Fehler damit gar nicht auffallen.
Bei größeren Firmen habe ich seltenst Band/Archivkunden, was schlüssig klingt das die auch da redundant fahren, aber kleinere Firmen haben halt nur Teilzeitadmins aus der günstigeren Schublade und was da nicht vorkommt (eingeplant) geht gerne unter.
Gruß
Sam


P.S.: Hoffe die Lesbarkeit hat deutlich zugenommen.
Mitglied: SamvanRatt
SamvanRatt 08.07.2017 um 15:48:03 Uhr
Goto Top
AddOn:
Frage: Wieso addiere ich defekte Bereich (ausgefallene Members) bei RAIDx0 Systemen?
Antwort: alle Datenrettungsprogramme gehen gut mit Lesefehlern (BadBlocks) oder Fehlern (Bereiche überschrieben) um, aber Inkonsistenzen wie durch fehlende Nummernbereichen liefern evtl. ungenaue/fehlerhafte (weil falsch berechnet) Sprungadressen (MFT/inodes). Daher ist es wichtig das Dateisystem so gut wie möglich zu rekonstruieren.