Disaster Recovery Test — wie man es wirklich tut

Backups, die nie wiederhergestellt wurden, sind keine. Die drei Test-Stufen, was wirklich gemessen wird — und warum das echte RTO fast immer länger ist.

Jedes Bürogebäude hat eine Brandschutzordnung, einen Fluchtplan und Feuerlöscher an der Wand. Und trotzdem macht jeder Betrieb regelmäßig eine Feuerwehrübung — nicht, weil der Plan an der Wand falsch wäre, sondern weil sich erst in der Übung zeigt, ob er funktioniert: ob die Fluchttür wirklich aufgeht, ob alle den Sammelplatz finden, ob es nicht doch fünf Minuten länger dauert als gedacht. Genau so verhält es sich mit Disaster Recovery. Ein Backup-Konzept an der Wand ist gut. Aber erst die Übung — der DR-Test — beweist, dass im Ernstfall tatsächlich eine funktionierende Datenbank zurückkommt, und zwar schnell genug. Alles andere ist ein Fluchtplan, den nie jemand gegangen ist.

Mit diesem Beitrag schließt sich der Kreis des SQL-Server-Notarztwagens (die Triage-Übersicht liegt unter /sql-server-notarztwagen/). Er ist der letzte der fünfundzwanzig — und nicht zufällig der über das Üben des Ernstfalls, denn er bündelt, worauf die ganze GRÜN-Stufe hinausläuft: Vorsorge, die im Ruhezustand stattfindet, damit der Notfall gar nicht erst zum Drama wird. Hier erfährst du, wie ein DR-Test wirklich aussieht — die drei Test-Stufen, was dabei gemessen wird, wie man es dokumentiert und warum das echte RTO fast immer länger ist als das geplante. Es ist die praktische Fortsetzung der Backup-Strategie: Dort wird der Plan gemacht, hier wird er bewiesen.

Warum ein Backup kein DR-Konzept ist

Es ist die unbequemste Wahrheit der ganzen Reihe, und sie verdient es, am Ende noch einmal klar gesagt zu werden: Ein Backup, das nie wiederhergestellt wurde, ist kein Backup — es ist eine Hoffnung. Ein grüner Backup-Job in der Historie beweist ausschließlich, dass Daten geschrieben wurden. Ob aus diesen Daten im Ernstfall wieder eine laufende Datenbank wird, ob die Wiederherstellung schnell genug gelingt, ob jemand überhaupt weiß, wie sie geht — das alles beweist allein der Test. Und genau dieser Schritt wird am häufigsten übersprungen, weil er Aufwand macht und „bisher ja immer alles gut ging“.

Der Unterschied zwischen einem Backup und einer Disaster-Recovery-Fähigkeit ist derselbe wie zwischen einem Feuerlöscher an der Wand und einem Team, das ihn bedienen kann. Das Backup ist nur ein Baustein. Eine echte DR-Fähigkeit umfasst weit mehr: einen dokumentierten Ablauf, der auch unter Stress und von wechselnden Personen befolgt werden kann; die Gewissheit, dass alle Abhängigkeiten am Zielort vorhanden sind; geprobte Zugänge und Berechtigungen; und vor allem die belegte Gewissheit, dass das Ganze innerhalb der vereinbarten Zeit gelingt. Diese Fähigkeit entsteht nicht durch ein gutes Backup-Skript — sie entsteht durch Üben.

Der DR-Test ist diese Übung. Sein Ziel ist nicht, „zu beweisen, dass alles funktioniert“ — sein eigentlicher Wert liegt darin, die Lücken zu finden, solange es ungefährlich ist: den Schritt, der im Plan fehlt; den Zugang, den nur einer kennt; die Anwendung, die dem Failover nicht folgt; die fünf Minuten, die in Wahrheit fünfzig sind. Jede Lücke, die ein Test im Ruhezustand aufdeckt, ist eine Lücke, die nicht im brennenden Ernstfall überrascht. Ein DR-Test, der reibungslos durchläuft und nichts findet, ist deshalb nicht der ideale Test — der ideale Test ist der, der eine Schwachstelle ans Licht bringt, die du danach in Ruhe schließt.

Die drei Test-Stufen und die Mess-Punkte

Ein DR-Test gibt es nicht in einer einzigen Größe — er staffelt sich nach Tiefe, von der häufigen, automatisierten Minimal-Prüfung bis zur großen Voll-Probe. Die folgende Skizze zeigt die drei Stufen, was dabei gemessen wird und wie oft jede ansteht:

Die Skripte: restaurieren, prüfen, messen

Schritt 1 — Der automatisierte Restore-Test

Die unterste Stufe lässt sich automatisieren und sollte häufig laufen: Backup auf einen separaten Server zurückspielen, Konsistenz prüfen, wieder wegräumen. So sieht der Kern aus:

Dieser Ablauf erschlägt zwei Pflichten in einem Vorgang: Er testet das Backup (kommt es überhaupt zurück?) und prüft die Konsistenz (sind die Daten in Ordnung?). Als geplanter Job läuft er ohne menschliches Zutun und meldet nur bei Fehlern — die ideale Grundausstattung jeder DR-Strategie.

Schritt 2 — Point-in-Time und die Zeitmessung

Für die ernsthafte Probe gehört der Weg über die Log-Kette dazu — die Wiederherstellung auf einen bestimmten Zeitpunkt, wie sie der echte Notfall verlangt. Und dabei wird gemessen:

Das STOPAT stellt exakt auf den gewünschten Zeitpunkt wieder her — die Probe für jeden Fall, in dem nicht der letzte Stand, sondern der Moment vor einem Schaden gefragt ist (etwa vor einem versehentlichen Massenlöschen). Entscheidend ist die Zeitmessung drumherum: Erst sie verwandelt das RTO von einer Vorgabe in eine gemessene Zahl.

Schritt 3 — Backup-Kette auf Lückenlosigkeit prüfen

Realistisch testen, ehrlich messen, sauber dokumentieren

Realistisch heißt: keine Abkürzungen

Ein DR-Test ist nur so viel wert wie seine Realitätsnähe. Der häufigste Selbstbetrug ist die stille Abkürzung: Der testende DBA nutzt seinen persönlichen Zugang, weiß die Pfade auswendig, hat das richtige Backup schon zur Hand — und übersieht, dass im echten Notfall vielleicht keine dieser Voraussetzungen gegeben ist. Ein ehrlicher Test simuliert deshalb auch die ungemütlichen Umstände: Funktioniert die Wiederherstellung mit den Zugängen, die im Notfall verfügbar sind? Findet jemand das richtige Backup ohne Vorwissen? Geht es auch, wenn nicht der gewohnte Experte am Werk ist, sondern jemand, der nur dem Runbook folgt? Jede Abkürzung im Test ist eine Lücke, die im Ernstfall zuschlägt.

Ehrlich messen: das echte RTO ist fast immer länger

Die wertvollste Zahl eines DR-Tests ist das gemessene RTO — und fast immer ist es eine unbequeme Überraschung. Auf dem Papier steht „zwei Stunden“, in der Übung werden daraus vier, weil im Plan die unsichtbaren Schritte fehlten: Der Zugang musste erst gesucht, die Reihenfolge der Datenbanken erst geklärt, die Anwendung erst auf den neuen Server umkonfiguriert werden. Das ist keine Schande, sondern genau der Sinn der Übung: die Diskrepanz zwischen geplantem und echtem RTO im Ruhezustand zu finden, wo sie nur ein Lerneffekt ist, und nicht im Ernstfall, wo sie ein Geschäftsschaden wird. Wer sein echtes RTO kennt, kann es entweder verbessern oder die Erwartung beim Geschäft ehrlich korrigieren — beides ist besser als die Illusion einer Papierzahl. Die Grundlagen von RTO und RPO stehen im Backup-Strategie-Beitrag.

Dokumentieren: das Runbook für den Ernstfall

Das Ergebnis jedes DR-Tests gehört in ein Runbook — eine Schritt-für-Schritt-Anleitung, die so geschrieben ist, dass sie auch ein Fremder ausführen kann. Diese Anforderung ist kein Formalismus: Im echten Notfall ist der gewohnte DBA vielleicht im Urlaub, krank oder schlicht nicht erreichbar, und dann entscheidet die Qualität des Runbooks über Stunden. Es enthält jeden Schritt des Ablaufs, die nötigen Zugänge und Berechtigungen, die Reihenfolge und Zuständigkeiten, und die beim letzten Test gemessenen Zeiten samt gefundener Lücken. Nach jedem Test wird es aktualisiert — was hakte, wird ergänzt, was sich änderte, wird korrigiert. So wächst aus den Übungen ein erprobtes, verlässliches Dokument, und genau dieses Dokument, nicht das einzelne Backup, ist die DR-Fähigkeit eines Unternehmens in greifbarer Form.

Was du auf keinen Fall tun solltest

