Home NAS & RAID (Synology/QNAP/TrueNAS): gelöschte Daten und ein degradiertes Array sicher wiederherstellen (2026)

Ein Home-NAS wirkt wie „einmal einrichten, dann vergessen“ – bis plötzlich eine Platte ausfällt, das Volume als „degradiert“ angezeigt wird oder jemand den falschen Ordner im Netzwerk löscht. In vielen Fällen ist nicht der erste Fehler das Problem, sondern der zweite: ein Rebuild auf die falsche Disk, ein vorschnelles Neuinitialisieren, eine „Reparatur“, während noch Schreibzugriffe laufen, oder ein Tausch der Laufwerke ohne saubere Dokumentation. Dieser Leitfaden beschreibt einen pragmatischen, vorsichtigen Ablauf, der 2026 auf Synology, QNAP und TrueNAS in der Praxis funktioniert: Schaden stoppen, Zustand sichern, Kopien erstellen – und erst dann entscheiden, ob ein Rebuild, ein Snapshot-Rollback oder eine Dateiwiederherstellung sinnvoll ist.

Sofortmassnahmen: Schreibzugriffe stoppen, Zustand sichern, Automatik-Fixes vermeiden

Regel Nummer eins: Neue Schreibzugriffe so weit wie möglich reduzieren. Jeder Schreibvorgang kann gelöschte Dateien überschreiben (besonders bei bestimmten Share- und Volume-Konfigurationen) und er kann ein ohnehin wackliges RAID zusätzlich belasten. Pausiere daher Backup-Jobs, Sync-Clients, Medien-Indexierung, Download-Tools sowie Container- oder VM-Workloads. Wenn das NAS noch erreichbar ist, bringe es in einen „read-mostly“-Zustand: iSCSI-Targets trennen, Shares von Clients aushängen und Dienste deaktivieren, die dauerhaft kleine Writes erzeugen (z. B. Thumbnailing, aggressive Indexer, Logging mit hoher Frequenz). Bei Verdacht auf Malware oder Ransomware: Netzwerkverbindung trennen und nichts „aufräumen“, bevor klar ist, was passiert ist.

Regel Nummer zwei: Dokumentiere den Ist-Zustand, bevor du Hardware anfasst. Mache Screenshots vom Storage-Status, der Disk-Liste, dem RAID/Pool-Layout und allen Warnungen. Exportiere Logs, wenn möglich, denn sie zeigen oft, welche Platte zuerst Timeouts hatte und ob es Hinweise auf Metadaten-Fehler gibt. Notiere auch Firmware-/OS-Version und Build, weil sich Verhalten und Optionen je nach Version deutlich unterscheiden können – das hilft später beim Einordnen von Symptomen.

Regel Nummer drei: Starte keinen Rebuild und keine „Repair“-Funktion nur, weil ein Button da ist. Ein Rebuild schreibt Parität und Metadaten quer über das Array. Wenn in Wahrheit mehrere Disks grenzwertig sind, die Disk-Reihenfolge nicht sauber ist, stille Korruption vorliegt oder du gelöschte Daten noch retten willst, kann ein Rebuild Optionen unwiederbringlich reduzieren. Behandle Rebuild als späten Schritt – idealerweise erst, wenn du verifizierte Images der Mitgliedsdisks (oder eine saubere, überprüfte Snapshot-/Replik-Kopie des Datensatzes) hast.

So erkennst du schnell: Löschung, Filesystem-Schaden oder Hardware-Problem?

Die Symptome helfen beim Einordnen. Eine versehentliche Löschung wirkt oft „sauber“: Das NAS läuft stabil, die Disks scheinen gesund, aber ein Share/Ordner ist weg und der freie Speicher ist plötzlich höher. Ein degradiertes RAID zeigt typischerweise eine als „failed/removed“ markierte Disk oder wiederkehrende Read-Errors in den Logs; häufig werden Zugriffe spürbar langsamer. Filesystem-Probleme fallen eher durch Mount-Fehler, Read-only-Remounts, wiederholte „metadata“-Meldungen oder einen Pool auf, der zwar erkannt wird, dessen Datasets aber nicht sauber online kommen.

