Daten-Crash beim Kopieren zwischen zwei NAS-Systemen

Ein Leser wollte Daten von einem in die Jahre gekommen NAS-System auf ein Neues überspielen. Der Windows-Explorer entpuppte sich allerdings als kein zuverlässiges Kopierwerkzeug für große Datenmengen. Es kam zum Daten-Crash, inklusive einem beschädigtem Dateisystem.

Doc Storage sieht bestenfalls eine minimale Chance, die Daten wiederherzustellen.

Anzeige

Leserfrage: Ich setze zwei Netgear ReadyNAS 6 Pro ein. Das eine System läuft seit fünf Jahren bei mir. Nun habe ich mir ein weiteres angeschafft, um meine Daten vom PC auszulagern und zu sichern.

Ich habe den NAS mit 3x 6-TByte-HDDs bestückt, eine vierte war auf dem Postweg zu mir. Nachdem ich den NAS eingerichtet hatte, markierte ich alle Verzeichnisse mit dem Windows 10 Explorer und gab den Auftrag, diese zu kopieren. Dies sollte über Nacht geschehen.

Als ich morgens wieder an den PC ging, fand ich eine Fehlermeldung vor: Der Speicher ist voll…. Die Festplatten im NAS reichten wohl nicht aus, also brach ich die Aktion ab. Dann wollte ich schauen, ob die anderen Daten denn wenigsten auf dem NAS sind. Und da war das Problem.

Ich habe Zugriff auf den NAS, aber keinen Zugriff auf die Shares BACKUP und MEDIA. Das Protokoll und die Fehlermeldung habe ich angehängt.

Als die vierte Platte kam, habe ich diese in den NAS eingesetzt. Sie wird auch erkannt, aber nicht hinzugefügt.

Besteht eine Chance an die Daten auf dem NAS zu kommen? Für Vorschläge wäre ich dankbar.

Antwort Doc Storage:

DocStorage2014 thumb

Im Dateisystem-Check steht »UNEXPECTED INCONSISTENCY«, und man soll manuell checken. Weiterhin steht da »Group descriptor 26688 checksum is 0x0000, should be 0x968a«. Also sind die Einträge im Dateisystem ungültig. Dies wird durch den Eintrag »Unrecovered read error – auto reallocate failed« und weitere im Kernel-Log bestätigt. Darauf folgt eine Serie von zehn Lesefehlern auf der Disk md2, worauf die gesamte Checksumme der RAID-Gruppe falsch ist. Die ATA-Disk 4 verweigert den Dienst, auch nach mehrfachem Wiederanstarten des Kanals »START_STOP FAILED«. Im System-Log, wo am 19. Mai um 14:47 Uhr das Hinzufügen der neuen Platte verzeichnet ist, schlägt sich das mit der Meldung »sdd: unknown partition table« nieder.

Ohne viel Hoffnung machen zu wollen, sollte über die Schnittstelle des NAS das bzw. die Dateisysteme überprüft werden. Ohne eine solche Überprüfung und die dadurch neu zusammengestellten Dateieintragstabellen wird es nicht möglich sein, die auf dem Gerät gespeicherten Daten zurückzuholen.

Hardware-seitig scheint alles in Ordnung, die Platten sda bis sdd (Disk 1 bis 4) sind korrekt erkannt und im RAID 5 eingebunden. Sollte die manuelle Überprüfung des Dateisystems nicht möglich sein oder fehlschlagen, besteht nur noch eine Möglichkeit – Einschicken des Gerätes zum Hersteller mit der Bitte, die Dateisysteme wiederherzustellen und damit die gespeicherten Daten zu retten. Da es sich bei den intern verwendeten Dateisystem (ext3) um eines handelt, welches von »normalen« Windows-Rechnern nicht erkannt wird, ist eine Rettung über häusliche »Bordmittel« kaum möglich und sollte auch erst gar nicht versucht werden. Selbst das Anhängen der vier Platten an einen Linux-Rechner dürfte wenig bringen, da sich, wenn überhaupt, in diesem Rechner nicht derselbe RAID-Controller befinden dürfte wie im NAS-System. Damit ist der organisierte Zugriff auf die gespeicherten Daten ohne ein Zutun des Herstellers kaum möglich.

Es tut mir leid, dass ich keine bessere Nachricht habe…

Gruß
Doc Storage

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.