Backup-Wiederherstellung testen: ein Verfahren, das in eine Stunde passt

Ein grüner Haken in Ihrer Backup-Software heißt nicht, dass Sie wiederherstellen können. Ein konkretes Verfahren für den Wiederherstellungstest: drei Testarten, eine isolierte Umgebung, ein Bericht für Auditoren und der Umgang mit den Ergebnissen.

Backup-Wiederherstellung testen: ein Verfahren, das in eine Stunde passt

Jeden Morgen schickt die Backup-Software einen Bericht mit einem grünen Haken. Der Speicherplatz füllt sich, also wird etwas gesichert. Der IT-Verantwortliche ist ruhig, und der Geschäftsführer auch. Dann fällt der Buchhaltungsserver aus, und es stellt sich heraus, dass die Backups von einer Festplatte stammten, auf der die Datenbank seit einem halben Jahr nicht mehr lag, weil sie auf eine andere Partition verschoben worden war.

Wir kennen mehr als eine solche Geschichte. Allen gemeinsam ist, dass nie jemand versucht hat wiederherzustellen. Ein Backup, dessen Wiederherstellung nicht getestet wurde, ist kein Schutz, sondern die Annahme, dass es einen Schutz gibt. Den Unterschied lernen Sie im schlechtestmöglichen Moment kennen.

Die gute Nachricht: Ein Wiederherstellungstest ist kein einwöchiges Projekt. Das Kernverfahren passt in eine Stunde, und sein Ergebnis ist ein Dokument, das Sie einer Führungskraft, einem Auditor oder einem Versicherer zeigen können. Unten beschreiben wir, wie wir dabei vorgehen.

Warum ein grüner Haken nichts beweist

Backup-Software bestätigt nur, dass der Auftrag ohne Fehler beendet wurde. Sie prüft nicht, ob

  • das Richtige gesichert wird (die Datenbank, nicht ein leerer Ordner dafür);
  • das Backup konsistent ist (die Datenbank wurde nicht mitten in einem Schreibvorgang kopiert);
  • ein Betriebssystem mit allen Treibern und Lizenzen vom Backup aus startet;
  • die Wiederherstellung in die Ausfallzeit passt, die sich das Unternehmen leisten kann;
  • außer einem Administrator noch jemand weiß, wie die Wiederherstellung durchzuführen ist.

In unserer Praxis war jeder dieser Punkte schon einmal die Ursache eines realen Vorfalls. Keiner von ihnen erscheint im Bericht.

Es gibt noch ein weiteres, weniger technisches Argument. Solange eine Wiederherstellung nicht getestet wurde, kennt eine Person sie, und nur in der Theorie. Am Tag des Vorfalls kann diese Person im Urlaub sein, krank oder nicht mehr im Unternehmen. Ein Test zwingt dazu, das Verfahren aufzuschreiben und mindestens einmal von einem anderen Teammitglied durchführen zu lassen, was oft wertvoller ist als das Ergebnis selbst.

Drei Arten von Wiederherstellungstests

Tests unterscheiden sich in Umfang, Zeitbedarf und Aussagekraft. Sie brauchen alle drei, aber nicht gleich oft.

Test auf Dateiebene

Wählen Sie eine beliebige Datei oder E-Mail aus dem Backup der vergangenen Woche, stellen Sie sie in einem separaten Ordner wieder her und öffnen Sie sie. Das dauert wenige Minuten. Es beweist, dass die Backup-Kette funktioniert und die Daten lesbar sind. Es eignet sich als wöchentliche Routine, die jedes Mitglied des IT-Teams durchführen kann.

Test einer virtuellen Maschine

Eine ganze virtuelle Maschine (zum Beispiel der Buchhaltungsserver) wird aus dem Backup in ein isoliertes Netzwerk wiederhergestellt, gestartet, angemeldet und geprüft: Startet die Anwendung, und sind die Daten von gestern vorhanden? Je nach Größe der Maschine dauert das von 20 Minuten bis zu einer Stunde. Es beweist, dass aus dem Backup ein funktionierendes System entsteht und nicht nur eine Menge von Dateien. Das ist der Haupttest und derjenige, um den es in diesem Artikel geht.

Test des Gesamtsystems

Die gesamte Infrastruktur wird wiederhergestellt: Domänencontroller, Dateiserver, Buchhaltung, E-Mail und die Verbindungen dazwischen. Das dauert einen halben bis einen Tag. Es beweist, dass das Unternehmen aus Backups heraus arbeiten kann, nicht nur, dass jede Maschine für sich hochkommt. Das ist kein Test mehr, sondern eine Wiederherstellungsübung, und Unternehmen im Anwendungsbereich von NIS2 oder DORA sollten sie mindestens einmal im Jahr durchführen.

Ein Verfahren, das in eine Stunde passt

So führen wir den Test einer virtuellen Maschine für unsere Kunden durch.

  • Vorbereitung (10 Min.). Wählen Sie ein wichtiges System, am besten dasjenige, ohne das das Unternehmen als Erstes stillstehen würde. Notieren Sie die Startzeit. Bereiten Sie ein isoliertes Netzwerk vor: ein separates virtuelles Netz ohne Verbindung zur Produktion, damit ein wiederhergestellter Domänencontroller oder Buchhaltungsserver nicht mit dem laufenden kollidiert.
  • Wiederherstellung (20 bis 30 Min.). Stellen Sie die virtuelle Maschine aus dem Backup von gestern im isolierten Netzwerk wieder her. Veeam kann das direkt aus dem Backup-Repository tun, ohne darauf zu warten, dass die Daten in den Produktivspeicher verschoben werden. Halten Sie fest, wie lange die Wiederherstellung selbst gedauert hat.
  • Überprüfung (10 bis 15 Min.). Melden Sie sich an der wiederhergestellten Maschine an. Starten Sie die Anwendung. Öffnen Sie das Dokument oder den Datensatz von gestern. Prüfen Sie den Status der Dienste und die Protokolle auf Startfehler. Handelt es sich um einen Datenbankserver, führen Sie eine einfache Abfrage aus.
  • Abschluss (5 Min.). Löschen Sie die wiederhergestellte Maschine im isolierten Netzwerk. Schreiben Sie den Bericht.