SMART solltest du so bewerten, wie es ein Rebuild tatsächlich belastet. Ein kurzer Test kann „OK“ melden, obwohl eine Disk bei Dauerlast aussteigt. Achte besonders auf: Reallocated Sector Count, Current Pending Sector, Offline Uncorrectable sowie UDMA-CRC-Fehler (oft Kabel/Backplane). Wenn Pending/Uncorrectable Werte steigen oder Timeouts im Log auftauchen, ist Klonen meist wichtiger als „noch schnell rebuilden“, weil ein Rebuild ein Voll-Scan mit Dauerlesen ist – genau das, was marginale Disks häufig endgültig kippen lässt.

Wichtig ist auch, was „degradiert“ in deinem Stack bedeutet. Viele Synology- und QNAP-Systeme nutzen intern Linux-RAID (mdadm), oft kombiniert mit LVM; darüber liegt dann ext4 oder Btrfs. TrueNAS arbeitet mit ZFS: Ein Pool kann degradiert weiterlaufen, aber ein Resilver ist ebenfalls schreib- und leseintensiv und kann latente Sektorfehler auf älteren Disks sichtbar machen. In solchen Momenten ist Stabilität wichtiger als „Optimieren“: Daten sichern, dann erst Firmware- oder Strukturänderungen.

Sicherungsnetz bauen: Snapshots, Klone und Read-only-Strategien zur Datenextraktion

Wenn Snapshots aktiv sind, sind sie bei „Ordner versehentlich gelöscht“ meist der risikoärmste Weg. Gibt es einen Snapshot von vor der Löschung, ist ein Restore oder ein Clone in vielen Fällen sicherer als jede Low-Level-Recovery. Der saubere Ansatz ist: zuerst in einen neuen Zielordner oder ein separates Dataset wiederherstellen, prüfen, und erst danach entscheiden, ob du etwas zurückkopierst oder ersetzt.

Wenn keine Snapshots existieren (oder der Pool instabil ist), ist Disk-Imaging der nächste sinnvolle Schritt. Ziel: sektorweise Images der Mitgliedsdisks erstellen – oder zumindest zuerst von den Disks, die auffällig sind. Die Recovery läuft dann auf den Images, nicht auf den Originalen. Das schützt dich vor dem Klassiker „ein Neustart zu viel“ und erlaubt mehrere Rekonstruktionsversuche, ohne die Hardware weiter zu stressen. Nimm ein Imaging-Verfahren, das mit Bad Sectors kontrolliert umgehen kann (definierte Retries, sauberes Logging, klare Fehlerberichte).

Wenn du Dateien möglichst ohne Veränderung herausziehen willst, setze auf Read-only-Assembly. Bei mdadm-Setups bedeutet das: Array aus Images bzw. Disks in einem Recovery-System read-only zusammensetzen und das логische Volume read-only mounten. Bei ZFS: Pool/Dataset read-only importieren (oder aus Kopien importieren) und Daten auf ein separates Ziel extrahieren. Entscheidend: Das Zielmedium muss ein anderes Storage sein – zweite NAS, externe Disk oder ein Backup-Ziel – niemals „zurück in denselben degradierten Pool“.

Typische Stolperfallen, die Recoverability leise zerstören

Der häufigste Fehler: Disk tauschen und den automatischen Rebuild laufen lassen, bevor es sichere Kopien gibt. Fast genauso häufig: Disk-Reihenfolge verwechseln. Beschrifte Bays/Trays, notiere Seriennummern und halte fest, welche Disk wo saß. „Merke ich mir“ endet in der Praxis oft mit Rätselraten – und RAID-Rekonstruktion hasst Rätselraten.

Eine tückische Falle sind Dialoge wie „initialisieren“, „neues Volume erstellen“ oder „formatieren“, wenn das NAS etwas nicht mounten kann. Diese Optionen sind für Provisioning gedacht, nicht für Recovery. Wenn die Oberfläche vorschlägt, einen Pool „neu anzulegen“, ist das meist das Signal, sofort zu stoppen und auf Offline-Recovery umzuschalten. Auch „Filesystem reparieren“ kann Metadaten umschreiben und damit die Chance auf gelöschte Dateien senken.

