Raid migriert... HDD defekt nach 4%

[Kletschmeister]

Hallo erstmal,

ich habe da einen spezial gelagerten Sonderfall der mich und mein aktuelles Wissen arg strapaziert.

Ich bin Besitzer eines Promise SmartStor NS23000 NAS in dem ich eine 1 TB Platte verbaut hatte - diese ging auf 90% Belegung rauf und so dachte ich da muss ich mal was machen.
Also eine 2. (1- TB) Platte besorgt und fertig zum Einbau gemacht... dann das NAS heruntergefahren und dachte noch bei mir: "naja die aller wichtigsten Daten hättest doch mal brennen sollen....hast du schon lange nicht mehr gemacht...."

Auf später vertagt und los gelegt ... bei der Frage Mirror oder Striping war dann die Antwort klar - ich brauche ja mehr Platz brennen tu ich ja dann nachher.... und mit dem Wissen das bei 1 TB Platten selbst das Formatieren lange dauert gesagt - naja läßt das mal über Nacht schön migrieren und morgen ist dann ein Brenntag angesetzt.

Haken ist nur nach 4% der Migration Abbruch - die neue HDD ist defekt. Raid offline...

So jetzt ist die kacke am dampfen...

Zusammenfassend:

1 TB Speicherplatz
90% Belegt
Wahrscheinlich ext3 Dateisystem
Änderung auf Stripping sprich Aufteilung aller Dateien in die entsprechende Blockgröße verteilt auf Platte A & Platte B
allerdings nur 4% das heißt doch das es irgendein Tool geben muss was die restlichen 86% der 900 GB Daten irgendwie lesen können muss.

Einer hier ne Idee?

 

[Mueli]

Du wirst wohl nur mit Datenrettungstools zum Ziel kommen, Du solltest ein Tool wählen, was auch einen Roh-daten-Scan beherrscht, wie z. B. Ontrack Easy Recovery Pro, mal probieren.

Unterstützt denn das NAS überhaupt eine Online Migration? Gibt das Handbuch für den Fehlerfall etwas her? Hast Du mal probiert den Support anzusprechen?

 

[Plaste]

Au weia, ich habe 3*1 TB im RAID. Und jetzt ein flaues Gefühl in der Magengegend.

Hat die Platte definitiv ne Macke oder hat sich nur das NAS bei 4% aufgehängt?
Bei mir wird vor dem Striping ein Diskcheck durchgeführt der eine gefühlte Ewigkeit dauert.
Macht das Promise sowas nicht?
Welche Art von Defekt? Geist aufgegeben (tot?, kein Mucks?) oder defekte Blöcke?

Ontrack Easy Recovery kann kein ext3 lesen auch nicht in der Pro Version.
R-Studio kann sowas.

Uarg.
Promise fragen.
Beten.

Gruß von dem der jetzt Backuppen geht

 

[Kletschmeister]

1) Die neu dazu gebaute Platte machte so ein nettes klacker geräusch aber erst an einem bestimmten Punkt. (bei 4%')

2) Einen Check hat das WebInterface nicht angeboten bzw. nicht durchgeführt - zu mindest kann ich mich nicht daran erinnern.

3) Das "Raid" lief ja mit der einen Platte musste es ja ~hochfahren~ um über das Webinterface die 2. Platte einzubinden. Nur jetzt sind die "Recover-Möglichkeiten" wirklich sehr sehr beschränkt. Das Raid ist offline wegen Hardware Error bzw. Disk Error ein Retry bzw. ein Stop gibt es nicht. Auch ein versuch eine brandneue Platte statt der defekten einzubauen und praktisch zu sagen verzichte auf die 4% die du schon hast gib mir die 96% der Rest daten hilft nichts. Und zu viel experimentieren möchte ich eigentlich nicht.

also R-Studio

Was ist mit Testdisk ? Damit ging immer was aber bisher wurde mit nicht viel angezeigt...

 

[Mueli]

Das Rohdaten lesen ist unabhängig vom Filesystem, dabei wird nur an Hand von Signaturen in bekannten Files (Header) der Typ erkannt und versucht die Fragmente zusammenzusetzen.

Wenn die Migrierung bereits begonnen hat, ist sicher ein Großteil der MFT weg und damit ohnehin das Filesystem stark beschädigt, bei NTFS belegt die MFT in der Standardeinstellung etwa bis 12% der Disk-Kapazität, je nach Füllgrad der Disk und Art der Dateien (kleine, große) ist sie u. U. komplett weg.

Testdisk ist ein Tool um primär die Partitionierung wieder herzustellen, ich würde mir da keine Hilfe erhoffen aber probieren kannst Du es mal.

Führe mal eine Diagnose mit Testdisk wie folgt aus.
Lade Dir dazu Testdisk 6.12.

