Führen Sie eine Wiederherstellungsübung durch: Machen Sie aus RPO und RTO ein Wiederherstellungsverfahren
Ein erfolgreicher Backup-Job meldet, dass eine Kopie erstellt wurde. Eine Wiederherstellungsübung beantwortet die nützlichere Frage: Kann das Team einen funktionierenden Dienst mit akzeptablem Datenverlust innerhalb der Zeit wiederherstellen, die das Projekt tolerieren kann?
Das Wichtigste in Kürze
Legen Sie explizite Wiederherstellungsziele fest, stellen Sie eine stimmige Kopie in einer isolierten Umgebung wieder her, testen Sie wichtiges Anwendungsverhalten und zeichnen Sie gemessene Ergebnisse auf, statt anzunehmen, dass der Zeitplan ausreicht.
Trennen Sie das Datenverlustziel vom Wiederherstellungszeitziel
Das Recovery Point Objective, oder RPO, beschreibt den Zeitpunkt, bis zu dem Daten wiederherstellbar sein müssen. Das Recovery Time Objective, oder RTO, betrifft, wie lange die Wiederherstellung dauern darf, bevor die Unterbrechung eine unannehmbare Auswirkung hat. Übersetzen Sie beides in ein Geschäftsgespräch, bevor Sie Software auswählen. Eine Portfolio-Website kann eine andere Unterbrechung tolerieren als ein Dienst, der jede Minute neue Bestellungen annimmt.
Betrachten Sie eine beispielhafte Buchungsanwendung, deren Eigentümer höchstens eine Stunde verlorener Aktualisierungen akzeptiert und den Dienst innerhalb von zwei Stunden wiederherstellen möchte. Eine nächtliche Kopie allein kann das Datenziel von einer Stunde nicht belegen: Ein Vorfall nahe dem Ende des täglichen Intervalls könnte deutlich neuere Arbeit verlieren. Die Beispielziele gehören zu diesem Projekt; sie sind keine HM Bastion-Wiederherstellungszusage.
Wählen Sie eine präzise Messgrenze. Halten Sie fest, wann der Dienst nicht verfügbar wurde, wann der Vorfall erkannt wurde und wann der getestete Dienst zurückkehrte. Unterscheiden Sie bei einer geplanten Übung zwischen der Zeit für den Neuaufbau und der Zeit, die auch benötigt würde, um einen Vorfall zu bemerken, eine Genehmigung einzuholen und Anmeldeinformationen abzurufen. Wenn nur der schnellste Import-Schritt gemeldet wird, bleibt die Arbeit verborgen, die eine echte Wiederherstellung verzögert.
Sichern Sie alles, was zur Wiederherstellung eines konsistenten Dienstes erforderlich ist
| Wiederherstellungskomponente | Was aufzubewahren ist | Häufige Auslassung |
|---|---|---|
| Anwendung | Release-Kennung, Abhängigkeiten und Deployment-Anweisungen | Der Quellcode existiert, aber das erforderliche Release kann nicht neu gebaut werden |
| Datenbank | Ein unterstütztes konsistentes Backup plus erforderliche Rollen oder Konfiguration | Es wird angenommen, dass eine Kopie der Live-Datenbankdateien wiederherstellbar ist |
| Benutzerinhalte | Uploads, Dokumente und Speicherberechtigungen | Datenbankzeilen verweisen auf fehlende Dateien |
| Private Konfiguration | Wiederherstellbare Geheimnisse und Zugriff auf ihre Verschlüsselungsschlüssel | Der Schlüssel ist nur auf dem ausgefallenen Server verfügbar |
| Betrieb | DNS-Details, geplante Jobs und Anforderungen an externe Dienste | Die wiederhergestellte Website sendet unerwartet Live-Nachrichten |
Verwenden Sie eine von der Datenbank-Engine unterstützte Backup-Methode. PostgreSQL-logische Dumps liefern eine konsistente Datenbanksicht, während clusterweite Rollen gesondert betrachtet werden müssen. Dateibasiertes Backup und kontinuierliche Archivierung folgen unterschiedlichen Anforderungen. Ein logischer Dump ist nicht austauschbar mit dem Basis-Backup und den archivierten WAL-Dateien, die für die Point-in-Time-Wiederherstellung benötigt werden. Wählen Sie eine dokumentierte Methode und testen Sie diese, statt inkompatible Teile zu kombinieren.
Datenbank und hochgeladene Dateien koordinieren. Wenn ein Kunde während der Kopie ein Dokument hochlädt, können ein Datenbank-Backup und ein deutlich älteres Dateiarchiv unterschiedliche Anwendungszustände beschreiben. Legen Sie eine Wartungs- oder Konsistenzstrategie fest, die zur Anwendung passt, und beziehen Sie einen aktuellen Beispielanhang in die Wiederherstellungsprüfungen ein. Dateianzahlen allein belegen nicht, dass die richtigen Dateien zu den wiederhergestellten Datensätzen passen.
Die Wiederherstellungskopie unabhängig und erreichbar machen
Bewahren Sie eine Wiederherstellungskopie außerhalb des Ausfallpfads auf, für den Sie planen. Ein weiteres Verzeichnis auf derselben Festplatte hilft nicht, wenn diese Festplatte verloren geht. Eine Kopie, die von derselben kompromittierten Anwendungs-Anmeldeinformation kontrolliert wird, kann auch von einem Angreifer entfernt werden. Wählen Sie Speicherzugriff, Aufbewahrung und etwaige Unveränderlichkeitskontrollen bewusst und bestätigen Sie deren tatsächliches Verhalten, statt sich auf ein Produktetikett zu verlassen.
Verschlüsseln Sie Kopien mit sensiblen Informationen und halten Sie den Wiederherstellungsschlüssel über ein separat kontrolliertes Verfahren verfügbar. Berechtigen Sie die Personen, die sie wiederherstellen müssen, und testen Sie den Abruf mit den Berechtigungen, die sie während eines Vorfalls haben werden. Beziehen Sie das Wachstum des Backup-Speichers und die Übertragungszeit in die Planung ein. Eine Kopie, die technisch existiert, aber vom Wiederherstellungsoperator nicht heruntergeladen werden kann, ist nicht einsatzbereit.
In eine sichere Umgebung wiederherstellen und einen konkreten Test durchführen
- Wählen Sie ein abgeschlossenes Backup aus und erfassen Sie dessen Wiederherstellungszeitpunkt, Größe und Integritätsnachweis.
- Bereiten Sie ein isoliertes Ziel mit den erforderlichen Softwareversionen und ausreichend temporärem Speicher vor.
- Blockieren Sie echte E-Mails, Zahlungsaufrufe, geplante Jobs und Webhooks, bevor Sie die wiederhergestellte Anwendung starten.
- Stellen Sie Datenbank, Dateien und private Konfiguration nach dem dokumentierten Verfahren wieder her.
- Prüfen Sie Anmeldung, repräsentative Datensätze, eine hochgeladene Datei und einen synthetischen Schreibvorgang in der isolierten Kopie.
- Erfassen Sie den letzten wiederhergestellten Datenpunkt, die verstrichenen Phasen, Fehler und Entscheidungen der Operatoren.
Suchen Sie im Buchungsbeispiel eine bekannte Reservierung unmittelbar vor der Backup-Grenze und prüfen Sie den zugehörigen Kunden und Anhang. Bestätigen Sie, dass die erwartete aktuelle Reservierung erscheint und ein absichtlich später angelegter Testdatensatz nicht. Legen Sie dann eine synthetische Reservierung in der isolierten Kopie an. Dies testet Beziehungen und Schreibfähigkeit, ohne einen echten Kunden zu kontaktieren oder die Produktion zu verändern.
Verwenden Sie ein Phasenprotokoll: Abruf der Anmeldeinformationen, Vorbereitung des Ziels, Download, Verifikation, Import, Anwendungsstart und Abnahmeprüfungen. Angenommen, der Import dauert zwanzig Minuten, die Zugriffsgenehmigung aber fünfzig. Die nächste Verbesserung ist das Zugriffsverfahren, nicht unbedingt ein schnellerer Datenbankplan. Halten Sie das gemessene Ergebnis auch dann fest, wenn es das Ziel verfehlt; eine fehlgeschlagene Übung hat Arbeit aufgezeigt, während der Dienst noch gesund ist.
Das Übungsergebnis in einen gepflegten Wiederherstellungsnachweis überführen
Weisen Sie jeder fehlgeschlagenen Prüfung einen Verantwortlichen zu und wiederholen Sie den betroffenen Teil nach der Behebung. Fehlende Uploads erfordern ein besseres Backup-Set; nicht unterstützte Erweiterungen erfordern ein reproduzierbares Software-Inventar. Wiederholen Sie eine vollständige Übung nach wichtigen Änderungen an Anwendung oder Speicher und in einer durch das Projekt begründeten Häufigkeit. Vermerken Sie das Datum der letzten erfolgreichen Wiederherstellung in den Betriebsnotizen.
Lesen Sie Hosting-Backup-Funktionen getrennt von Ihrem eigenen Wiederherstellungsverfahren. Replikation, Snapshots und aufbewahrte Backups haben unterschiedliche Rollen und Ausfallgrenzen. Bestätigen Sie die Funktionen und den Wiederherstellungsumfang Ihres erworbenen Dienstes mit dem Team. Ein getestetes Anwendungs-Wiederherstellungsverfahren bleibt wertvoll, auch wenn die Infrastruktur zusätzliche Wiederherstellungswerkzeuge bietet.
