So messen Sie, wie lange Ihr Wiederanlauf wirklich gedauert hat

Ihr Backup-Dashboard ist grün, seit Monaten. Das beweist, dass Daten weggeschrieben wurden. Es beweist nicht, dass sie zurückkommen, und schon gar nicht, wie lange das dauert. Wie Sie diese Zahl mit vorhandenen Mitteln messen und was Sie dabei fast sicher überrascht, zeigt dieser Beitrag.

Die Zahl, die niemand kennt

In fast jedem Notfallkonzept steht eine Wiederanlaufzeit. In sehr wenigen Organisationen ist sie gemessen. Sie stammt meist aus einer Herstellerangabe, aus einer groben Schätzung oder schlicht aus dem Wert, der beim Schreiben des Konzepts plausibel klang.

Der Unterschied zwischen geschätzt und gemessen liegt in der Praxis regelmäßig beim Faktor drei bis fünf. Nicht weil das Zurückspielen so lange dauert, sondern weil zwischen der Entscheidung und der ersten arbeitsfähigen Anwendung Dinge liegen, die in keinem Konzept stehen. Jemand sucht das Kennwort für die Wiederherstellungskonsole. Die Lizenzaktivierung braucht Internet, das gerade abgeschaltet wurde. Niemand weiß, in welcher Reihenfolge die Systeme hochkommen müssen.

Am Ende dieses Beitrags haben Sie eine gemessene Wiederanlaufzeit für mindestens ein Fachverfahren, eine erprobte Startreihenfolge und ein Protokoll, das Sie der Geschäftsführung, dem Wirtschaftsprüfer und der Cyberversicherung vorlegen können. Sie brauchen dafür kein Testrechenzentrum und kein zusätzliches Budget.

Schritt 1: Die richtige Testtiefe wählen

Es gibt vier Stufen: Auf Stufe eins stellen Sie eine einzelne Datei wieder her. Auf Stufe zwei stellen Sie ein vollständiges System in eine isolierte Umgebung zurück. Auf Stufe drei bringen Sie eine ganze Prozesskette zum Laufen, also Verzeichnisdienst, Datenbank, Anwendung und Zugang. Auf Stufe vier proben Sie den vollständigen Wiederanlauf am Ausweichstandort.

Beginnen Sie mit Stufe zwei und planen Sie Stufe drei für den zweiten Durchgang. Stufe eins beweist nichts, das macht Ihr Helpdesk ohnehin jede Woche. Stufe vier überfordert eine Erstübung und liefert am Ende nur die Erkenntnis, dass es nicht funktioniert hat, ohne zu zeigen, woran es lag.

Schritt 2: Die isolierte Umgebung ohne Budget aufbauen

Der Test muss vollständig getrennt vom Produktivnetz laufen. Ein eigenes VLAN ohne Route nach außen, kein Zugriff auf den produktiven Verzeichnisdienst, keine gemeinsame Namensauflösung. Diese Regel ist nicht verhandelbar, denn ein zurückgespielter Domaincontroller, der Kontakt zum Produktivnetz bekommt, richtet mit einem USN-Rollback mehr Schaden an als der Vorfall, den Sie üben wollen.

Als Unterbau genügt ausgemusterte Hardware aus dem letzten Austauschzyklus. Wer keine hat, nimmt eine Workstation mit ausreichend Arbeitsspeicher. An Virtualisierung reicht Hyper-V, wenn Sie ohnehin im Microsoft-Umfeld arbeiten. Wollen Sie unabhängig davon bleiben oder haben Sie keine passende Lizenz zur Hand, ist Proxmox VE die naheliegende Alternative. Es ist quelloffen, ohne Lizenzkosten nutzbar und bringt mit dem Proxmox Backup Server gleich eine Sicherungslösung mit, die Wiederherstellungen nachprüfbar verifiziert. Für einen reinen Testaufbau ist auch VirtualBox brauchbar, wenn es schnell gehen muss.

Wer gar keine Hardware freimachen kann, mietet für zwei Tage eine virtuelle Maschine bei einem deutschen Hoster. Das kostet weniger als ein Beratungstag und liefert denselben Erkenntnisgewinn. Achten Sie dann darauf, dass Sie keine echten personenbezogenen Daten in die Testumgebung spielen, oder klären Sie die Auftragsverarbeitung vorher.

Schritt 3: Die Startreihenfolge festlegen, bevor Sie beginnen

Die meisten gescheiterten Übungen scheitern hier. Schreiben Sie die Reihenfolge vorher auf und arbeiten Sie sie stur ab. Bewährt hat sich diese Kette:

