> ## Content Index > Fetch the complete content index at: https://blog.lange-it.com/llms.txt > Use this file to discover other available public pages before exploring further. # Backups sind noch keine Wiederherstellung: Warum ich Restore-Tests wichtiger finde als grüne Backup-Jobs - URL: https://blog.lange-it.com/backups-wiederherstellung-restore-tests/ - Published: 2026-10-05T15:52:27.000Z - Updated: 2026-10-05T15:52:27.000Z - Description: Ein erfolgreicher Backup-Job beweist noch keine Wiederherstellbarkeit. Warum ich Restore-Tests, Konsistenz und einen dokumentierten Recovery-Weg für entscheidend halte. - Author: Peter Lange - Tags: Backup, Recovery, Selfhosting, Docker ## Ein grüner Backup-Job ist für mich nur der Anfang Backups haben eine beruhigende Eigenschaft: Solange sie regelmäßig laufen und keine Fehler melden, entsteht schnell das Gefühl, für den Ernstfall vorbereitet zu sein. Genau an dieser Stelle bin ich inzwischen vorsichtig geworden. Ein erfolgreicher Backup-Job beantwortet zunächst nur eine begrenzte Frage: **Konnte die vorgesehene Sicherung erzeugt und am Ziel abgelegt werden?** Die wichtigere Frage lautet für mich: **Wenn das ursprüngliche System morgen vollständig weg wäre – könnte ich aus dieser Sicherung wieder einen funktionierenden Dienst herstellen?** Zwischen diesen beiden Aussagen liegt ein erheblicher Unterschied. Deshalb betrachte ich Backup und Recovery nicht mehr als dieselbe Aufgabe. ## Was ein Backup tatsächlich beweist Ein erfolgreiches Backup kann sehr wertvoll sein. Je nach Verfahren kann ich prüfen, ob eine Sicherungsdatei existiert, ob ein Archiv lesbar ist, ob Prüfsummen stimmen oder ob ein Datenbank-Dump ohne Fehler erzeugt wurde. Das alles sind sinnvolle Kontrollen. Sie beweisen aber noch nicht, dass der gesamte Dienst wiederherstellbar ist. Gerade bei selbst betriebenen Anwendungen besteht ein System selten nur aus einem Verzeichnis. Typischerweise gehören mehrere Bestandteile zusammen: - Datenbank - persistente Anwendungsdaten - Konfiguration - Secrets und Schlüsselmaterial - Deployment-Definitionen - gegebenenfalls Zertifikate - externe Dienste und Abhängigkeiten Fehlt einer dieser Bestandteile oder ist sein Wiederherstellungsweg unbekannt, kann eine formal erfolgreiche Datensicherung im Ernstfall trotzdem wenig helfen. NIST behandelt Backup und Recovery deshalb als Teil einer umfassenderen Contingency-Strategie. Dazu gehören nicht nur Sicherungen, sondern auch Wiederherstellungsstrategien, Tests und die laufende Pflege des Plans.\[^1\] ## Daten sichern ist nicht dasselbe wie einen Dienst sichern Ein einfaches Beispiel ist eine Webanwendung mit Datenbank und persistenten Dateien. ![Abhängigkeiten einer wiederherstellbaren Webanwendung](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-backup-application-dependencies-flow.png) Ich kann die Datenbank sichern und zusätzlich die Dateien kopieren. Damit habe ich zwei Backups. Für eine vollständige Wiederherstellung muss ich aber noch wissen, wie daraus wieder ein lauffähiges System entsteht. Welche Softwareversion wird benötigt? Woher kommt die Deployment-Konfiguration? Welche Umgebungsvariablen oder Schlüssel fehlen auf einem frischen Host? Welche Verzeichnisse und Berechtigungen erwartet die Anwendung? Welche externen Namen oder Dienste müssen wieder erreichbar sein? Bei Docker wird diese Trennung besonders anschaulich. Docker dokumentiert Volumes als persistente Datenspeicher und beschreibt auch deren Backup und Restore.\[^2\] Ein wiederhergestelltes Volume allein beschreibt aber noch nicht den gesamten Stack, der diese Daten verwendet. Das ist für mich der entscheidende Perspektivwechsel: **Nicht die Sicherungsdatei ist das eigentliche Ziel. Das Ziel ist ein wieder funktionsfähiger Dienst.** ## Konsistenz gehört zum Backup-Konzept Noch schwieriger wird es, wenn mehrere Datenquellen logisch zusammengehören. Eine Datenbank kann für sich betrachtet konsistent gesichert sein. PostgreSQL beschreibt beispielsweise, dass `pg_dump` einen intern konsistenten Snapshot der Datenbank erzeugt, auch während andere Zugriffe stattfinden.\[^3\] Das beantwortet aber nicht automatisch die Frage, ob ein separat erzeugtes Dateibackup exakt zum selben Anwendungszustand gehört. Angenommen, eine Anwendung speichert Metadaten in der Datenbank und große Dateien im Dateisystem. Zwischen Datenbank-Dump und Dateisicherung können neue Dateien entstehen, andere gelöscht oder Zuordnungen verändert werden. Beide Sicherungen können technisch fehlerfrei sein und trotzdem unterschiedliche Zeitpunkte repräsentieren. Deshalb gehört zur Backup-Planung auch die Frage: **Welche Bestandteile müssen gemeinsam einen konsistenten Wiederherstellungspunkt bilden?** Ein blindes Kopieren laufender Datenbanken ist ebenfalls keine allgemeine Lösung. Die aktuelle PostgreSQL-Dokumentation weist beispielsweise darauf hin, dass ein einfacher Dateisystem-Backup des Datenverzeichnisses bei laufendem Server ohne geeignetes Snapshot- oder Archivierungsverfahren nicht als brauchbare Sicherungsmethode behandelt werden sollte.\[^4\] Das konkrete Verfahren hängt vom jeweiligen System ab. Die grundlegende Frage bleibt aber gleich: Kann ich erklären, welchen Zustand meine Sicherung tatsächlich repräsentiert? ## Mein Prüfmodell: vom Backup zum funktionierenden Restore Ich finde es hilfreich, die Sicherung nicht als einzelnen Job, sondern als Kette zu betrachten: ![Ablauf vom erstellten Backup bis zur geprüften Wiederherstellung](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-backup-recovery-proof-flow.png) Jede Stufe beantwortet eine andere Frage. | Stufe | Was ich damit wissen möchte | | ---------------------- | --------------------------------------------------------------------------------------------- | | Backup erstellt | Wurden die vorgesehenen Daten gesichert? | | Integrität geprüft | Ist das Sicherungsartefakt technisch lesbar und vollständig genug für das gewählte Verfahren? | | Abhängigkeiten bekannt | Weiß ich, was außer den eigentlichen Daten für den Dienst benötigt wird? | | Restore durchgeführt | Lässt sich die Sicherung tatsächlich zurückspielen? | | Funktion geprüft | Arbeitet der wiederhergestellte Dienst anschließend wie erwartet? | Erst die letzte Stufe kommt der Aussage nahe, die ich im Ernstfall wirklich brauche. ## Ein Restore-Test muss nicht gleich ein Totalausfall sein Restore-Tests werden manchmal gedanklich sofort mit einem vollständigen Disaster-Recovery-Test gleichgesetzt. Das macht die Hürde unnötig hoch. Ich kann bereits deutlich früher sinnvolle Erkenntnisse gewinnen. Eine Datenbank lässt sich in eine separate Testinstanz zurückspielen. Ein Volume kann in eine temporäre Umgebung restauriert werden. Konfigurationsdateien können darauf geprüft werden, ob alle referenzierten Dateien und Secrets verfügbar wären. Ein kleiner Test-Stack kann zeigen, ob die dokumentierte Reihenfolge überhaupt funktioniert. Ein solcher Test beantwortet noch nicht jede Worst-Case-Frage. Er entdeckt aber viele Probleme, solange das Produktivsystem noch funktioniert. Ein vollständiger Recovery-Test geht weiter: Ausgangspunkt ist dann möglichst eine Umgebung, in der ich nicht stillschweigend auf Bestandteile des bestehenden Systems zurückgreifen kann. Genau dabei werden vergessene Abhängigkeiten sichtbar. ## Die Recovery-Matrix Für komplexere Dienste verwende ich gedanklich eine einfache Matrix. Sie zwingt dazu, nicht nur nach dem Vorhandensein eines Backups zu fragen. | Bestandteil | Backup vorhanden? | Restore getestet? | Funktion geprüft? | | ---------------------- | ----------------- | ----------------- | ----------------- | | Datenbank | Ja/Nein | Ja/Nein | Ja/Nein | | Anwendungsdaten | Ja/Nein | Ja/Nein | Ja/Nein | | Konfiguration | Ja/Nein | Ja/Nein | Ja/Nein | | Secrets/Schlüssel | Ja/Nein | Ja/Nein | Ja/Nein | | Deployment-Definition | Ja/Nein | Ja/Nein | Ja/Nein | | Externe Abhängigkeiten | dokumentiert? | erreichbar? | geprüft? | Schon diese einfache Darstellung verändert den Blick auf den Backup-Status. Eine Spalte voller „Ja“ bei **Backup vorhanden?** kann daneben sehr schnell eine Spalte voller „Nein“ bei **Restore getestet?** haben. Genau dort steckt das Risiko, das ein grüner Backup-Job nicht zeigt. ## Auch der gestartete Dienst ist noch nicht das Ende Nach einem Restore reicht mir nicht die Meldung, dass ein Container oder Prozess wieder läuft. Das ist dieselbe Unterscheidung, die bei Healthchecks wichtig ist: Ein laufender Prozess beweist nicht automatisch, dass die Anwendung ihre Aufgabe erfüllen kann. Nach einer Wiederherstellung möchte ich deshalb mindestens die wesentlichen Funktionen prüfen. Bei einer Webanwendung könnte das bedeuten: Anwendung erreichbar, Datenbankzugriff funktioniert, erwartete Daten vorhanden, Schreiben und Lesen möglich, Hintergrundprozesse arbeiten und relevante externe Abhängigkeiten sind erreichbar. Der genaue Test hängt vom Dienst ab. Entscheidend ist, dass **Restore erfolgreich** nicht mit **Prozess gestartet** gleichgesetzt wird. ## Dokumentation ist Teil der Wiederherstellbarkeit Ein weiterer Punkt wird erst im Ernstfall unangenehm sichtbar: Wissen kann eine Abhängigkeit sein. Wenn nur eine Person weiß, in welcher Reihenfolge Sicherungen zurückgespielt werden müssen, wo Schlüssel liegen oder welche Konfiguration zuerst benötigt wird, ist dieses Wissen faktisch Bestandteil des Recovery-Plans. NIST beschreibt Contingency Planning ausdrücklich als Zusammenspiel aus Plänen, Verfahren und technischen Maßnahmen zur Wiederherstellung von Systemen, Betrieb und Daten nach einer Störung.\[^5\] Genau deshalb gehört für mich ein verständlicher Wiederherstellungsweg genauso zum Backup-Konzept wie die Sicherungsdatei selbst. Eine gute Recovery-Dokumentation muss dabei nicht riesig sein. Sie sollte vor allem ausführbar sein. Ich möchte im Ernstfall nicht rekonstruieren müssen, was ich vor einem Jahr vermutlich gemeint habe. ## Der unangenehme, aber nützliche Worst-Case-Test Die härteste Frage bleibt für mich: **Was wäre übrig, wenn der ursprüngliche Host vollständig verloren wäre?** Nicht: Was liegt noch auf seinem Dateisystem? Nicht: Welche Container könnte ich noch inspizieren? Nicht: Welche Konfiguration könnte ich dort noch schnell nachsehen? Sondern wirklich: Welche extern gesicherten Daten, Dokumentationen, Schlüssel und Deployment-Informationen reichen aus, um den Dienst auf einem neuen System wieder aufzubauen? Dieser Test ist unangenehm, weil er Lücken sichtbar macht. Genau deshalb ist er wertvoll. Redundanz, RAID oder ein zweiter laufender Server können die Verfügbarkeit verbessern. Sie ersetzen aber nicht automatisch eine Recovery-Strategie. Auch NIST trennt solche technischen Verfügbarkeitsmaßnahmen von der eigentlichen Backup- und Recovery-Planung.\[^1\] ## Wann ich ein Backup für belastbar halte Ich erwarte von einem Backup nicht, dass jeder denkbare Totalausfall täglich vollständig simuliert wird. Das wäre für viele private und kleinere professionelle Umgebungen unverhältnismäßig. Ich möchte aber drei Dinge beantworten können: 1. **Was genau sichere ich?** 2. **Wie stelle ich es wieder her?** 3. **Woran erkenne ich anschließend, dass der Dienst wirklich funktioniert?** Wenn ich die zweite Frage nur theoretisch beantworten kann, fehlt mir ein wichtiger Nachweis. Deshalb sind Restore-Tests für mich inzwischen mindestens so wichtig wie die eigentlichen Backup-Jobs. Sie prüfen nicht nur die Daten. Sie prüfen das Verfahren, die Dokumentation und meine Annahmen über das System. Ein grüner Backup-Job ist beruhigend. **Ein erfolgreich getesteter Restore ist belastbarer.** ## Quellen \[^1\]: NIST SP 800-34 Rev. 1, *Contingency Planning Guide for Federal Information Systems*: \[^2\]: Docker Docs, *Volumes – Back up, restore, or migrate data volumes*: \[^3\]: PostgreSQL 18 Documentation, *SQL Dump*: \[^4\]: PostgreSQL 18 Documentation, *File System Level Backup*: \[^5\]: NIST CSRC, *Contingency planning*: