Die Antwort vorweg: Die Schaltfläche Repair in Synology DSM beziehungsweise Rebuild RAID Group in QNAP QTS ist nur dann sicher, wenn drei Voraussetzungen gleichzeitig erfüllt sind: Sie besitzen ein Backup, aus dem vor Kurzem tatsächlich Daten wiederhergestellt wurden; Sie wissen, welches konkrete Laufwerk ausgefallen ist und warum; und die übrigen Laufwerke weisen weder Fehler im Protokoll noch eine steigende Zahl fehlerhafter Sektoren auf. Sobald eine dieser Bedingungen nicht erfüllt ist, handelt es sich beim Rebuild nicht um eine Reparatur – sondern um den längsten ununterbrochenen Schreibvorgang, den das Array in seinem gesamten Leben erlebt, und er findet ausgerechnet auf den Daten statt, um die es geht.
Die Grenze verläuft nicht zwischen den Marken, sondern zwischen „funktioniert noch“ und „bereits ausgefallen“
Menschen geben die Fehlermeldung wortwörtlich in die Suchmaschine ein, weil die Benutzeroberfläche des NAS selbst in einem tschechischen Unternehmen Englisch spricht: storage pool degraded, storage pool crashed, volume crashed, system partition failed bei Synology; RAID group degraded, volume read-only, volume not active, storage pool inactive bei QNAP. Das sieht nach zwei unterschiedlichen Problemgruppen aus. Tatsächlich handelt es sich um dieselbe Grenze, die beide Hersteller an derselben Stelle ziehen.
Synology definiert sie selbst: Degraded bedeutet, dass eines oder mehrere Laufwerke fehlerhaft sind, das Array aber weiterhin verfügbar ist und kein Datenverlust eingetreten ist – Repair kann es wieder in einen fehlerfreien Zustand versetzen. Crashed bedeutet, dass der Benutzer das Array nicht mehr reparieren kann, gewöhnlich weil zu viele Laufwerke ausgefallen sind und die Datenintegrität nicht mehr gewährleistet ist.
Bei QNAP trägt dieselbe Grenze einen anderen Namen. Read-Only ist keine mildere Variante einer Degradierung – es ist ein Zustand, in dem QTS Schreibzugriffe selbstständig eingeschränkt hat, weil im Storage Pool etwas nicht stimmt und einige RAID Groups möglicherweise bereits Not Active sind.
Die praktische Übersetzung lautet: Degraded ist eine Warnung, Crashed und Read-Only sind ein Vorfall. Dazwischen liegt nur ein einziger Klick – Repair auf einem Array, in dem das zweite Laufwerk bereits unbemerkt Fehler produziert.
Was die einzelnen Meldungen genau bedeuten und welcher nächste Schritt jeweils sicherer ist, erläutern zwei separate Seiten: die Meldungen Storage Pool Degraded, Volume Crashed und System Partition Failed in DSM sowie die Zustände RAID Group Degraded, Read-Only und Volume Not Active in QTS. Dieser Text behandelt, was beide gemeinsam haben: wie Sie die drei entscheidenden Punkte überprüfen, bevor Sie irgendetwas anklicken.
Drei entscheidende Fragen – und wo Sie die Antworten in DSM und QTS finden
Bevor Sie irgendetwas anderes tun, speichern Sie Screenshots: vom Storage Manager beziehungsweise von Storage & Snapshots, von der Laufwerksliste mit Modellen und Einschüben, vom genauen Wortlaut der Meldung und von den Protokolleinträgen. Ohne diese Informationen lässt sich später nur noch darüber spekulieren, wie der Zustand vor dem Eingriff aussah.
1. Wurde das Backup überprüft oder ist sein Status nur grün? Ein grüner Auftragsstatus besagt, dass der Auftrag abgeschlossen wurde – nicht, dass sich daraus Daten wiederherstellen lassen. Die Integritätsprüfung von Hyper Backup kontrolliert, ob der Auftrag fortgesetzt und das Backup wiederhergestellt werden kann; dabei werden keine Daten übertragen. Das ist kein Wiederherstellungstest. Die entscheidende Frage lautet: Wann hat zuletzt jemand tatsächlich eine Datei aus diesem Backup wiederhergestellt oder daraus ein System aufgebaut?
2. Wissen Sie, welches Laufwerk ausgefallen ist und warum? In DSM finden Sie diese Informationen im Storage Manager beim jeweiligen Laufwerk (Health Info: Status Warning oder Critical sowie die Anzahl fehlerhafter, neu zugewiesener und ausstehender Sektoren) und im Log Center. In QTS stehen sie unter Storage & Snapshots, im IHM-Status und in den Systemprotokollen. Suchen Sie nach I/O-Fehlern, Bus-Resets und wiederholten Verbindungsabbrüchen desselben Einschubs. Vorsicht vor einer Falle: S.M.A.R.T. bleibt grün, solange das Laufwerk selbst keinen Fehler eingesteht – eine Verschlechterung erkennt man eher an der steigenden Zahl neu zugewiesener Sektoren und zunehmenden Latenzen als am Gesamturteil.
3. Sind die übrigen Laufwerke wirklich fehlerfrei? Das ist die wichtigste Frage und zugleich diejenige, die häufig übersprungen wird, weil das ausgefallene Laufwerk die gesamte Aufmerksamkeit auf sich zieht. Ein Rebuild beansprucht jedoch alle anderen Laufwerke: Von ihnen wird fortlaufend eine enorme Datenmenge gelesen und auf das neue Laufwerk geschrieben. Bei einem RAID 5 aus vier 4-TB-Laufwerken werden während der Rekonstruktion ungefähr 12 TB gelesen, bei 8-TB-Laufwerken etwa 24 TB. Hersteller von Consumer-Laufwerken geben als Untergrenze einen nicht lesbaren Sektor pro 10^14 gelesenen Bits an, also ungefähr pro 12,5 TB. Dieser Wert ist eine konservative Spezifikation und keine Vorhersage eines Datenverlusts; die unbestreitbare Schlussfolgerung daraus ist jedoch eindeutig: Ein Rebuild ist statistisch der riskanteste Vorgang, den ein Array erlebt.
Alle drei Überprüfungen bestehen ausschließlich aus Lesevorgängen. Dabei wird nichts geschrieben – deshalb lohnt es sich, dafür eine halbe Stunde aufzuwenden.
Was die einzelnen Schaltflächen tatsächlich auf die Laufwerke schreiben
Die NAS-Benutzeroberfläche bietet ihre Reparaturfunktionen bei einem Ausfall von sich aus an. Ein Eintrag in der grafischen Oberfläche ist jedoch keine Empfehlung für Ihre konkrete Situation – er ist lediglich eine Standardfunktion für die reguläre Wartung.
| Aktion in der Benutzeroberfläche | Was dabei tatsächlich auf den Laufwerken geschieht | Wann sie vertretbar ist |
|---|---|---|
| Repair / Rebuild RAID Group | Fortlaufendes Lesen von allen überlebenden Laufwerken und Schreiben auf das neue Laufwerk; dabei wird die Parität überschrieben, die für eine Wiederherstellung benötigt werden könnte | Nur wenn alle drei oben genannten Bedingungen erfüllt sind |
| Recover RAID (QuTS hero) | Versuch, vorübergehend getrennte Laufwerke wieder in das Array aufzunehmen | Nur bei einem Laufwerk, das herausgezogen und sofort wieder in denselben Einschub eingesetzt wurde – nicht bei einem Laufwerk, das aufgrund eines Defekts ausgefallen ist |
| Create / Initialize / neues Volume | Erstellt ein leeres Array und zerstört mdadm-Superblöcke, LVM-Metadaten sowie Dateisystemstrukturen | Niemals, wenn es um die Daten geht |
Check File System, fsck, btrfs check --repair, zpool scrub | Schreibt in die Metadaten des Dateisystems. Das Werkzeug interpretiert beschädigte Parität als Dateisystemfehler und löscht gültige Einträge | Nicht auf einem zerfallenen Array |
| Laufwerke zwischen Einschüben vertauschen | Löst auf den meisten Plattformen automatisch einen Rebuild-Versuch oder das Schreiben von Metadaten aus | Niemals, ohne zuvor die Reihenfolge zu kennzeichnen |
| Wechsel QTS ↔ QuTS hero | QNAP schreibt es ausdrücklich: „Switching to QuTS hero will erase all data on your NAS.“ Das gilt in beide Richtungen | Nur mit einem vollständigen und überprüften Backup |
| Anschließen der NAS-Laufwerke an Windows | Windows kann ext4, Btrfs und XFS nicht einbinden und bietet an, den „Datenträger zu initialisieren“ – wodurch Partitionstabelle und RAID-Metadaten überschrieben werden | Niemals |
Bei Btrfs verdient besondere Erwähnung, warum eine Reparatur „an Ort und Stelle“ so tückisch ist: Sie überschreibt die Generation Roots der Copy-on-Write-Bäume, also genau die Strukturen, auf denen eine spätere Wiederherstellung beruht. Metadaten sollten mit btrfs-restore vom beschädigten Volume gelesen und nicht durch Einbinden repariert werden.
Und noch etwas, das Datenrettungslabore als den häufigsten und verheerendsten Fehler überhaupt bezeichnen: ein erzwungener Rebuild, ohne sicher zu wissen, welches Laufwerk tatsächlich defekt ist. Kein exotischer Eingriff, keine Befehlszeile – nur ein gewöhnlicher Klick auf eine Schaltfläche, die von der Benutzeroberfläche angeboten wird.
Fünf Situationen, in denen „Degraded“ kein defektes Laufwerk bedeutet
Das Modell „Ein Laufwerk ist ausgefallen, also tausche ich es aus“ passt auf genau einen bestimmten Fall. In den folgenden fünf Fällen trifft es nicht zu.
- Ein intaktes Laufwerk wurde wegen eines Timeouts aus dem Array entfernt. Ein Desktop-SATA-Laufwerk besitzt keine zeitlich begrenzte Fehlerkorrektur und kann an einem schwachen Sektor für mehrere Dutzend Sekunden bis zu zwei Minuten festhängen. Ein Controller, der nur 7 bis 30 Sekunden wartet, wertet dies als Defekt und entfernt das Laufwerk aus dem Array. NAS-Laufwerke verfügen dagegen über TLER, ERC oder CCTL und brechen den Versuch nach ungefähr sieben Sekunden ab. Das Tückische daran: Ein solches Laufwerk kann einen separaten Test anschließend fehlerfrei bestehen.
- Im Array befindet sich ein SMR-Laufwerk. Während des Rebuilds wird über lange Zeit fortlaufend darauf geschrieben. Sobald sein Pufferbereich voll ist, beginnt es, komplette Bänder in Echtzeit per Read-Modify-Write neu zu schreiben, und der Durchsatz fällt auf wenige MB/s. Der Controller überschreitet sein Timeout und entfernt das Laufwerk aus dem Array – wiederholte Versuche verschlimmern den Zustand nur.
- Die NVMe-Cache-SSD ist ausgefallen. Der Cache enthält noch nicht bestätigte Schreibvorgänge, die für das Array bestimmt sind; er ist keine entbehrliche Kopie. Fällt er aus, kann das gesamte Btrfs-Volume abstürzen, obwohl alle mechanischen Laufwerke intakt sind.
- Es gab einen Stromausfall. Die Stromversorgung wird zwischen dem Schreiben der Daten und der Aktualisierung des Paritätsblocks unterbrochen, sodass das Array inkonsistent zurückbleibt. Heimtückisch ist, dass das NAS anschließend startet und normal aussieht, während beispielsweise der Backup-Katalog, eine Datenbank oder das Image einer virtuellen Maschine beschädigt geblieben ist.
- Die Event Counter in den mdadm-Superblöcken stimmen nicht überein. Das Array lässt sich nicht aus Laufwerken zusammensetzen, die es als veraltet betrachtet, obwohl sich die Daten weiterhin darauf befinden.
mdadm --assemble --forceohne Kenntnis der Event Counts, Offsets und Laufwerksreihenfolge ist ein Glücksspiel und keine Reparatur.
Der gemeinsame Nenner lautet: In keiner dieser fünf Situationen ist ein Rebuild die Lösung. Und in allen fünf Fällen bietet die Benutzeroberfläche ihn bereitwillig an.
Zwei dokumentierte Fälle: Geplante Wartung ist am gefährlichsten
Synology DS2015xs, RAID 6, sechs 6-TB-Laufwerke. Das Array bestand aus fünf WD60EFRX-Laufwerken (CMR) und einem WD60EFAX-Laufwerk (SMR), das als Ersatz für ein defektes CMR-Laufwerk eingebaut worden war. Das neue Laufwerk begann Fehler zu produzieren, die Leistung sank auf ein unbrauchbares Niveau, das NAS ließ sich weder ordnungsgemäß herunterfahren noch neu starten und schaltete sich schließlich überhaupt nicht mehr ein. Das Labor, das den Fall bearbeitete, fasste ihn mit einem Satz zusammen, den man zweimal lesen sollte: „NAS truly did not report any failures or outages.“ Fehlereinträge in den Protokollen waren vorhanden. Eine Warnung für den Benutzer gab es nicht.
Netgear ReadyNAS, X-RAID auf Btrfs. Das Szenario lautete „Kapazität im laufenden Betrieb erweitern“: Drei 3-TB-Laufwerke wurden schrittweise durch 6-TB-Laufwerke ersetzt, wobei das Array nach jedem Austausch neu berechnet wurde. Das neu eingesetzte 6-TB-Laufwerk begann mitten in der Rekonstruktion ATA-Fehler zu melden, und auch ein zweites Laufwerk fiel aus dem Array – obwohl dieses einen anschließenden separaten Test fehlerfrei bestand. Der nicht abgeschlossene Rebuild beschädigte sowohl die Metadaten als auch das Dateisystem.
Aus beiden Fällen folgt dasselbe: Der gefährlichste Zeitpunkt im Leben eines NAS ist nicht der Ausfall, sondern die geplante Wartung – ein Laufwerkstausch, eine Kapazitätserweiterung oder eine Migration. Und die Überwachung, auf die sich ein Unternehmen verlässt, muss überhaupt nichts melden. Deshalb lohnt es sich, eine scheinbare Selbstverständlichkeit zu prüfen: Werden Benachrichtigungen aus DSM oder QTS tatsächlich an eine Adresse gesendet, die jemand liest?
Wann Sie sofort und ohne Diskussion aufhören sollten zu klicken
- Der Zustand lautet Crashed, Inactive oder Read-Only.
- Mehr als ein Laufwerk meldet Fehler.
- Ein Laufwerk klickt, verschwindet wiederholt oder weist eine steigende Zahl ausstehender und neu zugewiesener Sektoren auf.
- Repair oder Rebuild wurde bereits einmal gestartet und nicht abgeschlossen – oder abgeschlossen, ohne den Zustand zu verbessern.
- Jemand hat bereits einen Reset, eine Neuinstallation des Systems, den Austausch mehrerer Laufwerke oder das Vertauschen der Einschübe versucht.
- Die Daten existieren nur hier.
In diesen Fällen ist der nächste Klick kein Reparaturversuch, sondern ein Schreibvorgang in der einzigen vorhandenen Kopie. Ausgeschaltete Daten verändern sich nicht. Wenn sich die Daten auch nach dem Ausschalten und Anschließen der Laufwerke an ein anderes System nicht auslesen lassen, erläutert der Artikel darüber, wie Sie Daten aus einem ausgefallenen NAS retten, die verfügbaren Möglichkeiten und ihre Risiken.
Was Sie vorbereiten sollten, bevor Sie jemanden anrufen
- Modell des NAS und Systemversion (DSM, QTS, QuTS hero).
- Anzahl der Laufwerke, ihre genauen Modelle und Kapazitäten sowie die Reihenfolge der Einschübe.
- Art des Arrays (RAID 1/5/6/10, SHR-1, SHR-2, X-RAID) und Dateisystem (ext4, Btrfs, ZFS).
- Wann zuletzt alles funktioniert hat und was unmittelbar davor geschah – Laufwerkstausch, Stromausfall, Aktualisierung oder Migration.
- Was bereits versucht wurde. Vor allem, ob ein Rebuild, eine Initialisierung, eine Dateisystemprüfung oder das Anschließen der Laufwerke an Windows durchgeführt wurde. Dabei geht es nicht um die Schuldfrage, sondern darum, was sich noch auf den Laufwerken befindet.
- Ob irgendein Backup vorhanden ist und wann zuletzt jemand daraus Daten wiederhergestellt hat.
Häufig gestellte Fragen
DSM bietet Repair an. Bedeutet das nicht, dass es sicher ist?
Nein. Repair ist eine Standardfunktion für eine Standardsituation – ein degradiertes Array, bei dem eindeutig feststeht, welches Laufwerk ausgefallen ist, während die übrigen Laufwerke fehlerfrei sind. Die Benutzeroberfläche kennt weder den Zustand Ihrer Backups noch die Vorgänge, die in der vergangenen Woche im Array stattgefunden haben. Das Vorhandensein der Schaltfläche ist keine Risikobewertung.
Das Array ist Degraded, aber die freigegebenen Ordner sind erreichbar. Kann ich meine Daten kopieren?
Wenn die Laufwerke keine auffälligen mechanischen Geräusche erzeugen und das Protokoll keine Fehler weiterer Laufwerke enthält, ist es sinnvoll, die wichtigsten Ordner zu sichern. Starten Sie jedoch kein vollständiges, stundenlang laufendes Backup: Das Lesen der gesamten Oberfläche belastet ein instabiles Array und kann genau den Ausfall beschleunigen, den Sie verhindern möchten. Stoppen Sie zunächst Backup-Aufträge, Indexierung, Kameraaufzeichnungen und geplante SMART-Tests.
Das ausgetauschte Laufwerk wurde als fehlerfrei getestet. Kann ich es wieder einsetzen?
Physisch ja, doch die Frage „Warum ist es dann ausgefallen?“ bleibt damit unbeantwortet. Ein Laufwerk, das wegen eines Timeouts oder des Verhaltens seiner SMR-Firmware aus dem Array entfernt wurde, kann einen separaten Test fehlerfrei bestehen und sich im Array anschließend genauso verhalten wie zuvor.
Hilft mir ein Wiederherstellungsprogramm unter Windows?
Bei einem Array aus mehreren Laufwerken nicht. Programme dieser Art scannen die Laufwerke einzeln und können das Array nicht zusammensetzen – eine über mehrere Stripes verteilte Datei lässt sich daraus nicht rekonstruieren.
Befindet sich Ihr Array im Zustand Degraded, Crashed oder Read-Only und möchten Sie keinen falschen Klick riskieren? Senden Sie uns einen Screenshot aus DSM oder QTS und beschreiben Sie, was bereits durchgeführt wurde. Wir sagen Ihnen, ob noch ein gewöhnlicher Serviceeingriff möglich ist oder ob Sie das NAS besser ausschalten und mit Kopien der Laufwerke arbeiten sollten. Wie die Datenrettung von RAID und NAS abläuft und was dabei mit den Originallaufwerken geschieht, erläutert unsere Leistungsseite.
Quellen
- Synology: Repair und Storage Pool (Definitionen von Degraded und Crashed) — kb.synology.com
- Synology: What can I do if one of my volumes crashed? — kb.synology.com
- QNAP QTS 5.2: Storage pool status (Read-Only, Not Active, Inactive) — docs.qnap.com
- QNAP QTS 5.1: Recovering a RAID Group with a Degraded status — docs.qnap.com
- QNAP: Can I switch my NAS OS? (der Wechsel QTS ↔ QuTS hero löscht Daten) — qnap.com
- Rossmann Repair Group: What Happens During a NAS Crash (Btrfs, NVMe-Cache,
btrfs-restore) — rossmanngroup.com - Rossmann Repair Group: Why Rebuilding a Degraded RAID Destroys Data — rossmanngroup.com
- SmallNetBuilder: The Seven Biggest Mistakes When Attempting Data Recovery — smallnetbuilder.com
- Wikipedia: Error recovery control (TLER, ERC, CCTL) — en.wikipedia.org
- EXALAB: Datenrettung von RAID nach HDD-Ausfall in einem NAS (Fall Synology DS2015xs) — exalab.cz
- EXALAB: Datenrettung von einem Netgear-NAS nach Ausfall von RAID 5 (Fall X-RAID und Btrfs) — exalab.cz
Wo Sie uns finden
ITHOPE ist eine Firma aus Brno, Tschechien: wir machen Datenrettung von Festplatten, RAID und NAS, PC- und Notebook-Service und IT für Unternehmen, alles im eigenen Labor in der Viniční 3587/216, 615 00 Brno.
Telefon +420 775 556 063 (rund um die Uhr). Das Gerät können Sie persönlich bringen oder per Kurier schicken (Zásilkovna, PPL).