Backup erfolgreich, Wiederherstellung gescheitert: Wenn das Sicherungs-NAS ausfällt

Ein mögliches Szenario: Im Fileserver eines mittelständischen Betriebs fallen über Nacht zwei Festplatten aus, das RAID startet nicht mehr. Der IT-Dienstleister bleibt gelassen, denn das Backup-NAS im Nebenraum hat jede Nacht gesichert, und die Protokolle der letzten Monate melden „Job erfolgreich". Die Wiederherstellung läuft an, kommt gut ein Drittel weit und bricht ab: Lesefehler auf dem Sicherungsziel. In der Verwaltungsoberfläche des NAS steht ein RAID, das seit Monaten im Zustand „degraded" läuft; die Warnmeldungen gingen an ein Postfach, das niemand mehr liest. Ein zweiter Versuch endet früher als der erste, danach wird das NAS nicht mehr erkannt. Das Leipziger Datenrettungslabor DATA REVERSE® erläutert, warum ein Backup als erfolgreich gelten kann und trotzdem nicht zurückkommt, was ein wiederholter Restore-Versuch an einem angeschlagenen Sicherungsspeicher auslösen kann und wie ein defektes Backup-Ziel im Labor rekonstruiert wird.

72 Prozent prüfen ihre Sicherung selten oder nie

In einer eigenen Befragung von DATA REVERSE® unter 285 kleinen und mittleren Unternehmen im ersten Quartal 2025 gaben 77 Prozent an, mindestens wöchentlich zu sichern. 72 Prozent der Befragten prüfen jedoch selten oder nie, ob sich ihre Sicherungen tatsächlich wiederherstellen lassen. Im Ernstfall kann sich dann erstmals zeigen, ob das Backup tatsächlich funktioniert.

Ein erfolgreicher Sicherungslauf allein beweist noch nicht, dass eine Wiederherstellung gelingt. Die Meldung „erfolgreich" bestätigt in der Regel, dass die Software ihre Daten vollständig auf das Ziel geschrieben hat. Ob diese Daten Monate später noch lesbar sind, ist eine andere Frage. Viele Backup-Produkte bieten dafür eigene Prüfungen an, etwa das Zurücklesen mit Prüfsummenvergleich oder einen Testlauf der Wiederherstellung. Diese Funktionen kosten Zeit und Speicherplatz und sind deshalb häufig abgeschaltet oder wurden nie eingerichtet.

Warum ein Sicherungsziel leise ausfällt

Ein Backup-NAS führt ein anderes Leben als ein Produktivsystem. Es wird nachts beschrieben und tagsüber kaum angefasst, Monate vergehen, ohne dass jemand einen größeren Bestand daraus liest. Dieser Rhythmus verdeckt Fehler. Festplatten können im Betrieb einzelne Bereiche entwickeln, die sich nicht mehr fehlerfrei lesen lassen; Hersteller geben dafür je nach Laufwerksklasse unterschiedliche Fehlerraten an. Solange diese Bereiche nur geschrieben und nie gelesen werden, fällt das nicht auf. Ein umfangreicher Restore ist dann oft der erste vollständige Lesevorgang seit langer Zeit, und er macht die Schwachstellen sichtbar.

Dazu kommt der Verbund. Fällt in einem RAID 5 eine Platte aus, läuft das System weiter, allerdings ohne die Reserve, für die der Verbund gebaut wurde. Warnmeldungen dazu können per E-Mail versendet werden. Bleibt die Meldung unbeachtet, arbeitet das Backup-Ziel monatelang ohne Redundanz. Ein Restore belastet die verbliebenen Laufwerke über Stunden stärker als das nächtliche Schreiben. Ein bereits geschwächtes Laufwerk kann unter dieser Last ausfallen, und mit dem zweiten Ausfall ist der Verbund nicht mehr lesbar. Ähnliches ist vom Rebuild bekannt: Wird nach einem Plattentausch der Verbund neu aufgebaut, müssen die übrigen Platten in großem Umfang gelesen werden, bislang unbemerkte Lesefehler können den Vorgang stören oder abbrechen.

Sicherungsketten haben eine eigene Verwundbarkeit. Inkrementelle Sicherungen speichern nur die Änderungen seit dem letzten Lauf und setzen auf einer Vollsicherung auf. Ist ein Glied dieser Kette beschädigt, lassen sich je nach Verfahren die Stände danach nicht mehr vollständig zusammensetzen. Und ein Snapshot auf demselben Speichersystem ersetzt keine Sicherung, er liegt auf denselben Platten, die gerade ausfallen.