Das Ergebnis ist nicht nur ein „funktioniert“ oder „funktioniert nicht“, sondern eine reale Wiederherstellungszeit, die Sie mit der Ausfallzeit vergleichen können, die das Unternehmen als akzeptabel festgelegt hat.

Warum die Umgebung isoliert sein muss

Ein häufiger Fehler ist, einen Server „nur zur Kontrolle“ direkt ins Produktivnetz wiederherzustellen. Zwei Domänencontroller mit demselben Namen, zwei DHCP-Server, ein mit den Daten von gestern wiederhergestelltes Buchhaltungssystem, das beginnt, Mahnungen an Kunden zu verschicken: Wir haben das alles gesehen. Ein Test, der einen Vorfall auslöst, ist schlimmer als gar kein Test.

Ein isoliertes Netzwerk ist ein separates virtuelles Netz ohne Route zur Produktion, das nur vom Arbeitsplatz des Administrators erreichbar ist. In unserer Cloud halten wir eine solche Umgebung dauerhaft vor. Es ist derselbe Ort, den wir für die PlanB-Infrastrukturwiederherstellung nutzen, sodass der Test zugleich bestätigt, dass der Wiederherstellungsstandort funktioniert.

Ein Bericht, den ein Audit akzeptiert

Ein Test ohne Dokument existiert für einen Auditor nicht. Der Bericht muss nicht lang sein, aber er muss konkrete Fragen beantworten:

  • Datum, Uhrzeit und wer den Test durchgeführt hat.
  • Welches System getestet wurde und aus dem Backup welchen Tages.
  • Testart: Datei, virtuelle Maschine oder Gesamtsystem.
  • Wie lange die Wiederherstellung dauerte und wie lange die Überprüfung.
  • Was geprüft wurde und das Ergebnis: bestanden, bestanden mit Anmerkungen oder nicht bestanden.
  • Gefundene Probleme und wer für die Behebung zuständig ist.
  • Wann der nächste Test geplant ist.

Eine Seite. Dieselbe Vorlage nutzen wir, wenn wir Unternehmen auf die Anforderungen von NIS2 vorbereiten. Für einen Auditor ist vor allem wichtig zu sehen, dass Tests regelmäßig stattfinden und gefundene Probleme angegangen werden, nicht dass jeder Test erfolgreich war.

Wie oft getestet werden sollte

Unsere Empfehlung für ein Unternehmen ohne gesonderte regulatorische Anforderungen:

  • Test auf Dateiebene: jede Woche, im Wechsel über die Systeme.
  • Test einer virtuellen Maschine: jeden Monat, jedes Mal ein anderes System, sodass innerhalb von sechs Monaten alle wichtigen abgedeckt sind.
  • Gesamtübung: einmal im Jahr oder nach jeder größeren Änderung der Infrastruktur, etwa einem neuen Server, einer Migration oder einem Wechsel der Backup-Lösung.

Für Unternehmen im Anwendungsbereich von DORA richtet sich die Häufigkeit nach der eigenen Richtlinie zum IKT-Risikomanagement, eine jährliche Übung ist aber das Minimum. Wenn Ihre Backup-Lösung eine automatisierte Prüfung der Wiederherstellung unterstützt (bei Veeam heißt sie SureBackup), schalten Sie sie ein. Sie ersetzt keinen manuellen Test, prüft aber jede Nacht, ob eine Maschine überhaupt aus ihrem Backup starten kann.

Was Sie mit den Ergebnissen tun

Ein fehlgeschlagener Test ist kein Misserfolg, sondern das bestmögliche Ergebnis: Sie haben das Problem gefunden und nicht die Ransomware. Weisen Sie jedem gefundenen Problem einen Verantwortlichen und eine Frist zu und wiederholen Sie den Test am selben System nach der Behebung. Tragen Sie die Zeiten erfolgreicher Tests in eine Tabelle ein. Nach einigen Monaten sehen Sie, welche Systeme länger zur Wiederherstellung brauchen, als sich das Unternehmen leisten kann, und können eine fundierte Entscheidung über häufigere Backups oder schnelleren Speicher treffen.

Wo Sie anfangen

  • Wählen Sie ein System, ohne das das Unternehmen stillstehen würde, und stellen Sie es diese Woche nach dem obigen Verfahren in einem isolierten Netzwerk wieder her.
  • Halten Sie das Ergebnis auf einer Seite fest und tragen Sie den nächsten Test in den Kalender ein.
  • Wenn der Test fehlgeschlagen ist oder Sie keinen Ort für eine isolierte Wiederherstellung haben, zögern Sie nicht: Das ist bereits ein Befund und keine Routine.
  • Wenn wir die Tests durchführen und dokumentieren sollen: Das ist ein Standardbestandteil der Leistung Veeam-Backup. Nehmen Sie über das Kontaktformular Kontakt mit uns auf, und wir führen den ersten Test gemeinsam durch.