1. Virtualisierungshost und Speicher
2. Netz, also Adressvergabe und Namensauflösung
3. Zeitquelle, mindestens ein verlässlicher Zeitgeber in der Testumgebung
4. Verzeichnisdienst mit mindestens einem Domaincontroller
5. Zertifikatsdienste, sofern Anmeldung oder Anwendungen darauf aufsetzen
6. Datenbankserver
7. Anwendungsserver des Fachverfahrens
8. Dateidienste
9. Clientzugang, also Terminalserver oder virtueller Arbeitsplatz

Die Zeitquelle wird fast immer vergessen und kostet dann Stunden. Kerberos toleriert standardmäßig fünf Minuten Abweichung. Liegt die zurückgespielte Maschine daneben, scheitert jede Anmeldung mit einer Meldung, die auf ein Kennwortproblem hindeutet. Man sucht am falschen Ende, während die Uhr läuft. Prüfen Sie deshalb direkt nach dem Start des Domaincontrollers.

w32tm /query /status
w32tm /query /configuration
w32tm /resync /force
dcdiag /v
repadmin /showrepl

Schritt 4: Die Rücksicherung anstoßen und dabei sauber protokollieren

Bevor Sie zurückspielen, prüfen Sie, was überhaupt zur Verfügung steht. Mit Bordmitteln unter Windows Server gehen Sie so vor:

wbadmin get versions -backupTarget:E:
wbadmin start recovery -version:08/24/2026-22:00 -itemType:Volume -items:D: -recoveryTarget:E: -quiet
vssadmin list shadows

Arbeiten Sie mit Veeam, was im Mittelstand verbreitet ist, listen Sie die verfügbaren Wiederherstellungspunkte über die PowerShell auf.

Get-VBRRestorePoint -Name "SRV-FIBU01" |
  Sort-Object CreationTime -Descending |
  Select-Object -First 5 Name, CreationTime, Type

Für Datenbanken gilt eine eigene Regel. Prüfen Sie die Sicherungsdatei, bevor Sie mit dem Zurückspielen Zeit verbrennen. Im SQL Server erledigen das zwei Anweisungen, die keine Daten anfassen:

RESTORE HEADERONLY FROM DISK = 'E:\Backup\fibu.bak';
RESTORE VERIFYONLY FROM DISK = 'E:\Backup\fibu.bak';
sqlcmd -S SRV-SQL01 -Q "SELECT name, state_desc, recovery_model_desc FROM sys.databases;"

Wer nicht im Microsoft-Umfeld sichert oder eine Alternative sucht, findet in der quelloffenen Welt gleichwertige Werkzeuge mit ausdrücklichen Prüffunktionen: Restic prüft die Sicherung inklusive Stichprobe der Nutzdaten, Borg prüft das gesamte Archiv, der Proxmox Backup Server verifiziert automatisiert. Bareos deckt größere Umgebungen ab und ist der klassische Ersatz für kommerzielle Sicherungssoftware.

restic -r /srv/backup check --read-data-subset=10%
restic -r /srv/backup restore latest --target /restore

borg check --verify-data /srv/borgrepo
borg extract --dry-run --list /srv/borgrepo::fibu-2026-08-24

proxmox-backup-client list
proxmox-backup-client restore vm/103/2026-08-24T22:00:00Z drive-scsi0.img /restore/disk.img

Für die Zeitmessung reicht ein kleines Protokollskript. Legen Sie es vor dem Test auf jedes beteiligte System und rufen Sie es an jedem Meilenstein auf. Ein Zettel funktioniert auch, geht aber im Eifer verloren.

$log = "C:\Restoretest\protokoll.csv"
if (-not (Test-Path $log)) { "Zeitpunkt;System;Ereignis" | Out-File $log -Encoding utf8 }

function Log-Schritt($System, $Ereignis) {
    "{0};{1};{2}" -f (Get-Date -Format o), $System, $Ereignis |
        Add-Content $log -Encoding utf8
}

Log-Schritt "SRV-DC01" "T1 Ruecksicherung gestartet"
Log-Schritt "SRV-DC01" "T2 System technisch verfuegbar"

Schritt 5: Die richtigen 4 Zeitpunkte erfassen

Hier entscheidet sich, ob Ihre Zahl belastbar ist oder eine Laborzahl bleibt. Erfassen Sie je System vier Zeitstempel.

T0 ist der Moment der Entscheidung, also der Punkt, an dem jemand sagt, wir stellen wieder her. In der echten Lage liegen zwischen T0 und dem ersten Befehl oft Stunden, weil analysiert, eskaliert und abgestimmt wird. Diese Zeit gehört zur Wiederanlaufzeit, auch wenn sie unbequem ist.