Nach dem Start von Testdisk beantwortest Du die Frage nach einer Logdatei mit Y. Den Partitionstyp solltest Du mit Intel beantworten. Dann wird Analyse aus dem dann erscheinenden Menü gewählt. Mit Quick Search wird dann der Vorgang fortgeführt (bei Vista mit Y antworten, wenn die Partitionierung unter diesem OS gemacht wurde).

Wichtig:
Wenn jetzt Partitionen gefunden wurden, kannst Du sie jeweils mit den Pfeiltasten anwählen und mit P deren Inhalt sichtbar machen. Mit Q geht es zurück ins Menü. Sollten keine Partitionen in der ersten Suche gefunden worden sein, wird mit Enter weiter gemacht, hier ist dann im Menü [ Quit ] [ Deeper Search ] [ Write ], die tiefere Suche mit Deeper SEARCH auszuwählen (dieser Vorgang kann dann schon eine Weile dauern).

Wenn jetzt Partitionen (sie sollten jetzt u.U. grün dargestellt werden) gefunden werden, solltest Du sie wieder mit den Cursor Tasten auswählen und mittels P deren Inhalt kontrollieren, also ob alle Daten sichtbar werden. Mit den Cursor-Tasten kann gescrolled werden. Aus dem Menü, beim listen des Inhalts kann man mit c Files und ganze Partitionen kopieren.

Nach jedem elementaren Schritt (also nach der ersten Analyse, nach dem Quick Search mit der Abfrage ob die Disk unter Vista eingerichtet wurde oder nicht und nach dem deeper SEARCH) solltest Du einen Screendump (oder Photo) machen und hoch laden, alternativ kann auch die Logdatei gepostet werden.

Bilder und andere Dateien kannst Du unter Anhänge verwalten (unter dem Edit Feld) hochladen.

Der Weg einer Diagnose ist hier recht anschaulich beschrieben.

Fiona hat auch den folgenden Artikel Beratung: Datenrettung mit „TestDisk“ verfasst, um den Usern das Programm etwas näher zu bringen.

Du solltest die Disk aber auch mal intern (im PC) mit dem Herstellertool testen um den Status der Disk zu überprüfen. Evtl. ist ja auch die Disk nicht das ursächliche Problem.

Evtl. könntest Du die beiden Disk's des NAS auch intern verbauen und sie virtuell zu einem RAID zusammen zu pappen, diverse Datenrettungstools aus dem Link können das, auch Linux ist dazu in der Lage (es erkennt die Zusammengehörigkeit teilweise automatisch - bin hier aber nicht wirklich im Thema - habe es aber beim ergoogeln eines anderen Problems vielfach lesen können).

 

[Ernst@at]

Wenn die Migrierung bereits begonnen hat, ist sicher ein Großteil der MFT weg und damit ohnehin das Filesystem stark beschädigt, bei NTFS belegt die MFT in der Standardeinstellung etwa bis 12% der Disk-Kapazität, je nach Füllgrad der Disk und Art der Dateien (kleine, große) ist sie u. U. komplett weg.

Eine Migration von non-RAID auf RAID0 wie jede andere RAID-Migration ändert absolut NICHTS am Inhalt des logischen Filesystemes.
In diesem Migrationsfall wird jedes ungerade Stripe (Stripe 1,3,5,..) hintereinander auf die neue Platte geschrieben, die geraden Stripes am dadurch freiwerdenden Platz der ursprünglichen Platte hinter dem Stripe 0 zusammengeschoben (Stripe 2 kommmt an Platz von Stripe 1, 4 an 2, 6 an 3...)
Wird dieser Vorgang unterbrochen - hier bei 4% - dann ist der Inhalt der unteren 4% 2% jeder HDD RAID0, und alles darüber auf der ersten Disk als Einzelplatte ansprechbar.

Von der Ursprungsplatte, als Einzelplatte untersucht, muss mit testdisk
- die Partitionierung aus dem MBR richtig ausgelesen werden können (da Stripe 0 noch an selber Stelle auf dieser Platte liegt)
- mit diesen Partitonsdaten über den Backup-Bootblock auf die $MFT zugegriffen werden können (wenn diese nicht in den ersten 4% liegt)
- Alles, was an Filesystem-Metadaten nicht innerhalb der ersten 4% liegt, und keine Datencluster innerhalb der ersten 4% liegen hat, unbeschädigt auslesbar sein.
nachträgliche Korrektur: Da die nach unten geschobenen geraden Stripes ja nur halb soviel Platz brauchen, ist 4% nicht korrekt - dadurch wird auch nur halb soviel - also 2% zerstört

Es gilt eigentlich nur, den genauen Abbruchpunkt festzustellen, was durch den Plattenfehler an einer bestimmten Sektoradresse ja nicht schwer sein kann. Dies muss mittels eines Platteneditors mit physischem Zugriff auf die Einzelplatten genau festgestellt werden (ab welcher Stripe-Grenzen- LBA?).

Eine "händische" Rekonstruktion des Gesamtvolumes müsste so laufen:
- zwei neue Platten besorgen
- mit linux-rescue-CD den Inhalt der beiden Platten 1 und 2 bis zum Abbruchpunkt auf die beiden neuen Einzelplatten 3 und 4 kopieren
- mit den neuen Platten 3 und 4 (in richtiger Reihenfolge) den RAID0 neu definieren
- den Rest (ab dem Stripe des Abbruckpunktes) von der Platte 1 auf den RAID0 kopieren

Es ginge mit nur einer zusätzlichen Platte 3 auch umgekehrt, um das Ursprungsvolume wiederherzustellen
- Inhalt bis zum Stripe des Abbruchpunktes von 1 auf 3 kopieren
- 3 und 2 als RAID0 definieren
- Inhalt bis zum Stripe des Abbruchpunktes auf 1 zurückkopieren
(diese zweite Methode ist recoverymäßig irreversibel, weil sie die Daten der Ausgangssituation verändert)

Die "russische" Methode wäre noch subtiler:
- Stripe 0 von der Platte 1, Stripe 1 von Platte 2 als Image sichern (von den Einzelplatten je ab Sektor 0)
- RAID0 definieren mit Platte 1 und 2
- 3% der Stripes auf Imagedatei abziehen (ergibt eine 30GB Datei irgendwo)
- Platte 1 als Einzelplatte
- Das 3% Image aufspielen (ab Stripe 2)
- die im ersten Step gesicherten Stripes 0 und 1 aufspielen

 

[Mueli]

Im Prinzip ist es schon so, wie Du geschrieben hast ändert aber nichts an meiner Aussage, nur für alle mir bekannten Tools gibt es Stress, das wieder herzustellen. Meine Beschreibung basiert auf dem Fakt, dass jeder zweite Block (von den 4%) eben schon auf der neuen Disk gelandet ist und auf der Ursprungsdisk eine Verschiebung der Blöcke bereits stattgefunden hat, damit wäre eine MFT, die i.d.R. am Anfang der Disk beginnt, dabei eine unbekannte reservierte Größe hat (mit dem Füllgrad der Disk, dann dynamisch expandiert wird), zerpflückt auch wenn man sie händisch mit viel Aufwand wohl wieder zusammen setzen kann, wenn man ein paar Parameter kennt.
Hier haben wir es wahrscheinlich mit einem Linux-Filesystem zu tun von dem ich eher weniger vom Aufbau kenne als jetzt z.B. von FAT oder NTFS!

Wenn man den genauen Abbruchpunkt heraus bekäme, könnte ich mir schon vorstellen, dass man mit mindestens einer weiteren doppelt so großen Festplatte, wie die derzeitigen Einzeldisks und dd unter Linux zusammen kopieren könnte. Dazu müsste man mindestens noch den Blockingfaktor kennen. Da Du hier im Forum ja bereits diverse RAID händisch zurecht gepfriemelt hast, hoffe ich mal auf ein gutes Gelingen.

 

[Ernst@at]

ooops - das mit dem ext3 hab ich überlesen.

Aber das Einfachste fällt einem ja leider immer zuletzt ein.
Da bei Fortschritt 4% (oder 3,5-4,5) ja die Hälfte auf der einen Platte und die andere Hälfte auf der anderen landet, hat man ja einen Spielraum für den Abbruchpunkt und kann ihn selbst wählen - da würde ich einfach 3% von maxLBA wählen.
Stripesize lässt sich schon irgendwie ermitteln, wenn man sich die Platten mal außerhalb des Gehäuses einzeln zur Brust nimmt...
Eigentlich ist sogar die Stripesize uninteressant, weil das Gehäuse immer dieselbe wählt

Die Frage ist nur, wie das NAS arbeitet - das hat doch einen echten RAID-Controller drin; per Software-RAID ließe sich auf diese Weise doch gar keine derartige inplace-Migration im laufenden Betrieb durchführen.

 

[Kletschmeister]

Vielen Dank für die antworten......

bis jetzt bin ich mir nicht mal sicher wie das Promise SmartStor NS2300 überhaupt das ganze verwaltet.
Gefunden habe ich folgende Infos:
http://www.promise.com/upload/datasheet/NS2300N_20090325.pdf
RAID Management
RAID Levels: RAID 0, 1
RAID features: Drive Roaming, Robust Error Handling, RAID Level Migration, On-line Capacity Expansion
File Systems: EXT3 Journal File System, Multi-Volume


