Erfolgreiche Datenrettung

Die Situation

Rekonstruktion eines 20-Laufwerk-RAID-6-Arrays aus einem NAS im Labor von ITHOPE Brno — eine DeepSpar-Klonstation mit parallel laufenden Laufwerken
Paralleles Klonen aller 20 Laufwerke aus dem Enterprise-NAS — Imaging auf Sektorebene über den DeepSpar Disk Imager.

Der Kunde — ein mittelständisches Ingenieurbüro — nutzt ein NAS mit 20 Laufwerken im RAID 6 (zwei Parität, verträgt den gleichzeitigen Ausfall zweier Laufwerke) für CAD-Dokumentation, historische Projekte und Buchhaltungs-Backups. Array-Kapazität: 160 TB, effektiv rund 130 TB. Alter des Arrays: 4 Jahre.

Was passiert ist:

  1. Montagmorgen — das NAS meldet einen Ausfall von Laufwerk #7. Der Admin bestellt einen Ersatz und plant einen Rebuild über Nacht.
  2. Dienstagmorgen — noch vor Eintreffen des Ersatzlaufwerks meldet das NAS den Ausfall eines weiteren Laufwerks, #12. Das Array befindet sich im Zustand degraded-critical (null Toleranz für einen weiteren Verlust).
  3. Dienstagnachmittag — nach Eintreffen der Ersatzlaufwerke startet der Rebuild. Nach 30 Stunden bleibt der Rebuild auf einem fehlerhaften Sektor von Laufwerk #5 hängen (dieses war „gesund”, doch unter der Intensität des Rebuilds traten fehlerhafte Sektoren aus der Oberfläche zutage).
  4. Mittwoch — das NAS ist offline, das Array mit gewöhnlichen Mitteln not recoverable.

Warum es ins Labor musste

Der Standard-Rebuild scheiterte. Ein ddrescue-Versuch hätte Wochen gedauert (Copy-on-Read der gesamten 20-TB-Laufwerke) und hätte dennoch nichts garantiert, denn die Parity Recovery hätte erneut die fehlerhaften Sektoren ansprechen müssen.

Die Lösung: Klonen aller 20 Laufwerke auf Sektorebene, Offline-Paritätsanalyse, Rekonstruktion des Dateisystems.

Was wir gemacht haben

  1. Tag 1–2: Annahme des NAS, Fotodokumentation, Kennzeichnung der Laufwerke nach Position. Die Laufwerke haben wir so wenig wie möglich berührt.
  2. Tag 3–5: Klonen aller 20 Laufwerke über den DeepSpar Disk Imager. Laufwerk #5 und Laufwerk #7 hatten eine schlechte Oberfläche und wurden in mehreren Durchläufen mit unterschiedlicher Strategie geklont (forward, reverse, reading multiple times).
  3. Tag 6–7: Offline-Paritätsanalyse an unserer Rekonstruktionsstation. Bestimmung des korrekten Stripe-Offsets (das NAS nutzte ein proprietäres Layout) und der tatsächlichen Laufwerksreihenfolge.
  4. Tag 8–9: Virtuelle Rekonstruktion des Arrays aus den Klonen, Auslesen der Daten auf Staging-Storage (120 TB SATA RAID 10).
  5. Tag 10: Der Kunde kam in unsere Filiale und sah sich die Ordnerstruktur und den Inhalt an. 100% Integrität, kein einziger Fehler in den entscheidenden CAD-Dateien.
  6. Tag 11: Übergabe der Daten auf neue Enterprise-Laufwerke, die der Kunde mitbrachte. Disk Wipe auf unserem Staging-Storage. Der Kunde fuhr mit einem vollen NAS davon und nahm das alte NAS außer Betrieb.

Das Ergebnis

  • 100 % der Daten wiederhergestellt (der Kunde prüfte zufällig ausgewählte CAD-Projekte aus 2020, 2022 und 2024 — alles ließ sich ohne Beschädigung öffnen)
  • 11 Tage Laborarbeit
  • 0 Tage war der Kunde ohne Zugriff auf die Daten — in den ersten 3 Tagen zogen wir die aktuellen Projekte der Priorität A aus den geklonten Bereichen als Quick Win heraus

Lehren für den Kunden

  • RAID 6 ist kein Backup. Es ist ein Schutz gegen den Ausfall eines Laufwerks, nicht gegen den Ausfall des Arrays.
  • Der Rebuild ist der gefährliche Moment. Das intensive Lesen der gesamten Oberfläche bei Laufwerken, die 3–4 Jahre alt sind, deckt fehlerhafte Sektoren auf.
  • Ein regelmäßiger Scrub (Synology, QNAP, ZFS) identifiziert fehlerhafte Sektoren, bevor es zu einem Rebuild-Fehler kommt.
  • Ein Offsite-Backup ist eine Notwendigkeit. Heute hat der Kunde ein Veeam-Backup auf unserer Infrastruktur + rotierende USB-Laufwerke.

Haben Sie einen ähnlichen Fall? RAID/NAS-Datenrettung anfragen · +420 775 556 063