SQL Server-Praxis

Zeitpunktwiederherstellung: Das richtige Ziel nachweisen

Eine lückenlose Sicherungskette auswählen, STOPAT richtig bestimmen und Geschäftsdaten vor der Freigabe einer wiederhergestellten Datenbank prüfen.

Eine Wiederherstellung auf einen Zeitpunkt beschreibt, welche Transaktionen in der zurückgewonnenen Datenbank enthalten sein sollen. „Kurz vor dem Löschen“ reicht als Arbeitsanweisung nicht aus. Benötigt werden ein belastbarer Zeitstempel, eine vollständige Sicherungskette und fachliche Prüfungen. Dieser Ablauf setzt das vollständige Wiederherstellungsmodell und eine bereits eingerichtete Protokollsicherung voraus.

Zuerst das fachliche Ziel bestimmen

Angenommen, eine Bereitstellung löscht um 14:30 falsche Rechnungen. Das Anwendungsprotokoll kann den Eingang einer Anfrage zeigen, obwohl deren Transaktion erst später bestätigt wird. Die Uhr eines Kunden kann außerdem eine andere Zeitzone verwenden. Verbinden Sie Datenbanknachweise, Anfragekennungen und protokollierte Geschäftsänderungen, bevor Sie die Grenze festlegen. Bewahren Sie Beweise auf, statt die beschädigte Datenbank sofort zu überschreiben.

Stellen Sie möglichst unter einem anderen Datenbanknamen und mit separaten physischen Dateien wieder her. Das erhält den ursprünglichen Zustand zur Untersuchung und ermöglicht eine fachliche Abnahme. Dafür benötigen Sie zusätzlichen Speicherplatz. Verhindern Sie außerdem, dass Aufträge und externe Integrationen die Kopie wie Produktion behandeln. Eine Datenbankwiederherstellung widerruft keine bereits verschickte Nachricht oder ausgeführte externe Zahlung.

Dokumentieren Sie die verwendete Zeitbasis. Der Beispielwert unten steht für die überprüfte Serverzeit und behauptet nicht, UTC zu sein. Mehrdeutige Uhrzeiten bei einer Zeitumstellung erfordern einen eigenen Test. Eine pauschale Grenze eine Sekunde vor dem Fehler kann auch richtige Änderungen ausschließen. Diese müssen anschließend bewusst abgeglichen werden.

Die Sicherungskette zusammenstellen

Beginnen Sie mit einer vollständigen Sicherung, deren wiederhergestellter Endzustand vor dem Ziel liegt. Ergänzen Sie gegebenenfalls eine passende differenzielle Sicherung, die das Ziel ebenfalls nicht überschreitet. Danach folgen sämtliche erforderlichen Protokollsicherungen bis einschließlich des gesuchten Zeitpunktes. Entscheidend ist der Transaktionsabschluss: Eine vorher begonnene, aber erst nach dem Ziel bestätigte Transaktion gehört nicht zum bestätigten Ergebnis.

Prüfen Sie tatsächliche Sicherungsheader und Dateilisten. Dateinamen und Endzeiten allein beweisen keine Kontinuität. Erfassen Sie Satzpositionen, alle Teile verteilter Sicherungen, Schlüssel und logische Dateinamen für MOVE. Eine vollständige Sicherung nach dem Schaden lässt sich nicht durch STOPAT in einer späteren Protokollwiederherstellung zurückdrehen.

Die Vorlage setzt eine isolierte Zieldatenbank voraus, auf der die passende vollständige und gegebenenfalls differenzielle Sicherung mit NORECOVERY eingespielt wurde. Ersetzen Sie Pfade und führen Sie alle benötigten Protokolle in korrekter Reihenfolge aus. Der Zielzeitpunkt bleibt identisch.

RESTORE LOG [RecoveryPractice]
FROM DISK=N'D:\Restore\required_log_001.trn'
WITH NORECOVERY, STOPAT='2025-05-12T14:29:59';
-- Repeat for every required log, with the same STOPAT.
-- Only after confirming that the target was reached:
-- RESTORE DATABASE [RecoveryPractice] WITH RECOVERY;

Solange keine abschließende Wiederherstellung erfolgt, können fehlende Protokolle ergänzt werden. Prüfen Sie vor diesem Abschluss, ob die Kette den gewünschten Zeitpunkt tatsächlich erreicht. Liegt das Ziel nach dem letzten vorhandenen Protokoll, ist eine noch nicht geöffnete Datenbank weder ein Erfolgsnachweis noch automatisch ein Datenverlust. Suchen Sie die fehlenden Medien. Unter dem massenprotokollierten Wiederherstellungsmodell begrenzen minimal protokollierte Vorgänge die Auswahl innerhalb der betroffenen Protokollsicherung.

Die Freigabe fachlich begründen

Ist die ursprüngliche Datenbank noch erreichbar, prüfen Sie vor einem überschreibenden Vorgang, ob eine Sicherung des Protokollendes noch ungesicherte Transaktionen erhalten kann. Das Verfahren hängt vom Zustand und Wiederherstellungsziel ab. Verwenden Sie WITH REPLACE nicht als improvisierte Abkürzung.

Prüfen Sie nach dem Abschluss zunächst Integrität und dann Geschäftsregeln. Sind die betroffenen Rechnungen vorhanden? Fehlt die falsche Änderung? Sind bekannte frühere Abschlüsse enthalten und Summen stimmig? Erfassen Sie bewusst ausgeschlossene spätere Transaktionen für eine kontrollierte Nachbearbeitung. Der Status ONLINE beantwortet keine dieser Fragen.

Messen Sie Diagnose, Medienbeschaffung, Einspielen, Abnahme und Wiederanschluss getrennt. Fehlende Anwendungszugänge können trotz schneller Wiederherstellung das Zeitbudget sprengen. Speichern Sie die erprobte Medienfolge und konkrete Prüfqueries. Ein zweiter Operator sollte damit denselben Zielzustand nachvollziehbar erreichen können, ohne mündliches Vorwissen des ersten zu benötigen.

Technische Referenzen: Microsoft Learn: Point-in-time restore · Microsoft Learn: Tail-log backups.

Frage zu diesem Artikel

Haben Sie eine Frage zu diesem Thema?

Beschreiben Sie, was Sie bewerten oder wo Sie nicht weiterkommen. Wir antworten mit einer praktischen Empfehlung.

Inquiries are not enabled in this preview.

Eine Frage zu diesem Artikel stellen