Ebenfalls gefährlich: das NAS weiter normal nutzen „bis am Wochenende“. Hintergrundprozesse wie Indexer, Scrubs, Dedupe, Snapshot-Pruning oder VM-Workloads können genau die Blöcke verändern, die du später noch brauchst. Wenn du nicht sofort recovern kannst, friere das System zumindest ein: Writes minimieren, nicht essentielle Jobs stoppen, und erst nach Protokoll-/Status-Sicherung kontrolliert herunterfahren.

Tools, die zu Hause realistisch sind: von Bordmitteln bis zu spezialisierten RAID-Recovery-Programmen

Beginne mit Bordmitteln, weil sie bei richtiger Nutzung am wenigsten riskant sind. Bei Löschung: Recycle-Bin-Einstellungen (falls aktiv), Snapshot-Stände und Replikationsziele prüfen. Bei degradiertem RAID: herausfinden, ob die Disk wirklich defekt ist oder ob es ein transienter Fehler war (Strom, Backplane, Kontakt, Kabel). Manchmal hilft ein korrektes Neu-Erkennen – aber: erst dokumentieren, dann handeln, weil Reboots den Status „wer ist active member“ verändern können.

Wenn du tiefer gehen musst, sind spezialisierte Recovery-Tools das, was viele Heimanwender und kleine IT-Teams tatsächlich nutzen. Typische Fähigkeiten: Disk-Images erstellen, NAS-typische RAID-Layouts erkennen, Arrays virtuell aus Images zusammensetzen und Dateien in ein sicheres Ziel exportieren. Das wichtigste Kriterium ist, dass du auf Kopien arbeitest – nicht, dass du „schnell irgendwas scannst“, während die Originaldisk bereits Fehler wirft.

Es gibt aber klare Grenzen für DIY. Wenn mehrere Disks klicken, aussteigen oder wiederholt Read-Errors liefern, bist du in einem Bereich, in dem ein Rebuild die Lage verschlimmern kann. Wenn die Daten wirklich wertvoll sind und mehr als eine Disk auffällig ist, ist es oft klüger, früh zu stoppen und professionelle Datenrettung in Betracht zu ziehen, statt mit Trial-and-Error die letzten guten Reads zu verbrauchen. DIY funktioniert am besten, wenn deine Schritte reversibel bleiben und du grenzwertige Hardware nicht unnötig unter Dauerlast setzt.

Entscheidungsbaum: Welche Route ist in der ersten Stunde sinnvoll?

Ordner gelöscht, NAS sonst gesund: zuerst Snapshots prüfen. Wenn vorhanden, in ein neues Ziel wiederherstellen und verifizieren. Wenn keine Snapshots existieren, Schreibzugriffe stoppen und Recovery von Images planen – jede zusätzliche Schreiblast verschlechtert die Chancen.

Array degradiert, System stabil, nur eine Disk wirkt auffällig: Logs sichern, SMART prüfen, zuerst die riskante Disk (oder idealerweise alle Disks) image-basiert klonen. Erst wenn Images existieren, über Disk-Tausch und Rebuild/Resilver nachdenken. Wenn SMART sauber ist, aber CRC-/Disconnect-Hinweise auftauchen, zuerst Sitz/Backplane/Cabling prüfen, bevor du das Array mit einem Rebuild durchbelastest.

NAS instabil, Boot-Loops oder mehrere Disks mit Fehlern: nicht ständig power-cyclen. Priorität hat Imaging mit kontrollierten Retries (ggf. Disks ausbauen und in einer Workstation klonen), danach Rekonstruktion auf Kopien. In diesem Stadium sind read-only Workflows und virtuelle Assembly-Tools oft sicherer als die NAS-Oberfläche, weil du jede Schreiboperation unter Kontrolle hast und jederzeit zu den Images zurückkehren kannst.