Restore-Test: So prüfen Sie Ihr Backup

Was ist ein Restore-Test?

Ein Restore-Test ist die planmäßige Wiederherstellung von Daten, Anwendungen oder ganzen Systemen aus einer Sicherung mit dem Ziel, die Wiederherstellbarkeit zu überprüfen. Er beantwortet drei Fragen: Sind die gesicherten Daten vollständig und lesbar? Funktionieren die Anwendungen nach der Wiederherstellung? Und wie lange dauert der gesamte Vorgang einschließlich der beteiligten Personen und Schritte?

Der Begriff ist von der Überwachung der Backup-Jobs zu unterscheiden. Die Überwachung beobachtet, ob Sicherungen laufen. Der Restore-Test prüft, ob das Ergebnis dieser Sicherungen nutzbar ist. Beides ist nötig, aber nur der Restore-Test belegt, was im Ernstfall tatsächlich passiert.

Warum ein Backup-Protokoll nicht genügt

Ein Protokoll bestätigt, dass ein Job technisch beendet wurde. Es sagt nichts darüber aus, ob die Daten für Ihre Anwendungen brauchbar sind. Eine Datenbank etwa kann im laufenden Betrieb in einem inkonsistenten Zustand gesichert werden, wenn die Anwendung dafür nicht vorbereitet wurde. Das Protokoll meldet dennoch Erfolg, denn der Kopiervorgang ist fehlerfrei abgeschlossen.

Hinzu kommen Fehlerquellen, die erst beim Zurückspielen sichtbar werden: fehlende Abhängigkeiten, etwa ein nicht mitgesicherter Schlüssel oder ein Lizenzserver, veraltete Dokumentation, Zugangsdaten, die im Ernstfall nicht auffindbar sind, oder eine Zielhardware, auf der das gesicherte System nicht startet. Auch die Dauer lässt sich aus einem Protokoll nicht ableiten. Wer sein RTO-Ziel kennt, aber nie eine Wiederherstellung gemessen hat, kennt lediglich einen Wunsch, siehe RPO und RTO einfach erklärt.

Grundsätzlich gilt: Eine Sicherung ist erst dann geprüft, wenn eine Wiederherstellung daraus gelungen ist. Dieser Grundsatz ist in der Fachliteratur und in Rahmenwerken zur Notfallplanung etabliert, etwa im Leitfaden NIST SP 800-34, der das Testen von Wiederherstellungsverfahren als festen Bestandteil der Notfallplanung betrachtet.

Die Teststufen im Überblick

Tests lassen sich nach Aufwand und Aussagekraft in Stufen einordnen. Je höher die Stufe, desto näher kommt der Test dem Ernstfall, und desto mehr Zeit und Abstimmung erfordert er.

• Stufe 1, Job-Meldung: Der Backup-Job meldet Erfolg. Das ist die Grundlage, aber noch kein Test.
• Stufe 2, Integritätsprüfung: Die Sicherung wird automatisiert auf Lesbarkeit und Unversehrtheit geprüft. Das erkennt beschädigte Datenträger oder Übertragungsfehler, aber keine inhaltlichen Probleme.
• Stufe 3, Dateiwiederherstellung: Einzelne Dateien werden zurückgespielt und geöffnet. Das belegt, dass die Daten nutzbar sind und das Verfahren verstanden wird.
• Stufe 4, Anwendungswiederherstellung: Eine Anwendung samt Datenbank wird wiederhergestellt und fachlich geprüft, zum Beispiel durch einen Test mit bekannten Datensätzen.
• Stufe 5, Systemwiederherstellung: Ein vollständiges System wird auf Zielhardware oder in einer virtuellen Umgebung wiederhergestellt und gestartet.
• Stufe 6, isolierte Wiederherstellung: Die Wiederherstellung erfolgt in einer abgetrennten Umgebung, damit Test und Produktion sich nicht beeinflussen. Das ist insbesondere bei Verdacht auf Schadsoftware sinnvoll.
• Stufe 7, Disaster-Recovery-Übung: Das Szenario eines größeren Ausfalls wird durchgespielt, mit allen beteiligten Personen, Abhängigkeiten und der Kommunikation.

Was genau wird getestet?

Ein guter Test hat ein klar definiertes Ziel und ein überprüfbares Kriterium für Erfolg. Allgemeine Aussagen wie „die Wiederherstellung hat funktioniert“ sind für eine spätere Bewertung zu ungenau. Besser ist eine Festlegung vorab: Welches System, welcher Wiederherstellungspunkt, welches Zielsystem und woran erkennen wir, dass das Ergebnis brauchbar ist?

Prüfen Sie dabei nicht nur technische, sondern auch fachliche Kriterien. Ein wiederhergestellter Server, der startet, aber veraltete Daten enthält oder dessen Anwendung keine Verbindung zur Datenbank aufbaut, ist kein Testerfolg. Beziehen Sie deshalb die Fachabteilung ein, die die Anwendung kennt. Sie kann beurteilen, ob der Datenstand plausibel ist und ob zentrale Abläufe wieder funktionieren.

Dokumentieren Sie zudem, was nicht getestet wurde. Ein Protokoll, das offen benennt, dass etwa die Wiederherstellung der Telefonanlage nicht Teil der Übung war, ist wertvoller als eine pauschale Erfolgsmeldung.

Wie oft und in welcher Reihenfolge sollten Sie testen?

Auch hier gibt es keine einheitliche Vorgabe, die für alle Organisationen passt. Sinnvoll sind feste Rhythmen und zusätzliche, anlassbezogene Tests. Anlässe sind etwa der Austausch von Servern, größere Updates, die Einführung neuer Anwendungen, eine Änderung der Backup-Pläne oder Personalwechsel bei den Zuständigen.

Beginnen Sie mit den geschäftskritischen Systemen, also jenen, deren Ausfall den Betrieb am stärksten trifft. Für diese lohnen sich tiefere Stufen und kürzere Abstände. Weniger wichtige Systeme können mit einfachen Stufen und längeren Abständen geprüft werden. Eine Priorisierung, die sich an Ihren Zielen für Datenverlust und Ausfalldauer orientiert, hilft dabei, den Aufwand zu begrenzen. Wie Sie solche Ziele ableiten, zeigt Backup-Strategie für KMU.

Was ein Testprotokoll enthalten sollte

Ein Test, der nicht dokumentiert wird, ist für die Zukunft nahezu wertlos, denn niemand kann später nachvollziehen, was geprüft wurde und mit welchem Ergebnis. Zugleich muss ein Protokoll nicht umfangreich sein. Entscheidend ist, dass es die Fragen beantwortet, die im Ernstfall oder bei einer Überprüfung gestellt werden. Folgende Angaben haben sich bewährt:

• Datum, beteiligte Personen und getestetes System mit Version
• Verwendeter Wiederherstellungspunkt und Zielumgebung
• Gemessene Dauer, getrennt nach Einzelschritten, etwa Bereitstellung der Zielumgebung, Datenübertragung und fachlicher Prüfung
• Erfolgskriterien und Ergebnis der Prüfung, einschließlich festgestellter Abweichungen
• Offene Punkte mit Verantwortlichen und Terminen
• Ausdrücklich nicht getestete Bereiche

Gemessene Zeiten richtig lesen

Aus Tests lassen sich Erkenntnisse zur Wiederherstellungsdauer gewinnen, die kein Handbuch liefert. Wichtig ist, die Gesamtdauer in Bestandteile zu zerlegen. Dazu gehören die Zeit bis zur Entscheidung zur Wiederherstellung, die Bereitstellung von Hardware oder einer virtuellen Umgebung, die Übertragung der Daten über das vorhandene Netz, die technische Inbetriebnahme sowie die fachliche Prüfung. Oft zeigt sich, dass nicht die Datenübertragung, sondern organisatorische Schritte den größten Anteil haben, etwa die Suche nach Zugangsdaten oder die Abstimmung zwischen mehreren Beteiligten.

Beachten Sie außerdem, dass eine Messung im Test nicht ohne Weiteres auf den Ernstfall übertragbar ist. Im Test sind die Beteiligten vorbereitet und erreichbar, die Last auf Netz und Speicher ist gering, und die Aufgabe betrifft in der Regel ein einzelnes System. Im Ernstfall fallen unter Umständen mehrere Systeme gleichzeitig aus, und die Wiederherstellung konkurriert um dieselbe Bandbreite. Planen Sie deshalb einen Puffer ein und sprechen Sie intern nur von einem Zielwert, nicht von einer Zusage.

Worauf Sie bei der Testumgebung achten sollten

Ein Restore-Test erzeugt eine zweite Instanz eines Systems. Das birgt Risiken, die Sie vorab bedenken sollten. Ein wiederhergestellter Server kann dieselbe Netzwerkadresse und denselben Namen wie das Original besitzen und dadurch Konflikte im Produktivnetz auslösen. Anwendungen können nach dem Start automatisch E-Mails versenden, Aufträge verarbeiten oder auf produktive Schnittstellen zugreifen. Aus diesem Grund wird häufig in einer isolierten Umgebung ohne Verbindung zur Produktion getestet.

Zusätzlich enthalten Testsysteme dieselben Daten wie die Produktion, darunter personenbezogene und vertrauliche Informationen. Behandeln Sie die Testumgebung daher mit denselben Zugriffsbeschränkungen und räumen Sie sie nach dem Test auf. Ob und wie Testdaten verändert oder anonymisiert werden müssen, ist eine Frage, die Sie mit Ihrer Datenschutzberatung klären sollten.

