NAS Datenrettung bei RAID0 und Bad Sectors

„Meine NAS ist tot, alle Daten weg.“ – Diesen Satz höre ich leider regelmäßig, wenn Leute mit einem kaputten NAS zu mir kommen. Was sie meist nicht wissen: Selbst wenn eine Festplatte physische Defekte hat und der RAID-Verbund nicht mehr automatisch startet, sind die Daten in vielen Fällen noch da. In diesem Artikel zeige ich dir Schritt für Schritt, wie ich bei einem realen Einsatz über 80 % der Daten von einem 2-Bay-NAS mit defekter Platte und zerstörtem RAID-Superblock gerettet habe – komplett mit Linux-Bordmitteln, ohne teures Reinraumlabor.

Die Ausgangslage: Was war defekt?

Das NAS in diesem Fall: ein handelsübliches 2-Bay-NAS mit zwei Festplatten à ~465 GB. Laut Hersteller-Dokumentation sollte es im RAID1-Modus (Spiegelung) laufen – also alle Daten doppelt vorhanden, kein Datenverlust bei einem Laufwerksausfall. Schön wäre es.

Die unangenehme Wahrheit steckt im Partition-Layout:

Kleine Partitionen: gespiegelt
Die eigentliche Daten-Partition: RAID0 (Striping)

Der Hersteller bewirbt das System als RAID1 – aber das gilt nur für Boot und System. Wo deine Fotos, Dokumente und Backups liegen, läuft im Stripe-Modus. Das bedeutet: Fällt eine Platte aus, sind theoretisch alle Daten unzugänglich – weil jede Datei auf beide Platten verteilt wird.

Gut zu wissen: Dieses Verhalten ist bei diversen günstigen 2-Bay-NAS-Systemen dokumentiert, bei denen der Hersteller „RAID1″ bewirbt, die Datenpartition aber intern als RAID0 konfiguriert. Wer sich auf „RAID1 = sicher“ verlässt, erlebt auf solchen Plattformen eine böse Überraschung.

Der konkrete Defekt: Laufwerk 1 hatte Bad Sectors am physischen Ende der Partition – genau dort, wo mdadm bei Version 0.90 seinen Superblock ablegt. Ergebnis: Der RAID-Metadatenblock auf der defekten Platte war zerstört, mdadm konnte das Array nicht automatisch zusammensetzen. Laufwerk 2 war vollständig intakt mit lesbarem Superblock.

Warum ist RAID0-Datenrettung trotzdem möglich?

RAID0 verteilt Daten in sogenannten Chunks (hier: 64 KB) abwechselnd auf alle Mitglieds-Platten. Wenn eine Platte physisch lesbar ist, aber nur der Superblock fehlt, sind die eigentlichen Nutzdaten darauf meist noch vorhanden. Das einzige, was fehlt, sind die RAID-Metadaten, die mdadm normalerweise braucht, um das Array zu assemblieren.

Der Trick: Mit mdadm --build lässt sich ein RAID-Array ohne Superblock manuell aufbauen – vorausgesetzt, du kennst die Parameter (Level, Chunk-Size, Geräte-Reihenfolge). Die stehen nämlich noch auf der intakten Platte.

Schritt 1: Laufwerke identifizieren

Beide Platten wurden an einen Linux-Rechner angeschlossen – die gesunde Platte per USB-SATA-Adapter, die defekte intern. Mit lsblk prüfen, welche Gerätenamen zugewiesen wurden:

lsblk

In diesem Fall:

• sdg → Laufwerk 1 (defekt, intern)
• sdh → Laufwerk 2 (gesund, USB-Adapter)

Wichtig: Notiere dir die Gerätepfade genau. Beim Neustart oder Umstecken können sich die Buchstaben ändern.

Schritt 2: RAID-Metadaten auslesen

Zuerst die intakte Platte untersuchen, um alle Parameter zu sichern:

sudo mdadm --examine /dev/sdh6 > /tmp/sdh6_examine.txt
sudo mdadm --examine /dev/sdg6 > /tmp/sdg6_examine.txt

Ausgabe von sdh6 (die gesunde Platte):

RAID Level: raid0
Chunk Size: 64K
UUID:       xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
Device 0:   Major 8, Minor 6   → sda6 im NAS = Laufwerk 2 (sdh6)
Device 1:   Major 8, Minor 22  → sdb6 im NAS = Laufwerk 1 (sdg6)

Ausgabe von sdg6 (die defekte Platte):

mdadm: No md superblock detected on /dev/sdg6.

Wir wissen jetzt: RAID0, Chunk 64K, und welches Gerät in welcher Reihenfolge als Device 0 und Device 1 eingebunden war. Diese Reihenfolge ist entscheidend – beim Stripe-Modus muss sie exakt stimmen, sonst ist das Dateisystem korrupt.

Schritt 3: RAID0 manuell assemblieren (ohne Superblock)

Da der Superblock auf Laufwerk 1 fehlt, schlägt mdadm --assemble fehl. Stattdessen verwenden wir --build, das alle Parameter manuell entgegennimmt:

sudo mdadm --build /dev/md0 \
  --level=0 \
  --raid-devices=2 \
  --chunk=64 \
  /dev/sdh6 /dev/sdg6

Erwartete Ausgabe:

mdadm: array /dev/md0 built and started.

Reihenfolge der Geräte:sdh6 muss zuerst stehen (= Device 0 laut Metadaten), sdg6 kommt zweiter (= Device 1). Vertauschst du sie, mountet das Dateisystem zwar möglicherweise, alle Dateien sind aber unlesbar oder kaputt.

Schritt 4: Dateisystem prüfen und read-only mounten

Bei diesem NAS liegt kein LVM vor – XFS liegt direkt auf dem RAID0-Device. Mount-Befehl mit zwei wichtigen Flags:

sudo mkdir -p /mnt/nas
sudo mount -t xfs -o ro,norecovery /dev/md0 /mnt/nas

Flag-Erklärung:

• ro → Read-only: Kein versehentlicher Schreibzugriff auf das defekte Array
• norecovery → Journal-Recovery überspringen: XFS versucht nicht, beschädigte Journal-Einträge nachzuspielen – wichtig bei Bad Sectors

Nach erfolgreichem Mount waren folgende Verzeichnisse sichtbar:

Dokumente  Archiv  Outlook  Backup  Privat  share  spool

Gesamtgröße der vorhandenen Daten: ~361 GB

Schritt 5: Daten mit rsync sichern

Jetzt kommt die eigentliche Rettung: rsync überträgt alle Daten auf ein externes Backup-Laufwerk. Der entscheidende Unterschied zu einem normalen Kopiervorgang: --ignore-errors und --timeout verhindern, dass das Tool bei einem Bad Sector komplett abstürzt.

sudo rsync -av \
  --ignore-errors \
  --timeout=30 \
  /mnt/nas/ \
  /run/media/user/BACKUP/NAS-Recovery/ \
  >> /tmp/rsync_log.txt 2>&1 &

Was die Flags bewirken:

Was tun, wenn rsync abstürzt (Broken Pipe)?

Bei schlimmen Bad Sectors friert die Leseoperation ein und rsync bekommt eine Broken Pipe. Einfach denselben Befehl erneut ausführen – rsync überspringt bereits kopierte Dateien automatisch (Größe + Timestamp-Vergleich).

Schritt 6: Fortschritt überwachen

# Kopierte Datenmenge gesamt:
du -sh /run/media/user/BACKUP/NAS-Recovery/

# Live-Anzeige alle 10 Sekunden:
watch -n 10 'du -sh /run/media/user/BACKUP/NAS-Recovery'

# Laufende rsync-Prozesse:
ps aux | grep rsync | grep -v grep | wc -l

# Letzte Log-Einträge:
tail -20 /tmp/rsync_log.txt

# Fehler-Übersicht:
grep "error\|failed\|IO" /tmp/rsync_log.txt

Welche Fehler traten auf – und warum?

Nicht rettbar waren hauptsächlich temporäre Cache-Dateien und Installations-Archivdateien – also genau der Datenmüll, den niemand wirklich braucht. Produktive Arbeitsdaten, Dokumente und wichtige Dateien waren zu über 80 % vollständig lesbar.

Aufräumen nach der Rettung

# NAS unmounten:
sudo umount /mnt/nas

# RAID-Array stoppen:
sudo mdadm --stop /dev/md0