DR-Tests in der Routine — und ein Schlusswort zum Notarztwagen

Der DR-Test wird vom Großprojekt zur beherrschbaren Routine, wenn er gestaffelt und automatisiert wird: der Restore-Test als wöchentlicher, automatisierter Job; der Failover-Test als quartalsweiser Termin im Kalender; die Voll-Probe als jährliche Übung mit Team und Stoppuhr, ergänzt um einen außerplanmäßigen Test nach jedem großen Umbau. Und über allem das Runbook, das nach jeder Übung wächst. Damit ist der Kreis geschlossen: Vom akuten Server-Stillstand der ROT-Stufe über die dringenden Probleme der GELB-Stufe bis zur proaktiven Wartung der GRÜN-Stufe führt der Notarztwagen genau hierher — zu der Erkenntnis, dass die beste Notfallmedizin die ist, die den Notfall durch Vorsorge entschärft, bevor er eintritt. Wer regelmäßig den Ernstfall probt, hat ihn schon halb gewonnen.

Vertiefung in der Buchreihe

Disaster-Recovery-Strategien, Restore-Mechanik und HV-Konzepte füllen in der Buchreihe „SQL Server in der Praxis“ einen ganzen Band — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Beiträge im Notarztwagen

Der DR-Test ist der Schlussstein vieler Themen — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zum erprobten Ernstfall

Selbst-Diagnose-Kit

Einen DR-Test selbst aufzusetzen ist die wertvollste Vorsorge überhaupt — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — automatisierter Restore-Test mit CHECKDB, Point-in-Time-Wiederherstellung mit Zeitmessung, Backup-Ketten-Prüfung — plus eine Runbook-Vorlage zum Ausfüllen, die Drei-Stufen-Teststaffelung zum Ausdrucken und ein RTO/RPO-Messprotokoll. Damit verwandelst du das Bauchgefühl „die Backups werden schon passen“ in eine bewiesene, dokumentierte DR-Fähigkeit.

Festpreis-Analyse

Du willst die ehrliche Antwort auf die Frage, ob dein Unternehmen einen Ernstfall wirklich übersteht — mit gemessenem RTO und einem erprobten Runbook? Die Festpreis-Analyse liefert sie: Ich führe einen vollständigen DR-Test durch, spiele die Wiederherstellung tatsächlich durch, messe das echte RTO und RPO, decke die Lücken zwischen Plan und Realität auf und liefere ein einsatzfähiges Runbook samt Bericht mit priorisierten Verbesserungen. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn der Ernstfall gerade jetzt eingetreten ist und die Wiederherstellung läuft — oder anstehen muss: anrufen. Halte bereit, welche Backups vorliegen, in welchem Recovery-Model die Datenbanken laufen und ob ein Runbook existiert. In diesem Moment zählt jeder richtige Schritt in der richtigen Reihenfolge, und genau dafür ist die Hotline da — auch dann, wenn vorher nie geübt wurde.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Wie oft sollte ich einen DR-Test machen?

Gestaffelt nach Test-Tiefe: Der einfache Restore-Test (Backup zurückspielen und prüfen) sollte automatisiert und häufig laufen, idealerweise wöchentlich. Der Failover-Test einer Always-On-Konstellation gehört regelmäßig geprobt, etwa quartalsweise. Die große Voll-Probe — der komplette Ernstfall-Ablauf mit Team, Dokumentation und Zeitmessung — sollte mindestens jährlich stattfinden, und zusätzlich immer nach größeren Infrastruktur-Änderungen, denn genau die brechen oft unbemerkt einen vorher funktionierenden Wiederherstellungsweg. Der schlechteste Zeitpunkt, festzustellen, dass der DR-Plan nicht mehr passt, ist der echte Notfall. Regelmäßiges Testen verschiebt diese Erkenntnis in den ungefährlichen Ruhezustand.

Was muss ein DR-Test umfassen?

Mehr als nur das Zurückspielen eines Backups. Ein vollständiger DR-Test prüft die ganze Kette: ob das Backup brauchbar ist (Restore plus Konsistenzprüfung), ob bei Always-On der Failover sauber greift und die Anwendung mitfolgt, ob alle Abhängigkeiten (Logins, Jobs, Linked Server) am Zielort vorhanden sind, und vor allem, ob der ganze Vorgang innerhalb der vereinbarten Zeit- und Datenverlust-Vorgaben gelingt. Der wichtigste, oft übersehene Teil ist die Messung: Wie lange dauerte es wirklich, und wie viele Daten waren am Ende verloren? Ein Test, der nur „hat funktioniert“ feststellt, aber keine Zahlen liefert, verschenkt seinen eigentlichen Wert.

Was ist der Unterschied zwischen RESTORE VERIFYONLY und einem echten Restore?

RESTORE VERIFYONLY prüft nur, ob die Backup-Datei lesbar und in sich konsistent ist — es liest die Datei und kontrolliert ihre Struktur, stellt aber nichts wieder her. Das fängt eine beschädigte oder unvollständige Backup-Datei ab, beweist aber nicht, dass daraus eine funktionierende Datenbank wird. Ein echter Restore spielt das Backup tatsächlich zurück, sodass am Ende eine laufende, abfragbare Datenbank steht. Nur dieser bewiesene Weg zurück ist eine echte Verifikation. VERIFYONLY ist die schnelle Minimal-Prüfung für zwischendurch, der echte Test-Restore ist der Beweis — und im DR-Test zählt nur der Beweis, nicht die Hoffnung.

Wie dokumentiere ich einen DR-Test?

In einem Runbook — einer Schritt-für-Schritt-Anleitung, die so geschrieben ist, dass sie auch jemand ausführen kann, der nicht der gewohnte DBA ist. Das ist wichtig, weil im echten Notfall vielleicht genau diese Person nicht erreichbar ist. Das Runbook enthält jeden Schritt des Wiederherstellungsablaufs, die nötigen Zugänge und Berechtigungen, wer was tut, und die beim Test gemessenen Zeiten samt gefundener Lücken. Nach jedem Test wird es aktualisiert: Was hakte, was fehlte, was dauerte länger als gedacht. So wächst aus den Tests ein verlässliches, erprobtes Dokument — und genau das, nicht das einzelne erfolgreiche Backup, ist die eigentliche DR-Fähigkeit eines Unternehmens.

Was sind die typischen DR-Test-Fehler?

Die häufigsten: Erstens, gar nicht testen und sich auf grüne Backup-Jobs verlassen — ein Backup-Job beweist nur das Schreiben, nicht die Wiederherstellbarkeit. Zweitens, nur den Restore testen, aber nicht die Zeit messen — dann kennt man das echte RTO nicht. Drittens, im Test Abkürzungen nehmen, die im Ernstfall nicht verfügbar wären (etwa Zugänge, die nur der testende DBA hat). Viertens, nach Infrastruktur-Änderungen nicht erneut testen, sodass ein vorher funktionierender Weg unbemerkt bricht. Fünftens, die Erkenntnisse nicht zu dokumentieren, sodass dieselben Lücken bei jedem Test neu entdeckt werden. Der rote Faden: Ein DR-Test ist nur dann etwas wert, wenn er realistisch, gemessen und dokumentiert ist.

Wie teste ich einen Always-On-Failover?

Mit einem geplanten, manuellen Failover im Wartungsfenster — nicht durch das Abschießen eines Servers, sondern kontrolliert. Du schwenkst die Verfügbarkeitsgruppe auf einen Secondary, der damit zum neuen Primary wird, und prüfst dann das Entscheidende: Folgt die Anwendung dem Failover automatisch (über den Listener), oder hängt sie an der alten Adresse fest? Laufen alle Jobs auf dem neuen Primary? Stimmt die Performance? Der Failover selbst ist oft der einfache Teil — die Tücken stecken in den Dingen drumherum, die nur auf dem ursprünglichen Primary konfiguriert waren. Anschließend schwenkst du kontrolliert zurück. Die Mechanik der Synchronisierung steht im Always-On-Beitrag.

Welche RTO/RPO-Werte sollte ich messen?

Genau die beiden, die das Geschäft als Vorgabe gesetzt hat — der DR-Test prüft, ob die Realität sie einhält. Das tatsächliche RTO misst du als Zeit vom simulierten Schaden bis zur wieder voll nutzbaren Datenbank: Stoppuhr an beim Start, aus, wenn die Anwendung wieder läuft. Das tatsächliche RPO misst du als Menge der am Ende verlorenen Daten — abhängig davon, bis zu welchem Zeitpunkt die Wiederherstellung reichte. Fast immer ist das gemessene RTO länger als das geplante, weil im Plan die unsichtbaren Schritte fehlen (Zugänge suchen, Reihenfolge klären, Anwendung umkonfigurieren). Genau diese Lücke aufzudecken ist der Sinn der Messung — sie macht aus einer Papierzahl eine belegte.