Ein Restore-Test prüft, ob sich eine Sicherung wirklich zurückspielen lässt – nicht nur, ob die Backup-Datei existiert. Dazu stellst du ausgewählte Daten in einer abgeschotteten Umgebung wieder her, misst die Dauer und vergleichst das Ergebnis mit dem Original. Für wichtige Systeme gehört dieser Test vierteljährlich in den Kalender, sonst bleibt die Wiederherstellung eine reine Hoffnung.
Warum „Backup vorhanden“ nicht „Backup funktioniert“ heißt
Ein Backup, das nie zurückgespielt wurde, ist nur eine Annahme. Defekte Sicherungsdateien, abgebrochene Jobs, fehlende Datenbank-Bestandteile oder ein Verschlüsselungspasswort, das niemand mehr kennt – all das fällt erst im Ernstfall auf, wenn die Zeit drängt. Der Restore-Test verlegt diesen Moment bewusst nach vorne: Du provozierst das Scheitern unter ruhigen Bedingungen, statt es während eines echten Ausfalls zu erleben.
Was du vor dem Restore-Test brauchst
- Eine isolierte Testumgebung: ein separater Rechner, eine virtuelle Maschine (VM – ein per Software nachgebildeter, eigenständiger Computer) oder ein abgetrenntes Netzsegment. Niemals direkt auf das Produktivsystem zurückspielen, sonst überschreibst du im schlimmsten Fall funktionierende Daten.
- Zugriff auf das Backup-Medium: externe Platte, NAS (Netzwerkspeicher), Bandlaufwerk oder Cloud-Konto – inklusive aller Zugangsdaten und des Verschlüsselungspassworts.
- Eine Referenz zum Vergleichen: Du musst wissen, wie die Daten im Original aussehen (Dateigrößen, Anzahl Datensätze, Prüfsummen), um die Wiederherstellung bewerten zu können.
- Etwas Zeit ohne Druck: Ein kleiner Datei-Restore dauert oft unter einer halben Stunde, ein voller Systemtest deutlich länger.
Restore-Test in 5 Schritten
- Umfang und Ziel festlegen. Entscheide, was du testest: eine einzelne Datei, ein E-Mail-Postfach, eine Datenbank oder ein komplettes System. Lege dazu eine messbare Vorgabe fest – etwa „Ordner X muss in unter 20 Minuten vollständig wiederhergestellt sein“. Diese Vorgabe ist dein Soll-Wert für Schritt 4.
- Testumgebung vorbereiten. Starte deine VM oder den Ersatzrechner und trenne sie sicherheitshalber vom Produktivnetz, damit eine wiederhergestellte Anwendung nicht versehentlich echte Dienste anspricht. Stelle sicher, dass die nötigen Grundvoraussetzungen laufen (Betriebssystem, Datenbankdienst, Laufzeitumgebung).
- Wiederherstellung durchführen und Zeit stoppen. Spiele das gewählte Backup nach den Vorgaben deiner Software zurück und notiere den Startzeitpunkt. Halte fest, ob das Programm Warnungen oder übersprungene Dateien meldet. Die tatsächliche Dauer ist eine der wichtigsten Kennzahlen des Tests.
- Ergebnis validieren. Prüfe nicht nur, ob Dateien da sind, sondern ob sie funktionieren: Öffne Dokumente, melde dich an der wiederhergestellten Anwendung an, lass eine Datenbank ihre Integritätsprüfung laufen. Vergleiche Dateianzahl und -größe mit dem Original (Soll-Ist-Abgleich).
- Dokumentieren und Termin setzen. Schreibe Datum, getestetes Objekt, gemessene Dauer, gefundene Probleme und Ergebnis auf. Trag dann den nächsten Test als festen Termin ein – für kritische Systeme mindestens vierteljährlich, für selten geänderte Daten einmal im Jahr.
Wer regelmäßig testet, muss nicht jedes Mal alles zurückspielen: Ein kleiner granularer Restore einzelner Objekte zwischendurch und ein großer Vollwiederherstellungs-Test ein- bis zweimal im Jahr decken zusammen die meisten Risiken ab.
Wenn die Wiederherstellung scheitert
Schlägt ein Restore-Test fehl, liegt es meist an einer dieser Ursachen:
- Backup unvollständig oder defekt: Der Job wurde abgebrochen oder die Datei ist beschädigt. Prüfe die Protokolle deiner Backup-Software auf Fehler des letzten Laufs und teste eine ältere Sicherung gegen.
- Passwort oder Schlüssel fehlt: Verschlüsselte Backups lassen sich ohne das richtige Passwort nicht öffnen. Hinterlege Schlüssel an einem zweiten, sicheren Ort – getrennt vom Backup selbst.
- Abhängigkeiten fehlen: Eine Anwendung startet nicht, weil eine Datenbank, ein Dienst oder eine bestimmte Software-Version in der Testumgebung fehlt. Notiere diese Abhängigkeiten und nimm sie in den Wiederherstellungsplan auf.
- Falsche Version wiederhergestellt: Du hast einen älteren Stand erwischt als erwartet. Prüfe Aufbewahrungszeitraum und Versionierung deiner Backup-Lösung.
Hintergrund: RTO, RPO und die 3-2-1-Regel
Zwei Kennzahlen helfen, das Testergebnis einzuordnen – sie tauchen auch in der Fachinformatiker-Prüfung gern auf. Die RTO (Recovery Time Objective) ist die maximal akzeptierte Zeit, bis ein System nach einem Ausfall wieder läuft. Genau diese Zeit misst du in Schritt 3. Die RPO (Recovery Point Objective) beschreibt, wie viel Datenverlust verkraftbar ist, also wie alt das jüngste brauchbare Backup höchstens sein darf. Ein tägliches Backup bedeutet eine RPO von bis zu 24 Stunden.
Als Faustregel für die Sicherung selbst gilt die 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine an einem anderen Ort. Der Restore-Test ist die Probe aufs Exempel, ob diese Kette im Ernstfall wirklich trägt – denn die teuerste Erkenntnis ist die, dass das Backup erst beim echten Datenverlust nicht funktioniert.
Häufige Fragen
Wie oft sollte ich einen Restore-Test machen?
Für geschäftskritische Systeme mindestens vierteljährlich, für selten geänderte Daten einmal pro Jahr. Mit automatisierten Tests darf es ruhig häufiger sein – jeder Test deckt nur den Stand zum Testzeitpunkt ab.
Kann ich das Backup einfach auf dem Produktivsystem testen?
Besser nicht. Spiele Sicherungen in einer isolierten Umgebung wie einer virtuellen Maschine oder einem Ersatzrechner zurück. So vermeidest du, funktionierende Produktivdaten versehentlich zu überschreiben.
Was ist der Unterschied zwischen RTO und RPO?
Die RTO ist die maximal akzeptierte Wiederanlaufzeit nach einem Ausfall. Die RPO gibt an, wie viel Datenverlust verkraftbar ist, also wie alt das jüngste brauchbare Backup höchstens sein darf.
Reicht es, wenn die wiederhergestellten Dateien vorhanden sind?
Nein. Prüfe, ob die Daten auch nutzbar sind: Dokumente öffnen, an der Anwendung anmelden, Datenbank-Integrität prüfen. Vorhandene, aber defekte Dateien bestehen den Test nicht.
Was tun, wenn der Restore-Test fehlschlägt?
Prüfe zuerst die Protokolle der Backup-Software auf Fehler, teste eine ältere Sicherung gegen und kontrolliere Verschlüsselungspasswort sowie fehlende Abhängigkeiten. Dokumentiere die Ursache und passe den Backup-Plan an.




