Sie haben in Ihrem Synology‑SHR‑Array eine 4‑TB‑Festplatte durch eine 8‑TB‑Festplatte ersetzt. Der Wiederaufbau (Rebuild) begann, lief eine Zeitlang — und brach dann ab. DSM zeigt Degraded, Crashed oder der Fortschrittsbalken hat sich seit Stunden nicht mehr bewegt. Das NAS kann dabei vollständig nicht mehr reagieren. Dieser Artikel behandelt die Datenrettung nach einem Absturz des SHR‑Wiederaufbaus: was im Array tatsächlich passiert ist, wie Sie den aktuellen Zustand auslesen, ohne die Lage zu verschlimmern, und wie Sie Ihre Dateien wiederherstellen.
Bevor Maßnahmen ergriffen werden
Drei Maßnahmen erscheinen naheliegend, wenn ein RAID‑Wiederaufbau einfriert — und alle drei können aus einer noch behebbaren Situation einen dauerhaften Datenverlust machen:
Neustart des NAS
Ein degradiertes Array hält den Zustand seiner Mitglieder im Arbeitsspeicher. Ein Neustart veranlasst mdadm, die Superblöcke von den Datenträgern neu einzulesen — sind diese Superblöcke aufgrund eines unterbrochenen Wiederaufbaus nicht synchron, kann es nach dem Neustart vorkommen, dass sich das RAID‑Array überhaupt nicht mehr zusammenbauen lässt.
Laufwerke entfernen
Auch ein von DSM als „fehlerhaft“ markiertes Laufwerk kann betroffen sein. Das Entfernen eines Array‑Mitglieds verändert die Anzahl der Geräte im RAID‑Array und veranlasst mdadm, die Superblöcke auf den verbleibenden Laufwerken zu aktualisieren; die Entfernung wird dabei als permanentes Ereignis protokolliert. Dadurch kann ein tatsächlich lesbares Laufwerk dauerhaft aus dem RAID ausgeschlossen werden.
Klick auf „Reparieren“ im Storage Manager
Die Aktion „Reparieren“ startet einen erneuten Wiederaufbauversuch. Wenn der ursprüngliche Wiederaufbau aufgrund von Lesefehlern auf einem vorhandenen Laufwerk fehlgeschlagen ist, liest ein zweiter Versuch dieselben Sektoren erneut — wodurch die Schäden an einem bereits stark belasteten Laufwerk zunehmen und ein weiterer Ausfall drohen können.
Erzwungenes Ausschalten
Ein plötzlicher Stromausfall auf dem NAS während eines aktiven (auch eingefrorenen) RAID‑Wiederaufbaus kann teilweise Paritätsblöcke auf das neue Laufwerk schreiben und das Array in einen Zustand versetzen, in dem weder die alten noch die neuen Daten konsistent sind. Verwenden Sie stets das Herunterfahren über die DSM‑Weboberfläche (DiskStation Manager), wenn die Benutzeroberfläche noch erreichbar ist.
Ausführen von fsck oder btrfs check
Werkzeuge zur Dateisystemreparatur arbeiten auf der Volume-Ebene — eine Schicht oberhalb des RAID-Arrays. Werden sie auf einem degradierten Array ausgeführt, lesen sie rekonstruierte Daten, die Paritätsfehler enthalten können, und schreiben beschädigte Metadaten zurück auf die Datenträger.
Ein weiteres Laufwerk einsetzen
Das Einsetzen eines Ersatzlaufwerks in ein ausgefallenes RAID-Array veranlasst DSM zu einem automatischen RAID‑Wiederaufbau. Ohne die Ursache des ersten fehlgeschlagenen Wiederaufbaus zu kennen, stößt ein zweiter Versuch auf dasselbe Problem — und führt zudem zu einer weiteren Runde vollständiger Lesezugriffe über das gesamte Array auf bereits stark belasteter Hardware.
Warum der Wiederaufbau fehlgeschlagen ist
Wenn SHR eine Festplatte mit abweichender Kapazität ersetzt, erfolgt weit mehr als eine einfache Datenkopie. Der Ablauf sieht folgendermaßen aus:
mdadm liest alle Datenpartitionen von den verbleibenden Laufwerken mit konstant hohem sequenziellem Durchsatz — über Stunden oder Tage bei Multi‑Terabyte‑Arrays.
Parität wird berechnet und geschrieben auf das neue Laufwerk. Bei SHR mit gemischten Plattengrößen verwendet mdadm mehrere md‑Geräte unterschiedlicher Größe, die kombiniert betrieben werden, sodass die Paritätsberechnung komplexer ist als bei einem RAID‑5 mit fester Geometrie.
LVM berechnet die Zuweisung der Physical Extents im erweiterten Speicherpool neu. Ist die neue Festplatte größer, bedeutet das ein Remapping des Volume‑Group‑Layouts — eine eigenständige Operation, die parallel zum mdadm‑Wiederaufbau läuft oder anschließend ausgeführt wird.
Ein Fehler in einem beliebigen Schritt bricht den Ablauf ab. Drei Ursachen sind für die Mehrzahl der SHR‑Wiederaufbau‑Fehler verantwortlich:
Nicht behebbarer Lesefehler (URE)
Consumer-Laufwerke weisen eine URE-Rate von etwa 1 zu 1014 gelesenen Bits auf. Bei einem 4-TB-Laufwerk bedeutet das, dass statistisch gesehen während eines vollständigen sequentiellen Durchlaufs irgendwo wahrscheinlich ein Lesefehler auftritt. Im Normalbetrieb werden diese Sektoren selten angesprochen. Während eines RAID-Wiederaufbaus (Rebuild) werden jedoch alle Sektoren gelesen — und ein einziger nicht lesbarer Sektor stoppt die Paritätsberechnung für den gesamten Stripe. Das Laufwerk muss nicht komplett ausfallen; es genügt, wenn es im ungünstigen Moment einen Lesefehler erzeugt.
SATA-Timeouts unter Last
Eine marginale Kabel- oder Backplane-Verbindung, die unter normalen Arbeitslasten noch funktioniert, kann beim anhaltend hohen I/O‑Durchsatz eines RAID‑Wiederaufbaus (Rebuild) zuverlässig ausfallen und zu SATA‑Timeouts führen. Der Kernel protokolliert einen SATA‑Fehler, mdadm wertet das Laufwerk als nicht erreichbar aus und markiert es als Faulty — obwohl das Laufwerk physisch unauffällig ist. Nach erneutem Verbinden ist das Laufwerk wieder verfügbar, doch mdadm hat es inzwischen bereits aus dem Array entfernt.
Hintergrundaufgaben von DSM
Synology führt S.M.A.R.T.-Tests, Medienindexierung (für Photo Station, Video Station) und Btrfs-Scrubs automatisch nach Zeitplan aus. Laufen diese Aufgaben gleichzeitig mit einem Wiederaufbau (Rebuild), konkurrieren sie um dieselbe Festplatten-I/O-Bandbreite. Auf einem System, das bereits einen andauernden Lesezugriff auf die gesamte Festplatte ausführt, kann zusätzliche I/O die Lese‑/I/O‑Latenz so weit erhöhen, dass Laufwerks‑Timeouts ausgelöst werden — mit derselben Auswirkung wie ein physikalisches Verbindungsproblem.
Für einen umfassenderen Vergleich des Risikos eines Wiederaufbaus gegenüber einer direkten Datenrettung lesen Sie unseren Artikel zu RAID-Wiederaufbau vs. Software‑Datenrettung.
Aktuellen Zustand des Arrays auslesen
Vor jeder Wiederherstellungsmaßnahme müssen Sie genau feststellen, was mdadm meldet. Falls SSH-Zugang vorhanden ist, liefern zwei Befehle das vollständige Bild. Eine ausführliche Schritt-für-Schritt-Anleitung zur Interpretation der mdadm-Ausgabe finden Sie in unserem mdadm-RAID-Wiederherstellungsleitfaden. Nachfolgend die spezifischen Muster, auf die Sie in diesem Szenario achten sollten.
cat /proc/mdstat — zeigt den Zusammenbau‑Status des Arrays und, falls ein Wiederaufbau läuft, den aktuellen Fortschritt und die Geschwindigkeit.
Ein eingefrorener Wiederaufbau sieht so aus:
Personalities : [raid5] [raid6] [raid1] md3 : active raid5 sdb3[0] sdc3[1] sdd3[2] 5860468736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_] [================>....] recovery = 83.2% (2436352/2930234) finish=∞ speed=0K/sec unused devices: <none>
finish=∞ und speed=0K/sec bestätigen, dass der Wiederaufbau blockiert ist — mdadm wartet auf einen Sektor, den es nicht lesen kann (URE / nicht behebbarer Lese-/Fehler).
Ein abgestürztes Array sieht so aus:
Personalities : [raid5] [raid6] [raid1] md3 : inactive sdb3[0](S) sdc3[1](S) 5860468736 blocks super 1.2 unused devices: <none>
inactive mit (S) (Spare) bedeutet, dass mdadm kein aktives Array aufgebaut hat — die Geräte sind vorhanden, aber nicht zusammengefügt. Die Daten liegen physisch auf den Datenträgern, sind jedoch nicht zugänglich.
Die folgende Tabelle ordnet den in DSM sichtbaren Status dem tatsächlichen Zustand zu und zeigt, welche Maßnahmen empfohlen sind:
| Was DSM anzeigt | Bedeutung | Nicht tun | Nächster Schritt |
|---|---|---|---|
| Wiederaufbau eingefroren, speed = 0 Degradiert | URE auf einem vorhandenen Laufwerk blockiert Paritäts‑Schreibvorgänge. Array ist degradiert, aber intakt. | Nicht abwarten; keinen Neustart des Wiederaufbaus erzwingen | RS RAID Retrieve |
| Ein Laufwerk als Faulty markiert, Wiederaufbau gestoppt Degradiert | mdadm hat ein Laufwerk nach wiederholten Lese‑ oder SATA‑Fehlern ausgeschlossen. Betrieb ohne Redundanz. | Das als Faulty markierte Laufwerk nicht entfernen | S.M.A.R.T.-Prüfung durchführen, danach RS RAID Retrieve |
| Speicherpool: Abgestürzt Abgestürzt | mdadm konnte keine Quorum‑Mehrheit aufrechterhalten. Array inaktiv — Daten vorhanden, aber unzugänglich. | Nicht auf „Repair“ klicken; nicht neu starten | RS RAID Retrieve |
| NAS reagiert nicht, DSM lädt nicht Unbekannt | Möglicher Kernel‑Hänger während Rebuild‑I/O. Zustand des Arrays unklar. | Wenn möglich, keinen erzwungenen Netz‑Ausschaltvorgang durchführen | Sauberes Herunterfahren per Power‑Button (gedrückt halten), danach RS RAID Retrieve |
Datenrettung mit RS RAID Retrieve
RS RAID Retrieve ist ein Tool zur RAID‑Wiederherstellung, das die SHR‑Array‑Konfiguration aus den mdadm-Superblöcken der verbleibenden Laufwerke rekonstruiert. Es unterstützt degradierte Arrays, bei denen ein Mitglied fehlt oder als Faulty markiert ist, und bietet schreibgeschützten Zugriff auf das Volume für selektive Dateiwiederherstellung — ohne einen erneuten Rebuild-Versuch zu starten.
Schritt 1 — Laufwerke verbinden und S.M.A.R.T. prüfen
Das NAS nach Möglichkeit ordnungsgemäß herunterfahren. Alle Laufwerke — einschließlich desjenigen, das DSM als fehlerhaft markiert hat — an einen Wiederherstellungsrechner anschließen und den integrierten S.M.A.R.T.-Monitor in RS RAID Retrieve öffnen. Alle Laufwerke prüfen, nicht nur das ausgefallene. Beim RAID‑Wiederaufbau (Rebuild) ist das scheinbar gesunde Laufwerk häufig die Ursache des Ausfalls, da es durch Lesefehler an einem bestehenden Verbundmitglied Probleme ausgelöst haben kann.
Schritt 2 — Abbild erstellen bei erhöhten S.M.A.R.T.-Werten
Wenn bei einem Laufwerk S.M.A.R.T.-Kennwerte wie Reallocated Sector Count, Pending Sectors oder Uncorrectable Errors ungleich null sind, erstellen Sie vor dem Scan ein sektorweises Abbild (Festplatten-Image) dieses Laufwerks mithilfe der integrierten Abbildfunktion von RS RAID Retrieve. Alle anschließenden Wiederherstellungsarbeiten erfolgen ausschließlich am Image. Dadurch wird das Quelllaufwerk vor weiteren Lesezugriffen geschützt und eine zusätzliche Verschlechterung eines bereits belasteten Laufwerks verhindert — eine bewährte Praxis in der professionellen Datenrettung und RAID-Wiederherstellung.
Schritt 3 — Automatische Array-Rekonstruktion
RS RAID Retrieve liest den mdadm-Superblock von jedem angeschlossenen Laufwerk oder Abbild, erkennt die Array-UUID, die Mitgliedsrollen, das RAID-Level und die Stripe-Parameter und rekonstruiert die SHR-Volumestruktur. Bei einem degradierten Array mit einem fehlenden oder ausgefallenen Mitglied kann das Programm die Rekonstruktion mithilfe der verbleibenden Laufwerke durchführen — fehlende Daten werden aus der Parität berechnet, genauso wie mdadm im degradierten Zustand vorgehen würde, jedoch ohne Änderungen auf die Datenträger zu schreiben.
Schritt 4 — Dateien durchsuchen und wiederherstellen
Fahren Sie das NAS nach Möglichkeit ordnungsgemäß herunter. Schließen Sie alle Laufwerke — einschließlich desjenigen, das DSM als „Fehlerhaft“ markiert hat — an einen Wiederherstellungsrechner an und öffnen Sie für die Datenwiederherstellung den integrierten S.M.A.R.T.-Monitor in RS RAID Retrieve. Prüfen Sie jedes Laufwerk, nicht nur das vermeintlich ausgefallene. Während eines RAID-Rebuilds ist häufig das Laufwerk, das gesund erscheint, tatsächlich Verursacher des Ausfalls, da es beim Lesen von bestehenden RAID-Mitgliedern Lesefehler erzeugt hat.
Unterstützt degradierte und ausgefallene Arrays
Rekonstruiert SHR-Volumes (Synology Hybrid RAID) aus verbleibenden Mitgliedern, ohne ein vollständig intaktes RAID-Array vorauszusetzen — einschließlich inaktiver Arrays, die mdadm nicht zusammenbauen kann. Geeignet für RAID-Rekonstruktion und Datenwiederherstellung bei defekten Arrays.
S.M.A.R.T.-Überwachung
Den Laufwerkszustand vor dem Scan prüfen. S.M.A.R.T.-Werte liefern Informationen zum Festplattenzustand und zu drohenden Ausfällen. Ermittelt, welches Laufwerk den RAID‑Rebuild‑Fehler verursacht hat und ob vor der Wiederherstellung ein Festplattenabbild (Image) zur Datenrettung erstellt werden muss.
Datenträger-Image (sektorebenes Abbild)
Vor der Wiederherstellung wird ein sektorebenes Abbild des beeinträchtigten Datenträgers erstellt. Alle weiteren Arbeiten erfolgen ausschließlich am Image, sodass das Original vor zusätzlichen Lesezyklen geschützt bleibt.
SSH‑Verbindung
Wenn das NAS eingeschaltet und über das Netzwerk erreichbar ist, kann RS RAID Retrieve per SSH eine Verbindung zum Gerät herstellen — ohne Laufwerke physisch aus dem Gehäuse entfernen zu müssen.
Wenn eine softwareseitige Wiederherstellung nicht ausreicht
Wenn mehrere Laufwerke beim Anschluss an den Wiederherstellungsrechner nicht erkannt werden oder S.M.A.R.T. bei mehr als einem Array‑Mitglied kritische Werte meldet, liegt ein Hardwareausfall vor und die Situation ist nicht mehr allein durch softwaregestützte Datenwiederherstellung zu lösen. Ein SHR‑1‑Array mit zwei ausgefallenen Laufwerken besitzt keine Paritätsdaten zur Rekonstruktion — es gibt keinen mathematischen Weg, die fehlenden Daten ausschließlich per Software wiederherzustellen.
Sofort stoppen und ein Datenrettungs‑Labor kontaktieren, wenn folgende Hinweise auftreten
- Zwei oder mehr Laufwerke werden nicht erkannt oder zeigen beim Einschalten sofort einen S.M.A.R.T.-Fehler
- Klick‑ oder Schleifgeräusche bzw. wiederholtes Scheitern des Spindelanlaufs bei einem Laufwerk
- RS RAID Retrieve kann das Array selbst im manuellen Modus nicht rekonstruieren
- Laufwerke sind innerhalb weniger Minuten nach Anschluss heiß bei Berührung
Physische Datenrettung — Kopfwechsel, Plattenübertragung — erfordert eine Reinraumumgebung. Jeder zusätzliche Stromzyklus bei mechanisch defekten Festplatten reduziert die Wahrscheinlichkeit einer erfolgreichen Datenwiederherstellung.
Nach der Wiederherstellung: Vermeidung eines erneuten Rebuild‑Ausfalls
Ein Absturz des Wiederaufbaus (Rebuild) während des Laufwerkstauschs ist kein Zufall. Er nutzt eine spezifische Schwachstelle: Alle verbleibenden Laufwerke sind genau in dem Moment, in dem das Array keine Redundanz mehr besitzt, einer maximalen, anhaltenden Lese‑ bzw. I/O‑Last ausgesetzt. Die folgenden Maßnahmen reduzieren die Wahrscheinlichkeit, dass dieses Szenario erneut eintritt.
S.M.A.R.T. prüfen, bevor ein Laufwerk ausgetauscht wird
Vor dem Ausbau des alten Laufwerks sollte auf allen verbleibenden Datenträgern ein vollständiger, erweiterter S.M.A.R.T.-Test ausgeführt werden. Ein Laufwerk mit neu zugewiesenen Sektoren oder mit ausstehenden Fehlern führt beim anschließenden RAID‑Rebuild mit hoher Wahrscheinlichkeit zu einem URE (unrecoverable read error, nicht korrigierbarer Lesefehler).
DSM‑Hintergrundaufgaben während des Wiederaufbaus (Rebuild) deaktivieren
Öffnen Sie die Systemsteuerung → Aufgabenplaner und setzen Sie geplante S.M.A.R.T.-Tests, Btrfs-Scrubs und Medienbibliothek-Scans für die Dauer des Wiederaufbaus aus. Konkurrierende Ein-/Ausgabevorgänge (I/O) sind eine der am einfachsten vermeidbaren Ursachen für einen fehlgeschlagenen Wiederaufbau.
SATA-Kabel vor Beginn erneut einstecken
Eine marginale Verbindung, die bei geringer Last noch funktioniert, kann bei der dauerhaft hohen Datenrate eines mehrtägigen Wiederaufbaus ausfallen. Vor dem Start des Austauschvorgangs alle SATA-Daten- und SATA-Stromkabel abziehen, erneut einstecken und die Kabelverbindungen prüfen.
Keine Laufwerkschargen mischen
Festplatten (HDD/SSD), die zur selben Zeit aus derselben Produktionscharge stammen, unterliegen einem ähnlichen Verschleiß. Fällt eine Einheit aus, ist die Ausfallwahrscheinlichkeit für die übrigen Laufwerke statistisch erhöht — besonders kritisch in RAID-Umgebungen. Beziehen Sie Ersatzlaufwerke von einem anderen Hersteller oder aus einer anderen Produktionscharge, um das Risiko von Folgeschäden und weiteren Festplattenausfällen zu reduzieren.
E‑Mail-Benachrichtigungen in DSM aktivieren
Systemsteuerung → Benachrichtigung → E‑Mail. DSM kann Sie sofort benachrichtigen, sobald eine Festplatte als defekt markiert wird oder ein Speicherpool degradiert. Je früher ein Ausfall erkannt wird — idealerweise bevor der Wiederaufbau (Rebuild) 60 Stunden gelaufen ist — desto mehr Wiederherstellungsoptionen stehen zur Verfügung.
Unabhängige Datensicherung anlegen
SHR bietet Ausfallsicherheit, keine Datensicherung. Ein degradiertes Array während eines Rebuilds schützt nicht vor einem zweiten Ausfall. Hyper Backup auf ein externes Laufwerk oder als Cloud-Backup ist die einzige Garantie dafür, dass ein Rebuild-Absturz nicht in dauerhaften Datenverlust mündet.
Ein Rebuild-Ausfall beim Laufwerksersatz zählt zu den häufigeren SHR‑Datenverlust‑Szenarien, weil er genau zum denkbar schlechtesten Zeitpunkt zuschlägt: maximale I/O‑Last auf der ältesten Hardware im Array bei keiner Redundanzreserve. Sind die Daten wiederhergestellt, ist das Ereignis als Warnsignal zu werten — nicht nur in Bezug auf das ausgefallene Laufwerk, sondern auch für den Zustand der übrigen Hardware und die allgemeine Integrität des Volumes. Eine unabhängige Sicherungskopie (Backup) und eine getestete Wiederherstellungsstrategie sind daher unabdingbar.
