Nexaro UG
DE / EN
Start / Use Cases / Backup-Drill

Wie testen wir Restore und Recovery wirklich, statt nur Backups laufen zu lassen?

Backups laufen seit Jahren grün — aber wann wurde zuletzt ein Restore wirklich getestet? Ein strukturierter Backup-Drill für mittelständische Firmen, der die ehrliche Antwort liefert: wie lange dauert die Wiederherstellung wirklich.

Eure Backups laufen. Jeden Morgen schickt das System eine grüne Mail, manchmal wöchentlich eine Übersicht. Niemand schaut so genau hin, weil es ja grün ist. Die unangenehme Frage kommt irgendwann von außen — vom Cyber-Versicherer, vom Auditor, vom Wirtschaftsprüfer: „Wann wurde zuletzt ein Restore wirklich getestet?” Wir bauen mit euch einen Backup-Drill, der diese Frage ehrlich beantworten kann.

Hast du diese Situation?

Warum das jetzt löst statt verschoben wird

Backup ist eine der Bereiche, in denen das Versprechen und die Realität am weitesten auseinander liegen. Eine grüne Backup-Meldung bedeutet, dass Daten geschrieben wurden — nicht, dass sie lesbar sind, dass die richtigen Daten dabei sind, und schon gar nicht, dass eine Wiederherstellung in akzeptabler Zeit klappt. Wer den Drill verschiebt, verschiebt das Problem nur bis zum Ernstfall.

Typische Auslöser, die jetzt dran sind:

So sähe das bei euch aus

Schritt 1 — RTO und RPO pro System festlegen

Wir setzen uns mit euch und der Geschäftsführung zusammen und gehen die wichtigen Systeme durch: ERP, Dateiablage, Mail, CAD, Branchensoftware. Pro System klären wir: Wie lange darf das System maximal ausfallen, bevor das Geschäft ernsthaft leidet (RTO)? Wie viel Datenverlust ist tolerierbar — eine Stunde, vier Stunden, ein Tag (RPO)? Das ist eine Geschäfts-Entscheidung, keine IT-Entscheidung. Liefer-Ergebnis: eine kompakte Tabelle, in der pro System eine schriftliche RTO/RPO-Verabredung steht. Damit hört das „bestimmt einen Tag”-Schätzen auf.

Schritt 2 — Restore-Szenarien definieren

Wir suchen mit euch drei bis fünf realistische Szenarien aus, die geübt werden sollen. Typischer Mix für eine mittelständische Firma:

Liefer-Ergebnis: eine Szenario-Liste mit klarer Erfolgs-Definition pro Szenario. Was muss am Ende des Drills funktionieren, damit der Test als bestanden gilt?

Schritt 3 — Drill in einer isolierten Umgebung durchführen

Wir setzen mit euch eine isolierte Test-Umgebung auf — eine separate Azure-Subscription, eine VM-Sandbox oder ein dedizierter Test-Bereich. Dort spielen wir die Szenarien durch. Bei Szenario B wird der ERP-Test-Server wirklich aus dem Backup wiederhergestellt, gestartet, gegen die Datenbank validiert. Bei Szenario C wird ein Testpostfach restoriert, der Inhalt geprüft. Während des Drills läuft eine Stoppuhr — pro Szenario halten wir fest, wie lange es real gedauert hat, wo es gehakt hat, was unklar war. Liefer-Ergebnis: ein Drill-Protokoll mit echten Zeiten, echten Datenmengen, echten Hindernissen. Keine Theorie.

Schritt 4 — Lücken bewerten und Restore-Runbook schreiben

Nach dem Drill habt ihr drei Arten von Erkenntnissen: Was hat funktioniert (manchmal überraschend gut), was hat länger gedauert als gehofft, und was hat gar nicht funktioniert. Wir bewerten mit euch die Lücken. Manche sind technische Lücken (zu wenig Bandbreite zum Backup-Ziel, falsche Retention-Einstellung, fehlende Indexierung), manche sind organisatorische Lücken (niemand wusste, wo das Recovery-Passwort liegt, der Verantwortliche war im Urlaub). Daraus entsteht ein Restore-Runbook: eine Schritt-für-Schritt-Anleitung pro Szenario, die auch eine Vertretung im Ernstfall ausführen kann. Liefer-Ergebnis: ein Runbook von 5 bis 15 Seiten, kein Roman.

Schritt 5 — Wiederholungs-Rhythmus festlegen

Ein einmaliger Drill ist besser als nie — aber er altert. Wir vereinbaren mit euch einen realistischen Rhythmus: einmal pro Jahr ein voller Drill, halbjährlich ein kleiner Stichproben-Test einzelner Szenarien. Das passt in eine mittelständische Firma, ohne die Operative zu blockieren. Liefer-Ergebnis: ein Kalender-Rhythmus mit Verantwortlichkeiten und ein Mini-Template, das beim nächsten Mal die Vorbereitung halbiert.

Worauf du dabei achten solltest

Was sich danach realistisch ändert

Was ihr beisteuert

Risiken und wann es nicht passt

So fängt das Gespräch an

Erstgespräch buchen

Häufige Fragen

Reicht es nicht, wenn unsere Backup-Software die Jobs intern verifiziert? Die interne Verifikation prüft, ob die Backup-Datei lesbar ist — das ist hilfreich, aber nicht ausreichend. Ein echter Restore-Drill prüft, ob das wiederhergestellte System auch funktioniert: ob die Datenbank startet, ob die Anwendung sich verbindet, ob die Benutzer:innen sich anmelden können. Das ist eine andere Klasse von Test.

Brauchen wir wirklich ein Third-Party-Backup für Microsoft 365? Häufig ja, aber nicht immer. Microsoft sichert die Infrastruktur — was Microsoft nicht macht, ist ein langer Wiederherstellungs-Horizont für versehentlich gelöschte oder durch Angreifer manipulierte Daten. Die Standard-Retention für gelöschte Mails liegt bei 30 Tagen, für gelöschte Konten ähnlich. Wer länger zurück muss, braucht eine eigene Lösung. Im Drill wird das schnell sichtbar.

Wie lange dauert ein Drill insgesamt? Vorbereitung und Szenario-Definition rund eine Woche, die eigentliche Drill-Durchführung typischerweise einen Tag in der Sandbox, Auswertung und Runbook-Erstellung ein bis zwei Wochen. Für die erste Iteration also etwa 3 bis 4 Wochen Laufzeit, mit überschaubarem Zeit-Einsatz auf eurer Seite.

Was, wenn der Drill zeigt, dass unser Backup-Konzept Lücken hat? Genau dafür ist der Drill da. Lücken sind erstmal eine gute Nachricht — sie sind bekannt, statt im Ernstfall zu überraschen. Wir priorisieren mit euch, welche Lücken zuerst geschlossen werden müssen, und welche akzeptabel sind. Nicht jede Lücke muss sofort behoben werden, aber jede sollte bewusst entschieden sein.

Verwandtes