T1 ist der Beginn der Rücksicherung. T2 ist der Zeitpunkt, an dem das System technisch verfügbar ist, also Dienste laufen und die Anmeldung funktioniert. T3 ist die fachliche Freigabe durch die Fachabteilung.

Für Ihr RTO zählt allein T3. Ein System, das läuft, aber von der Fachabteilung nicht als arbeitsfähig bestätigt wurde, ist nicht wiederangelaufen. Deshalb muss jemand aus dem Fachbereich beim Test dabei sein. Definieren Sie vorher drei bis fünf Prüfhandlungen, etwa einen Datensatz suchen, einen Eintrag anlegen und speichern, eine Auswertung starten, einen Beleg drucken. Erst wenn alle durchlaufen, setzen Sie T3.

Schritt 6: Auswerten und die BIA korrigieren

Stellen Sie die gemessene Zeit von T0 bis T3 der Zielvorgabe aus Ihrer Business-Impact-Analyse gegenüber. Liegt die Messung darüber, wandert die Differenz in die Lückenliste, mit beiden Zahlen und einer Ursache. Liegt sie darunter, haben Sie einen belegten Wert, den Ihnen im nächsten Audit niemand mehr streitig macht.

Drei Zeitfresser tauchen in nahezu jeder ersten Übung auf. Die Startreihenfolge war nicht dokumentiert und wurde im Test erst entwickelt. Die Zugangsdaten für die Wiederherstellung lagen ausschließlich im Kennwortmanager, der selbst zu den ausgefallenen Systemen gehört. Und die Lizenzaktivierung einer Anwendung verlangte einen Internetzugang, den es im Notbetrieb nicht gab. Alle drei kosten nichts in der Behebung und viele Stunden im Ernstfall.

Halten Sie das Ergebnis in einem Notfallhandbuch fest, das offline verfügbar ist. Ausgedruckt im Serverschrank und zusätzlich verschlüsselt auf einem Datenträger, den zwei Personen unabhängig voneinander öffnen können. Ein Notfallplan im Intranet ist im Notfall genau dort, wo Sie nicht hinkommen.

Ergebnis und Kontrolle, woran Sie erkennen, dass der Test gültig war

1. Sie haben eine T0-bis-T3-Zeit für mindestens ein Fachverfahren, angegeben in Stunden und Minuten.
2. Die Rücksicherung erfolgte aus einer Kopie, die offline oder unveränderlich abgelegt ist, nicht aus einem produktiven Momentabbild.
3. Kein Testsystem hatte zu irgendeinem Zeitpunkt eine Route ins Produktivnetz. Der Nachweis steht im Protokoll.
4. Die Fachabteilung hat die Freigabe schriftlich bestätigt anhand der vorher festgelegten Prüfhandlungen.
5. Jede Wartezeit über fünfzehn Minuten ist mit Grund vermerkt.
6. Die gemessene Zeit ist in der BIA nachgetragen, entweder als Bestätigung oder als Eintrag in der Lückenliste.
7. Der nächste Test ist terminiert, mit einem anderen System und einer anderen Person an der Tastatur.

Der letzte Punkt ist der wichtigste. Ein Test, den immer dieselbe Person durchführt, misst nicht die Organisation, sondern diese Person. Genau die ist im Ernstfall erfahrungsgemäß im Urlaub.

Die Arbeitshilfe zu diesem Beitrag

Die Protokollvorlage Restore-Test liegt als makrofreie Excel-Datei im Downloadbereich dieser Ausgabe. Sie enthält je System die vier Zeitstempel, die Startreihenfolge als abhakbare Liste, ein Blatt für Wartezeiten mit Ursache und eine automatische Gegenüberstellung von gemessener Zeit und Zielvorgabe.

Wo Sie weiterlesen

Die Zielvorgabe, gegen die Sie hier messen, stammt aus der Business-Impact-Analyse. Wie Sie zu belastbaren Werten kommen, steht im Beitrag „In 6 Schritten zur belastbaren Business-Impact-Analyse“ in dieser Ausgabe.

Wie gut Sie auf den häufigsten Auslöser eines Wiederanlaufs vorbereitet sind, prüfen Sie mit dem Ransomware-Selbstcheck aus Ausgabe 17.

Läuft Ihre Wiederherstellung über einen Dienstleister, entscheidet dessen Vertrag über Ihre Zeit. Darum geht es in Ausgabe 21 im Beitrag „Dienstleisterzugänge technisch kontrollieren“.

Zum Nachschlagen der genannten Befehle und Verfahren dienen Microsoft Learn zu wbadmin und zur Gesamtwiederherstellung von Active Directory, die Veeam-Dokumentation zur PowerShell, die Handbücher von Proxmox Backup Server, restic und Borg sowie der BSI-Standard 200-4 zum Kapitel „Übungen und Tests“.