Warum der zweite Versuch warten sollte

Bricht eine Wiederherstellung wegen Lesefehlern ab, liegt es nahe, sie sofort neu zu starten. Jeder weitere Durchlauf liest jedoch dieselben schwachen Bereiche erneut und belastet Laufwerke, die bereits Fehler zeigen. Bei einer Festplatte mit beginnenden Defekten kann sich der Zustand mit jedem Leseversuch verschlechtern, bei einem RAID ohne Redundanz kann ein weiterer Ausfall den Verbund unlesbar machen. Deshalb gehört nach dem ersten Abbruch die Frage, was am Sicherungsziel vorliegt, vor den nächsten Versuch.

Was im Labor mit einem defekten Backup-Ziel geschieht

Im Labor wird das Sicherungsziel als Satz einzelner Datenträger behandelt. Jede Platte wird zunächst hardwareseitig ausgelesen und als 1:1-Kopie gesichert, defekte Laufwerke werden bei Bedarf zunächst für das Auslesen vorbereitet. Alle weiteren Schritte laufen auf diesen Kopien: Der RAID-Verbund wird daraus rekonstruiert, anschließend das Dateisystem des NAS und darin die Sicherungsdateien. Am Ende steht die Prüfung, welche Sicherungsstände vollständig und in sich schlüssig sind. Ist eine Kette unterbrochen, wird sie bis zum letzten intakten Glied zurückverfolgt. Für die Analyse hilft es, wenn der Original-Controller beziehungsweise das NAS-Gehäuse mit ins Labor kommt, weil sich die Konfiguration des Verbunds daraus schneller ableiten lässt. Für Unternehmen, deren Betrieb steht, bietet DATA REVERSE® einen Express-Service an.

Was vor dem nächsten Restore-Versuch geschehen sollte

– Nach dem ersten Abbruch keinen zweiten Versuch starten. Das Sicherungsziel herunterfahren, bei einem NAS über die Verwaltungsoberfläche oder den Ausschalter, nicht durch Ziehen des Netzsteckers.
– Die Datenträger beim Ausbau nach Schacht beschriften oder fotografieren und in keiner anderen Reihenfolge wieder einsetzen. Ein NAS mit vertauschten Platten neu zu starten, gehört zu den häufigen Ursachen für logische Folgeschäden.
– Keinen Rebuild anstoßen und keine Platte tauschen, solange unklar ist, welches Laufwerk in welchem Zustand ist.
– Die Konfiguration der Sicherungssoftware, das Jobprotokoll und den Aufbewahrungsplan sichern. Sie zeigen, welche Stände vorhanden sein müssten und wie die Kette aufgebaut ist.
– Die Rotation anhalten, damit die Sicherungssoftware nicht turnusmäßig die letzte intakte Vollsicherung überschreibt.
– Wenn auch das Produktivsystem beschädigt ist, dort keine Reparatur- oder Neuinstallationsversuche starten. Solange das Backup nicht gesichert ist, bleibt es die zweite Quelle, aus der sich der Bestand rekonstruieren lässt.

Für den Regelbetrieb rät DATA REVERSE® zu Wiederherstellungstests, die mindestens quartalsweise unter realen Bedingungen laufen: ein vollständiger Restore auf getrennte Hardware, mit Zeitmessung und einem Funktionstest der wiederhergestellten Anwendungen. Das Sicherungsziel gehört in dieselbe Überwachung wie die Produktivsysteme, mit Alarmen für RAID-Status und Laufwerksfehler, die ein besetztes Postfach erreichen. Mindestens eine Kopie sollte außerhalb des Gebäudes oder vom Netz getrennt liegen, damit der Ausfall eines Speichersystems Original und Sicherung nicht zugleich trifft. DATA REVERSE® ist nach ISO 9001 und ISO/IEC 27001 zertifiziert und stellt Daten von Servern, RAID-Verbünden, NAS-Systemen und virtuellen Umgebungen wieder her. Fälle, in denen ein Unternehmen erst im Notfall feststellt, dass seine Sicherung defekt oder unvollständig ist, gehören zur täglichen Praxis des Leipziger Labors.