Vollständige Befehlsreferenz auf einen Blick

# 1. Laufwerke identifizieren
lsblk

# 2. RAID-Metadaten sichern
sudo mdadm --examine /dev/sdh6 > /tmp/sdh6_examine.txt
sudo mdadm --examine /dev/sdg6 > /tmp/sdg6_examine.txt

# 3. RAID0 ohne Superblock assemblieren
sudo mdadm --build /dev/md0 \
  --level=0 \
  --raid-devices=2 \
  --chunk=64 \
  /dev/sdh6 /dev/sdg6

# 4. XFS read-only mounten
sudo mkdir -p /mnt/nas
sudo mount -t xfs -o ro,norecovery /dev/md0 /mnt/nas

# 5. Backup mit rsync starten
sudo rsync -av --ignore-errors --timeout=30 \
  /mnt/nas/ /run/media/user/BACKUP/NAS-Recovery/ \
  >> /tmp/rsync_log.txt 2>&1 &

# 6. Aufräumen
sudo umount /mnt/nas
sudo mdadm --stop /dev/md0

Wichtige Hinweise und Lessons Learned

mdadm-Superblock v0.90 liegt am Partitionsende

Ältere NAS-Systeme nutzen häufig mdadm-Superblock-Version 0.90. Diese Version legt den Superblock an das Ende der Partition – genau der Bereich, der bei alternden Festplatten als erstes Lesefehler entwickelt. Neuere Superblock-Formate (1.x) legen ihn an den Anfang und sind daher robuster.

RAID0 braucht beide Platten – immer

Das klingt selbstverständlich, wird aber regelmäßig vergessen: Bei RAID0 ist jede einzelne Datei auf beide Laufwerke verteilt. Eine einzige kaputte Platte bedeutet, dass theoretisch keine einzige Datei mehr vollständig lesbar ist. In der Praxis sieht es besser aus, wenn die defekte Platte noch physisch lesbar ist und nur der Superblock fehlt – wie in diesem Fall.

norecovery beim XFS-Mount ist Pflicht

Ohne norecovery versucht XFS, sein Journal abzuarbeiten. Bei einem beschädigten Dateisystem kann das dazu führen, dass weitere Metadaten überschrieben werden. Immer -o ro,norecovery verwenden, wenn du ein XFS-Dateisystem von einem defekten Array liest.

Niemals auf dem Original schreiben

Das klingt banal, ist aber die häufigste Ursache für dauerhaften Datenverlust bei Heimanwendern: Versuche, das NAS einfach neu zu initialisieren oder die Festplatte zu formatieren, überschreiben die noch vorhandenen Daten unwiederbringlich. Im Zweifelsfall erst ein vollständiges Image mit ddrescue ziehen, dann auf dem Image arbeiten.

Wann solltest du zum Profi?

Diese Methode funktioniert, wenn:

• Beide Platten physisch noch lesbar sind (auch wenn eine Bad Sectors hat)
• Der Superblock nur auf einer Platte fehlt
• Die RAID-Parameter (Level, Chunk, Gerätereihenfolge) noch ausgelesen werden können
• Du Zugang zu einem Linux-System hast

Zum Spezialisten (Reinraumlabor) solltest du, wenn:

• Eine Platte physisch nicht mehr anspringt (klackerndes Geräusch, kein Spin-Up)
• Beide Platten beschädigt sind
• Die Daten geschäftskritisch sind und du dir keine Fehler leisten kannst

Fazit: RAID0-Datenrettung ist möglich – aber kein Dauerzustand

Diese Rettungsaktion war erfolgreich, weil die defekte Platte noch mechanisch arbeitete und nur der Superblock fehlte. Mit mdadm --build, einem sauberen Read-only-Mount und rsync konnten weit über 80 % der Daten gerettet werden – ohne Reinraumlabor, ohne kostenpflichtige Software, nur mit Linux-Bordmitteln.

Die eigentliche Lektion ist eine andere: RAID ist kein Backup. Wer sich auf ein NAS mit RAID0 als einzige Datensicherung verlässt – vor allem wenn der Hersteller das als „RAID1″ vermarktet – lebt gefährlich. Ein externes Backup auf ein separates Laufwerk oder in die Cloud ist und bleibt Pflicht.