Ein erfolgreicher Sicherungsvorgang zeigt mir lediglich an, dass ein Prozess abgeschlossen wurde. Er gibt mir jedoch keinen Aufschluss darüber, ob die Anwendung wiederhergestellt werden kann. Dieser Unterschied wird schmerzlich deutlich, wenn der ursprüngliche Server nicht mehr verfügbar ist und sich niemand mehr daran erinnert, wo der Verschlüsselungsschlüssel gespeichert wurde.
Für ein kleines Team möchte ich einen Wiederherstellungsplan, den ein anderer Entwickler auch unter Zeitdruck befolgen kann. Der Plan sollte die Reihenfolge der Schritte sowie die erforderlichen Nachweise erläutern, um die Anwendung wieder als einsatzfähig zu erklären.
Beginnen Sie mit zwei geschäftlichen Fragen
Wie viele aktuelle Daten kann sich das Unternehmen leisten zu verlieren, und wie lange darf der Dienst nicht verfügbar sein? Diese Antworten legen die Wiederherstellungsziele (Recovery Point Objective und Recovery Time Objective) fest. Sie sollten mit den Personen abgestimmt werden, die auf die Anwendung angewiesen sind.
Eine tägliche Datenbankkopie mag für ein internes Berichtstool geeignet sein, für ein stark ausgelastetes Auftragssystem jedoch inakzeptabel. Ebenso kann ein Backup, dessen Wiederherstellung viele Stunden dauert, zwar technisch einwandfrei sein, aber den geschäftlichen Anforderungen nicht genügen.
Ich halte die dem Ziel zugrunde liegenden Annahmen fest: Datenvolumen, verfügbare Infrastruktur, Zugang zum Betreiber und die Frage, ob die Wiederherstellung beim selben Anbieter erfolgt. Eine Schätzung der Wiederherstellungszeit, die von einem funktionsfähigen Originalserver ausgeht, ist nicht aussagekräftig, wenn gerade dieser Server die ausgefallene Komponente ist.
Listen Sie alles auf, wovon die Datenbank abhängt
Für die Wiederherstellung einer Anwendung sind in der Regel mehr als nur Tabellen erforderlich. Hochgeladene Dateien, Verschlüsselungsschlüssel, Konfigurationen, Schemamigrationen, Identitätseinstellungen und Bereitstellungsartefakte können ebenfalls erforderlich sein, um die wiederhergestellten Daten zu interpretieren oder zu nutzen.
Ich bewahre Geheimnisse getrennt von den normalen Anwendungsdateien auf, doch für den Wiederherstellungsvorgang ist dennoch ein autorisierter Weg erforderlich, um sie abzurufen. „Die Schlüssel sind sicher“ und „die Schlüssel sind wiederherstellbar“ sind zwei unterschiedliche Eigenschaften.
In der Bestandsliste sollten auch Abhängigkeiten erfasst werden, die nicht in ein Backup gehören, wie beispielsweise der Status externer Zahlungen. Nach der Wiederherstellung muss die Anwendung möglicherweise ihre lokalen Datensätze mit denen eines Anbieters abgleichen, anstatt davon auszugehen, dass beide Systeme zum gleichen Zeitpunkt angehalten wurden.
In einer isolierten Umgebung wiederherstellen
Eine Testlauf sollte auf der Grundlage der gespeicherten Sicherungskopie starten, nicht auf der Grundlage einer bequemen Kopie der laufenden Datenbank. Ich möchte, dass im Rahmen dieser Übung der Zugriff, die Entschlüsselung, die Übertragung, die Wiederherstellung und der Start der Anwendung getestet werden.
Die wiederhergestellte Anwendung darf keine E-Mails an Kunden versenden, keine Live-Zahlungsvorgänge ausführen und keine ausgehenden Webhooks auslösen. Bevor ich die Worker starte, deaktiviere ich diese Integrationen oder ersetze deren Anmeldedaten durch Testkonfigurationen. Andernfalls kann eine Wiederherstellungsübung selbst zu einem Produktionsvorfall führen.
In der Dokumentation zu SQL-Dumps in PostgreSQL werden die Funktionsweise und die Einschränkungen logischer Sicherungen erläutert. Bei der Wahl einer Sicherungsmethode sollten die Datenbankgröße und die Anforderungen an die Wiederherstellung berücksichtigt werden; ein logischer Dump ist nicht automatisch für jede Arbeitslast die richtige Lösung.
Überprüfen Sie das Verhalten, nicht nur die Zeilenanzahl
Ich verwende eine kurze Checkliste für die Wiederherstellung auf Anwendungsebene:
- Kann sich ein autorisierter Benutzer anmelden?
- Kann die Anwendung repräsentative aktuelle und ältere Datensätze auslesen?
- Stimmen die hochgeladenen Assets und ihre Datenbankverweise überein?
- Kann eine Testtransaktion sicher abgeschlossen werden?
- Sind die Hintergrundprozesse bereit, ohne dass unbeabsichtigte historische Aufgaben ausgeführt werden?
- Bleiben die Tenant-Grenzen nach der Wiederherstellung weiterhin bestehen?
Zählwerte und Prüfsummen helfen dabei, fehlende Daten zu identifizieren, beweisen jedoch nicht, dass die Anwendung betriebsbereit ist. Ich halte außerdem die tatsächliche Dauer der Wiederherstellung fest und vermerke, in welchen Fällen der Bediener auf nicht dokumentiertes Wissen zurückgreifen musste.
Machen Sie Überraschungen zu Wartungsarbeiten
Eine Testlauf, bei dem ein Problem entdeckt wird, hat seinen Zweck erfüllt. Fehlende Berechtigungen, veraltete Anweisungen und inkompatible Anwendungsversionen lassen sich kostengünstiger aufdecken, solange der Produktivbetrieb reibungslos läuft.
Ich aktualisiere das Runbook umgehend und wiederhole dann den fehlgeschlagenen Teil. Der Eintrag sollte die Backup-Kennung, die Anwendungsversion, die Wiederherstellungsumgebung, das Ergebnis und die verbleibenden Lücken enthalten.
Mein Vertrauen in ein Backup beruht auf einer kürzlich durchgeführten, wiederholbaren Wiederherstellung. Der geplante Auftrag erstellt das Material; die Probe zeigt, ob das Team dieses Material wieder in einen Dienst umwandeln kann.
Aktualisiert am 25. September 2026.