Festplatte im NAS ausgefallen: Sicher durch den Rebuild

Ein als „ausgefallen“ markiertes Laufwerk ist nicht automatisch mechanisch defekt. Zuerst sind im NAS-Verwaltungsfenster RAID-Status, betroffener Schacht und Zeitstempel zu dokumentieren. Entscheidend ist, ob das Volume degradiert, die Platte nur getrennt oder das gesamte RAID in einem kritischen Zustand gemeldet wird.

Laufwerk und Umgebung getrennt bewerten

Die SMART-Werte liefern den wichtigsten Hinweis auf die Platte selbst: neu zugewiesene Sektoren, schwebende Sektoren, nicht korrigierbare Lesefehler sowie stark steigende CRC-Fehler sind besonders relevant. Ein fehlender SMART-Abruf kann jedoch ebenso auf einen Kontakt-, Backplane- oder Controllerfehler hindeuten. Ein kurzer Selbsttest ist sinnvoll, sofern das NAS ihn ohne RAID-Rebuild und ohne hohe Last ausführen kann; ein langer Test sollte bei nur noch einer verbleibenden Redundanz mit Bedacht erfolgen.

Die Systemprotokolle sollten um den Ausfallzeitpunkt geprüft werden. Wiederholte Meldungen wie disk unplugged, Link-Resets, I/O-Timeouts oder SATA-CRC-Fehler sprechen eher für Verbindung, Schacht oder Backplane als für Medienfehler. Treten ähnliche Ereignisse bei mehreren Schächten auf, sind Stromversorgung, Backplane und Controller vorrangig zu untersuchen.

• Schachtbezeichnung mit der physischen Einschubnummer abgleichen; Hersteller zählen nicht immer von links nach rechts.
• Firmwarestand von NAS, Backplane und Laufwerk mit den Herstellerhinweisen vergleichen.
• Bekannte Inkompatibilitäten, fehlerhafte Firmwareversionen und Warnungen zu SMR-Laufwerken prüfen.
• Bei externen Erweiterungseinheiten auch SAS-/eSATA-Kabel und deren Verriegelung kontrollieren.

Erst wenn Status, SMART und Logs zusammenpassen, ist ein Laufwerkstausch belastbar begründet.

Entscheidend ist nicht allein, dass eine Festplatte fehlt, sondern welche Redundanz das tatsächliche Volume noch besitzt. RAID 1, RAID 5, RAID 6, RAID 10 sowie herstellerspezifische Pools unterscheiden sich erheblich. Ein RAID 5 oder RAID 1 ist nach einem bestätigten Einzellaufwerksausfall bereits ohne Reserve; ein weiterer Lesefehler oder Plattenausfall kann den gesamten Verbund unbrauchbar machen. RAID 6 verkraftet dagegen zwei Ausfälle, allerdings nur, sofern nicht bereits eine zweite Disk fehlerhaft oder aus dem Array entfernt ist.

Layout und Metadaten vor dem Austausch prüfen

Bei RAID 10 hängt die Reserve vom betroffenen Spiegelpaar ab: Zwei ausgefallene Laufwerke können überlebbar sein, wenn sie in unterschiedlichen Paaren liegen – im selben Paar nicht. Bei SHR, ZFS-RAIDZ, Storage Spaces oder verschachtelten RAID-Gruppen darf die Bezeichnung in der Oberfläche daher nicht als ausreichende Diagnose gelten.

Zu prüfen sind insbesondere:

• Mitgliederstatus: aktiv, fehlend, ausgefallen, entfernt oder nur temporär nicht erreichbar;
• RAID-Metadaten: konsistente Array-ID, erwartete Laufwerksreihenfolge und keine widersprüchlichen Ereignisse;
• zweite Auffälligkeiten: Lesefehler, resilvernde Datenträger, instabile SATA-/SAS-Verbindungen oder erneute SMART-Warnungen.

Wurden mehrere Laufwerke als fehlend markiert, sind Metadaten uneinheitlich oder erscheint ein Pool als „nicht importierbar“, endet die Standardprozedur. Dann weder Array erstellen noch initialisieren, formatieren oder einen erzwungenen Rebuild starten: Solche Schreibvorgänge können die noch vorhandenen Zuordnungsinformationen überschreiben.

Solange das Volume noch lesbar ist, erhalten unersetzliche und aktuelle Daten Vorrang: Geschäftsunterlagen, Datenbanken, Projekte und Konfigurationen. Zuerst wird geprüft, ob deren letzter Stand bereits außerhalb des NAS gesichert ist. Eine Sicherung gilt erst als belastbar, wenn sie vollständig, zeitlich passend und stichprobenartig wiederherstellbar ist.

RAID ersetzt kein Backup. Es hält den Betrieb bei einem definierten Plattenausfall aufrecht, schützt aber weder vor versehentlichem Löschen noch vor Ransomware, Dateisystemfehlern oder einem zweiten Defekt. Snapshots sind schnelle, lokale Zeitstände und können Snapshots für eine leichtere Wiederherstellung nutzen; auf demselben NAS bleiben sie jedoch von vielen Hardware- und Administrationsrisiken betroffen.

Zeigt das Array neben der ausgefallenen Platte Lesefehler, wachsende Pending-Sektoren oder I/O-Resets, ist eine ungezielte Vollkopie riskant: Sie kann jeden Block lesen lassen und den Verbund zusätzlich belasten. Dann nur die priorisierten Daten in kleinen, überprüfbaren Chargen sichern, Fehler protokollieren und bei Abbrüchen keine wiederholten Kopierversuche erzwingen.

Rebuild-Dauer realistisch einschätzen

DIGIBITE zeigt, weshalb Rebuild-Zeiten von NAS-Auslastung, RAID und Laufwerksgröße abhängen.

Nach dem Einsetzen sollte die NAS-Verwaltung den bestehenden Storage Pool weiterhin als degradiert anzeigen und den neuen Datenträger als Ersatz für den fehlenden Schacht erkennen. Startet der Vorgang automatisch, wechselt der Status typischerweise zu Rebuilding, Resyncing oder Wiederherstellung läuft. Fortschritt, verbleibende Zeit und erhöhte Plattenaktivität müssen dabei zusammenpassen; das Ereignisprotokoll dokumentiert den Beginn.

Bleibt der Pool degradiert und der neue Datenträger erscheint als „verfügbar“, ist meist ein manueller Schritt erforderlich. In der Speicherverwaltung wird dann ausdrücklich Reparieren, Datenträger ersetzen oder dem bestehenden Pool zuordnen gewählt. Entscheidend ist die Auswahl des ausgefallenen Slots beziehungsweise des betroffenen RAID-Mitglieds – nicht das Anlegen eines neuen Volumes.

Ein als foreign, „fremd“ oder uninitialized gemeldeter Datenträger verdient besondere Vorsicht. Solche Hinweise können erhaltene RAID-Metadaten anzeigen. Vor jeder Aktion sollten Seriennummer, Schacht und Pool-Zuordnung erneut geprüft werden; gegebenenfalls ist die vom Hersteller vorgesehene Import- oder Assemble-Funktion nötig.

Ein Rebuild dauert nicht nach Kalender, sondern nach belegter Kapazität, RAID-Level, Plattengröße, NAS-Leistung und aktueller I/O-Last. Bei großen, nahezu gefüllten HDD-Arrays sind viele Stunden bis mehrere Tage realistisch. Die angezeigte Restzeit ist anfangs oft unzuverlässig: Sie wird aus der momentanen Transferrate hochgerechnet und schwankt bei wechselnder Last.

Während dieser Phase sollten rechen- und datenträgerintensive Aufgaben pausieren:

• Backups, Replikationen und Cloud-Synchronisationen
• Medienindizierung, Vorschauberechnung und Transkodierung
• große Kopier-, Verschiebe- und Löschvorgänge
• geplante S.M.A.R.T.-Langtests sowie weitere Wartungsjobs

Eine hohe Rebuild-Priorität verkürzt die Ausfallzeit, konkurriert aber stärker mit normalen Zugriffen und erhöht Temperatur, Warteschlangen und Belastung aller verbliebenen Laufwerke. Bei auffälligen S.M.A.R.T.-Werten, hohen Temperaturen oder vielen gleichzeitigen Zugriffen ist eine moderate Priorität meist die robustere Wahl. Entscheidend ist ein stabiler Durchlauf, nicht ein kurzfristiger Spitzenwert.

Fortschritt und Fehler korrekt deuten

Der Fortschritt sollte regelmäßig protokolliert werden: Prozentwert, Transferrate, Temperatur, RAID-Status und neue Systemmeldungen. Einzelne korrigierte Lesefehler können je nach RAID und Dateisystem behoben werden; wiederholte I/O-Fehler, steigende Pending- oder Reallocated-Sektoren auf weiteren Platten oder ein abgebrochener Rebuild sind dagegen Warnsignale. Dann Last weiter reduzieren, aktuelle Daten sichern und keine zusätzlichen Datenträgeraktionen erzwingen.

Nach erfolgreichem Abschluss bleibt der Pool erst nach einer vollständigen Konsistenz- beziehungsweise Datenprüfung vertrauenswürdig. Ein Scrub prüft Parität oder Spiegelung und liefert den nötigen Nachweis für RAID-Rebuild und Datenintegrität. Erst bei fehlerfreiem Ergebnis sollten pausierte Dienste wieder schrittweise aktiviert werden.