Wiederherstellung
Recovery stellt Daten und Funktionen nach einem Ausfall in einen arbeitsfähigen Zustand zurück. Ein Backup ist erst praktisch nutzbar, wenn Restore und Ergebnisprüfung geübt sind.
- RPOZulässiger Datenverlust in Minuten.
- RTOZulässige Ausfallzeit bis zum Betrieb.
- Backup-TaktJe dichter, desto weniger Verlust.
Einordnung
Warum das wichtig ist
Ein Backup nützt nur, wenn sich daraus ein arbeitsfähiger Stand herstellen lässt. Takt der Sicherung und Weg der Wiederherstellung bestimmen, wie viele Daten fehlen und wie lange der Shop steht. Deployment und Risikolog vertiefen.
Dieser Baustein behandelt Wiederanlauf und Wiederherstellungsnachweis. Deployment steuert Versionen; Datenmigration sichert Schemaübergänge.
Auf einen Blick · Vom Ausfall zur geprüften Wiederherstellung
Datenverlust und Ausfallzeit gegen Ziele
Ein Fehler beschädigt den Bestellindex. Das Team stellt einen gesicherten Stand in einer isolierten Umgebung wieder her und vergleicht Bestellungen mit dem Zahlungssystem.
So liest du das Bild
- RPO Die Zeile „Datenverlust (RPO)“ zeigt die Zeit seit dem letzten Backup gegen das Ziel.
- RTO Die Zeile „Ausfallzeit (RTO)“ zeigt die Dauer des gewählten Wiederherstellungswegs.
- Backup-Takt „Tägliches Backup“ ergibt bei Ausfall um 14:30 mehr Verlust als „Stündliches Backup“.
- Datenverlust (RPO)
- 14 h 30 min Bestelldaten
- Ziel 1 h · Ziel verfehlt
- Ausfallzeit (RTO)
- 4 h
- Ziel 4 h · Ziel erfüllt
Mindestens ein Ziel ist verfehlt: Sichere häufiger oder wähle einen schnelleren Wiederherstellungsweg.
Zeiten und Ziele illustrativ
Nutzen & Grenzen
Hilft, wenn
- Kritische persistente Daten brauchen eine gemessene Wiederherstellung innerhalb vereinbarter Zeit- und Verlustgrenzen.
- Beschädigte Datenstände oder Bedienfehler lassen sich über einen geprüften Wiederherstellungspunkt gezielt zurückführen.
Grenzen
- Replikation überträgt auch versehentliche Änderungen; kombiniere sie mit aufbewahrten Wiederherstellungspunkten und teste gezielte Rücksprünge.
- Eine Restore-Probe belegt nur den getesteten Ablauf; dokumentiere Datenstand, Dauer und Abweichungen von den vereinbarten Zielen.
- Technisch erfolgreiche Wiederherstellung reicht nicht; der fachliche Abgleich der Bestellungen mit Zahlungen gehört ins Risikolog und in den Ablauf.
In der Praxis
- Ziele aus Wirkung ableiten. Vereinbare tolerierte Datenlücke und Wiederanlaufdauer mit den Verantwortlichen des Dienstes. Ordne unterschiedliche Speicher und Funktionen ihren jeweiligen Folgen zu. Das Ergebnis sind fachlich begründete RPO- und RTO-Werte.
- Wiederherstellungskette absichern. Prüfe Backups, Änderungsprotokolle, Schlüssel, Konfiguration, Versionen und notwendige Abhängigkeiten. Stelle sicher, dass Reihenfolge und Berechtigungen im Runbook nachvollziehbar sind. Damit ist das Material für einen vollständigen Wiederanlauf verfügbar.
- Restore-Probe durchführen und messen. Stelle Daten isoliert wieder her, prüfe fachliche Konsistenz und erfasse Zeit sowie Datenlücke. Vergleiche beide Messwerte mit den vereinbarten Zielen und weise Abweichungen zu. Das Ergebnis ist ein belegter Status und ein konkreter Verbesserungsbedarf.
Ausführliche Erklärung lesen
Recovery umfasst die Wiederherstellung von Daten, Abhängigkeiten und Betriebsfähigkeit. Das Recovery Point Objective (RPO) beschreibt die tolerierte zeitliche Datenlücke; das Recovery Time Objective (RTO) setzt die gewünschte Wiederanlaufdauer. Point-in-Time Recovery benötigt ein Basisbackup sowie eine lückenlose Folge archivierter Änderungen. Der Wiederanlauf ergänzt die Ausfallregeln aus Verfügbarkeit und muss mit dem regulären Deployment & Rollout zusammenpassen.
Ein gestarteter Datenspeicher ist noch kein fachlich nutzbarer Dienst. Konfiguration, Schlüssel, Zugriffsrechte, abhängige Systeme und Konsistenzprüfungen gehören zum Wiederanlauf. Eine isolierte Probe misst tatsächliche Datenlücke und Dauer, ohne produktive Daten zu verändern. Runbooks benennen Reihenfolge und Verantwortlichkeiten. Wiederholte Proben liefern die Grundlage, um Ziele realistisch festzulegen und offene Engpässe gezielt zu beseitigen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Ausfall um 14:30, stündliches Backup, Restore aus Backup. Wie groß sind Datenverlust und Ausfallzeit, und werden die Ziele erfüllt?
Lösung mit Begründung ansehen
Datenverlust 30 Minuten (Backup um 14:00), Ausfallzeit 240 Minuten. Beide Ziele (RPO 60, RTO 240) sind erfüllt.
AnwendenAuf eine neue Lage übertragen
Ausfall um 09:00, tägliches Backup, Umschalten auf Standby. Welches Ziel wird verfehlt, und was änderst du?
Lösung mit Begründung ansehen
Das RPO: 540 Minuten seit dem Backup um 00:00 bei Ziel 60. Die Ausfallzeit von 15 Minuten passt. Wechsle auf stündliches Backup oder Logsicherung.
BewertenEine Alternative abwägen
Standby statt Restore aus Backup: Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Dafür: 15 statt 240 Minuten Ausfallzeit, deutlich mehr Reserve zum Ziel. Dagegen: zusätzlicher Betriebsaufwand, und ein Standby kann versehentliche Änderungen mit übernehmen. Empfehlung: Restore genügt knapp für RTO 240; für Reserve Standby ergänzen und Wiederherstellungspunkte aufbewahren.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- PostgreSQL – Backup and Restore (öffnet in neuem Tab)Vergleicht Sicherungsverfahren und Wiederherstellungswege für Datenbanken.
- AWS – Disaster recovery options in the cloud (öffnet in neuem Tab)Ordnet Wiederherstellungsstrategien anhand RTO und RPO ein.
- Google SRE – Data Integrity (öffnet in neuem Tab)Erklärt verlässliche Datensicherung, Wiederherstellung und regelmäßig geprüfte Recovery-Verfahren.