R-Studio findet was auf der Platte (1) allerdings ist das Programm so Speicherintensiv das meine 4 GB innerhalb von 10 Sekunden weg gelutscht sind und die Daten die ich sehe sind eigentlich alle unbrauchbar.

Testdisk findet zwar Linux Partitionen aber auch nicht wirklich mehr sprich brauchbare Files...

ich bleibe mal notgedrunden am Ball... Danke auf jedenfall....

 

[Ernst@at]

Interessant wäre mal, zu wissen, in welcher Umgebung zur Recovery wir uns bewegen.
Da gibt es mal den NAS mit den zwei SATA-Platten drin.
Wie ist der PC ausgestattet? Oder nur Notebook?
Welches Board, gibt es einen Onboard-Raid-Controller?
Welche(s) Betriebssystem(e) ?
Wo hängen die NAS-Platten jetzt zur Inspektion dran?
Wieviel freie Plattenkapazität? Irgendwelche leeren verwendbaren SATA-Platten? (auch 2,5" 20GB HDDs sind willkommen)

Ergänzung (20. September 2009)

Die Reparatur des teilweise auf eine zweite Platte im RAID0 migrierten Volumes dürfte nicht so sehr das Problem sein, das kann vielleicht einfach von einem anderen PC mit einem onboard-RAID-Controller aus bewerkstelligt werden, wenn der NAS-Controller keine Extrawürsteln im RAID0-Format brät. Damit kann die partielle Aufsplittung der Stripes auf zwei Platten rückgängig gemacht werden.

Nach Wiederherstellung des ersten Volumes wird sich der so nicht mehr in das NAS einbinden lassen, weil die Metadaten da drauf(in unbekanntem Format) des NAS-RAID auf failed stehen.
Der Datenträger selbst mit seinen Filesystemen drauf wäre aber wieder ansprechbar, und so müssten sich die Benutzerdaten runterholen lassen und gleich auf eine neue Platte im NAS schieben lassen

Ergänzung (20. September 2009)

Der Fahrplan zur Wiederherstellung müsste also folgendermaßen aussehen:

Rekonstruktion der alten 1TB
- benötigt werden 2 SATA-Platten mit mindestens 20GB, und ein onboard RAID-Controller
- kopieren der bereits migrierten Stripes von der alten und neuen defekten 1TB auf diese beiden Platten per rescue CD mit dd_rescue
- Anlegen eines RAID0 über die beiden Hilfsplatten mit richtiger Stripesize
- von diesem RAID0-Volume kann die richtiggestellte (ursprüngliche) Sektoranordnung ausgelesen und zurück auf die erste 1TB übertragen werden
- dazwischen ist etwas Hexerei mit einem Editor nötig, um die Platte intakt zu machen

Danach entweder unter XP oder einer Linux Live-CD die Daten von der wiederhergestellten 1TB auf das NAS mit einer (oder 2) neuen Platten schieben

Die Moral von der Geschicht - für alle, die sich so ein NAS-Ding zulegen wollen oder schon haben:
- ein einzelnes NAS ist völlig sinn- und wertlos, wenn kein zweites (als Backup mit periodischer Aktualisierung) oder eine Sicherung (übers Netz pro 1TB mindestens 7 Stunden Dauer!) vorhanden ist
- jede noch so schöne Versprechung von problemloser Erweiterung im laufenden Betrieb in den bunten Werbebroschüren keinerlei Sicherheit bietet, dass die Daten eines Tages noch vorhanden sind
- Der Händler oder Hersteller in Fällen wie diesem auch keinerlei Support zur Schadensbehebung zu leisten imstande sein wird. Professionelle Datenretter freuen sich schon, für Euch arbeiten zu dürfen!

 

[Kletschmeister]

Also TestDisk findet oder sucht scheinbar anders als R-Studio und findet im Grund nichts brauchbares...
Werde mich jetzt mal mit R-Studio beschäftigen ansonsten baue ich mir ein Linux-System und werde mich mit den Tips von Euch auf eine lange Recoveryzeit einrichten....

 

[Ernst@at]

Ein eigenes Linux-System ist dazu nicht nötig - eine CD tut's auch
http://www.sysresccd.org/Main_Page

Wie man mit dem ddrescue (welches ich dafür am geeignetsten halte) arbeitet, ist in diesem Thread vorgehüpft worden

damit lässt sich am einfachsten ein Sektorbereich 1:1 kopieren; geht zwar mit dd auch, ich finde aber die Methode mit dem logfile zur Steuerung eleganter, zudem ist man gegen fehlerhafte Sektoren gewappnet, die vielleicht gerade dann auftreten, wenn man es am wenigsten brauchen kann...