Wer trägt welche Verantwortung beim Test?

Ein Restore-Test berührt mehrere Verantwortungsbereiche, die nicht immer in einer Hand liegen: die Bereitstellung der Backup-Infrastruktur, die Konfiguration der Jobs, die Durchführung der Wiederherstellung, die Prüfung der Anwendung und die fachliche Bewertung der Daten. Klären Sie vor dem ersten Test, wer welche Aufgabe übernimmt. Wenn ein externer Dienstleister die technische Wiederherstellung ausführt, bleibt die fachliche Prüfung üblicherweise bei Ihnen, weil nur Sie beurteilen können, ob ein Datenstand für Ihr Geschäft plausibel ist. Wo Verantwortung ungeklärt ist, sollten Sie das als offenen Punkt festhalten und nicht stillschweigend unterstellen.

Typische Fehlannahmen

Rund um das Thema halten sich einige Annahmen, die im Ernstfall teuer werden können.

• „Der Job war grün, also ist alles in Ordnung.“ Ein erfolgreicher Job beweist nicht, dass sich ein System funktionsfähig wiederherstellen lässt.
• „Wir haben schon einmal eine Datei zurückgeholt.“ Das belegt die Dateiwiederherstellung, nicht aber den Neuaufbau eines Servers.
• „Der Test belastet den Betrieb.“ Mit isolierter Zielumgebung oder einem Test-Failover lässt sich die Produktion unberührt lassen.
• „Dafür haben wir keine Zeit.“ Die Zeit, die ein Test kostet, ist im Vergleich zu einem ungeprüften Ernstfall meist gering.
• „Das macht ja der Dienstleister.“ Wer testet und wer das Ergebnis fachlich bewertet, muss vorab geklärt sein.

Ablauf eines Tests in der Praxis

Ein Test lässt sich in überschaubare Schritte gliedern, die für jedes System wiederkehren:

• Ziel, Umfang, Wiederherstellungspunkt und Erfolgskriterien festlegen, möglichst schriftlich.
• Zielumgebung vorbereiten, bevorzugt isoliert von der Produktion.
• Wiederherstellung starten und die Zeit dokumentieren, von der Auslösung bis zur nutzbaren Anwendung.
• Funktion und Daten fachlich prüfen, zum Beispiel mit bekannten Testfällen oder Stichproben.
• Abweichungen erfassen, Ursachen klären und Maßnahmen mit Zuständigen und Fristen festhalten.
• Gemessene Dauer mit dem RTO-Ziel vergleichen und das Konzept bei Bedarf anpassen.
• Testumgebung zurückbauen und das Ergebnis ablegen.

Besonderheiten bei Cloud-Diensten und Ransomware-Szenarien

Bei Cloud-Diensten wie Microsoft 365 gelten ähnliche Grundsätze, die Tests sehen aber anders aus. Hier prüfen Sie typischerweise die Wiederherstellung einzelner Objekte, etwa einer E-Mail, eines Ordners oder einer Datei aus SharePoint, und ob der Bezug zum ursprünglichen Ort stimmt. Details dazu finden Sie unter Braucht Microsoft 365 ein Backup?.

Nach einem Cyberangriff genügt es nicht, irgendeinen Stand zurückzuspielen. Ein Test dieses Szenarios sollte klären, welcher Wiederherstellungspunkt als sauber gilt, wie er geprüft wird und in welcher Umgebung zunächst wiederhergestellt wird. Auch das Austauschen kompromittierter Zugangsdaten gehört dazu. Wie ein solches Vorgehen aussehen kann, beschreibt der Artikel Nach Ransomware: Daten sauber wiederherstellen.

Umsetzung mit der Plattform

Mit der Plattform können Sie Wiederherstellungen selbst testen. Sicherungen lassen sich im Voraus validieren, und Backups können vor der Wiederherstellung auf Schadsoftware geprüft werden. Virtuelle Maschinen lassen sich unter Umständen direkt aus dem Backup starten, während die vollständige Wiederherstellung noch läuft. Bei Disaster Recovery steht zusätzlich ein Test-Failover in einer isolierten Umgebung zur Verfügung, mit dem Sie Wiederherstellungen ohne Störung der Produktion üben können, einmalig oder regelmäßig. Mehr dazu unter Cloud-Failover und Failback.

Die Entscheidung, was getestet wird, die fachliche Bewertung der Ergebnisse und die Dokumentation liegen bei Ihnen. Wenn Sie bei Planung oder Durchführung Unterstützung möchten, bieten wir sie gegen Vergütung an. Im Standard gilt eine Reaktionszeit von 4 Stunden an Werktagen (Montag bis Freitag).