Ein konsistenter Dienst ist mehr als ein Snapshot
Einführung · 4 Abschnitte · ~15 Min Lesezeit · Stand
Konsistenzgrenzen
Datenbank, Queue, Cache, Dateien und externe Schnittstellen können verschiedene Zeitpunkte haben. Recovery braucht einen begründeten Konsistenzpunkt und eine fachliche Prüfung.
SQL-Log-Recovery vollständig schließen
Im SQL-Server-Full-Recovery-Model wird zuerst der Zielzeitpunkt und die zusammenhängende Backupkette bestimmt. Ist das Log nach dem Schaden zugänglich, wird ein mögliches Tail-Log-Backup vor dem Restore geprüft.
| **NORECOVERY** | Hält die Datenbank für weitere Differential- und Logrestores offen. |
|---|---|
| **RECOVERY** | Kommt erst nach dem letzten erforderlichen Log und bringt die Datenbank online. |
Fehlannahme: Online ist nicht fachlich konsistent
Eine online Datenbank beweist nicht, dass Queue, Zahlungsdienst oder andere Nebenwirkungen zum selben Geschäftsstand passen. Externe Effekte brauchen Idempotenz- oder Abgleichlogik; sie werden nicht durch einen Datenbankrestore automatisch korrigiert.
Transfer in die Checks
- Zielzeitpunkt und Kette bestimmen
- Daten- und Logrestores geordnet ausführen
- Mit `RECOVERY` online bringen
- Anwendung, Queue und Kerntransaktion abnehmen
Die folgenden Aufgaben prüfen Logkette, Recoverypfad, verteilte Nebenwirkungen und fachliche Abnahme getrennt.