Log Shipping: Wiederherstellbarkeit statt grüner Jobs prüfen

Log Shipping kann mit überschaubaren Komponenten eine brauchbare Wiederherstellungskopie bereitstellen. Die zentrale Betriebsfalle besteht darin, erfolgreiche Aufträge mit einem erfüllten Wiederherstellungsziel gleichzusetzen. Ein Kopierauftrag kann erfolgreich enden, obwohl die Quelle keine neuen Sicherungen erzeugt. Ein Restore-Auftrag kann funktionieren, während die neueste Datei noch auf einem anderen Server liegt. Entscheidend ist der Abstand des wiederherstellbaren Datenbestands zum Geschäftsgeschehen.

Eine Datei durch alle Stufen verfolgen

Verfolgen Sie eine konkrete Protokollsicherung von der Erstellung auf dem Primärserver über die Ankunft auf dem Sekundärserver bis zur Anwendung auf die Datenbank. Erfassen Sie Identität und Zeiten je Stufe. Sind Sicherungen aktuell, Kopien aber alt, prüfen Sie Freigabezugriff, Speicher und Kopierprozess. Treffen Dateien ein, während Restores zurückfallen, suchen Sie nach fehlenden Vorgängern, Fehlern, Leserzugriffen oder unzureichendem Durchsatz.

Die folgende lesende Prozedur liefert auf einem eingerichteten Überwachungsserver eine Zusammenfassung. Verwenden Sie die erforderlichen administrativen Berechtigungen. Bewerten Sie die Ergebnisse für Primär- und Sekundärseite gemeinsam und kontrollieren Sie die Aktualität der Überwachungsdaten selbst.

USE master;
EXEC sys.sp_help_log_shipping_monitor;

Ein alter Eintrag kann eine gestörte Meldestrecke bedeuten, statt einen alten Datenbestand. Prüfen Sie deshalb lokale Auftragshistorie und tatsächliche Dateien vor einem Eingriff. Umgekehrt darf dieser mögliche Fehler nicht zur pauschalen Entschuldigung jedes Alarms werden. Testen Sie die Zustellung einer Benachrichtigung und den zulässigen Altersgrenzwert, nicht nur das Vorhandensein einer Alarmdefinition.

Bei Sicherungen alle fünf Minuten sowie Kopien und Restores alle zwei Minuten wartet eine unmittelbar nach der Sicherung bestätigte Transaktion zunächst auf den nächsten Sicherungslauf. Danach können weitere Wartezyklen folgen. Die Zeitpläne garantieren somit keinen maximalen Datenverlust von fünf Minuten. Reale Ausführung, Rückstände und nach dem Ausfall noch erreichbare Dateien bestimmen das Ergebnis.

Verzögerung und Aufbewahrung abstimmen

Eine bewusst verzögerte Anwendung kann die Kopie für eine gewisse Zeit vor einem versehentlichen Löschen halten. Das hilft nur, wenn der Vorfall rechtzeitig erkannt wird. Unabhängig aufbewahrte Sicherungen bleiben notwendig: Die Entdeckung kann später erfolgen, und gemeinsame Speicher- oder Zugangsschäden können mehrere Kopien betreffen.

Unterscheiden Sie das Alter der zuletzt kopierten von der zuletzt eingespielten Sicherung. Ein Restore-Alarm berücksichtigt die geplante Verzögerung und eine begründete Toleranz. Die Kopierstufe muss trotzdem weiterlaufen. Eine allgemeine Ausnahme für verzögerte Systeme würde sonst echte Stillstände verdecken.

Die Aufbewahrungsdauer muss Verzögerung, plausible Ausfälle sowie Diagnose und Aufholen abdecken. Löscht eine Bereinigung einen noch benötigten Vorgänger, überbrückt eine spätere intakte Datei die Lücke nicht. Koordinieren Sie andere Sicherungsprodukte. Eine gewöhnliche Protokollsicherung durch ein fremdes Werkzeug kann eine notwendige Datei erzeugen, die der Versandprozess nicht kennt. Benennen Sie einen Verantwortlichen für die gesamte Folge.

Den Rollenwechsel vollständig erproben

Ein Rollenwechsel erfolgt kontrolliert und manuell. Verhindern Sie zuerst widersprüchliche Schreibzugriffe auf dem bisherigen Primärserver. Ist dieser erreichbar, prüfen Sie eine abschließende Protokollsicherung und übertragen sowie restaurieren Sie sämtliche benötigten verfügbaren Dateien. Ist er verloren, dokumentieren Sie den letzten erreichbaren Zustand und die Ungewissheit über spätere Transaktionen.

Führen Sie die endgültige Recovery nicht nur aus, um die Öffnung zu testen. Danach lässt sich die bisherige Restore-Folge nicht einfach fortsetzen. Der erneute Schutz benötigt einen geplanten Aufbau. Legen Sie fest, wann das Warten auf Dateien endet, wer möglichen Verlust akzeptiert und wie Clients umgeleitet werden.

STANDBY kann Lesezugriffe zwischen Restores ermöglichen. Leser können jedoch den Zeitplan behindern, wenn ihre Trennung nicht geregelt ist. Erproben Sie den gewählten Modus mit der unterstützten Versionskombination. Prüfen Sie nach dem Wechsel Anmeldungen, Aufträge, Verbindungen und externe Abhängigkeiten. Messen Sie bis zum ersten korrekten Geschäftsvorgang und speichern Sie Medienfolge sowie beobachtete Dauer als Nachweis.

Technische Referenzen: Microsoft Learn: Log shipping overview · Microsoft Learn: Monitor summary · Microsoft Learn: Manual failover.