Ihre 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 Ihnen einen Backup-Drill, der diese Frage ehrlich beantworten kann.
Kennen Sie diese Situation?
- Ihre Backup-Software meldet seit Jahren grüne Jobs. Ob die Daten im Ernstfall wirklich wiederherstellbar sind, hat seit der Einführung niemand systematisch getestet.
- Niemand kann auf Anhieb sagen, wie lange ein realistischer Restore des ERP-Servers dauern würde. Die Antwort schwankt zwischen „ein paar Stunden” und „bestimmt einen Tag” — je nachdem, wen man fragt.
- Microsoft 365 ist eingeführt, aber es gibt kein Third-Party-Backup für Exchange, SharePoint oder OneDrive. Falls jemand ein Postfach löscht oder Ransomware eine Mailbox verschlüsselt, ist die Antwort „Microsoft macht das schon” — und das stimmt nur zur Hälfte.
- Der Cyber-Versicherer hat einen Fragebogen geschickt, in dem nach „getesteten Restore-Verfahren” gefragt wird. Sie haben die Frage noch offen liegen, weil Sie nicht wissen, wie Sie ehrlich antworten sollen.
- Es gibt keine dokumentierte RTO (Recovery Time Objective) und keine RPO (Recovery Point Objective) — also keine schriftliche Verabredung, wie lange ein Ausfall dauern darf und wie viel Datenverlust toleriert wird.
Warum jetzt — und nicht später
Backup ist einer 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:
- Ransomware-Welle in der Branche — ein Mitbewerber wurde getroffen, in der Geschäftsführung kommt die Frage „Sind wir vorbereitet?” auf.
- Cyber-Versicherer fragt nach — der Fragebogen verlangt einen Nachweis über getestete Restore-Verfahren, sonst steigt die Prämie oder die Versicherung will nicht zeichnen.
- NIS-2-Vorbereitung — Business Continuity und Disaster Recovery sind Pflichtthemen, wenn Sie direkt betroffen sind oder als Zulieferer Nachweise erbringen müssen.
- Audit-Bemerkung — Wirtschaftsprüfer oder interne Revision hat das Thema markiert.
- M365-Konto wurde tatsächlich kompromittiert — und Sie haben gemerkt, dass die Wiederherstellung komplizierter ist als gedacht.
So sähe das bei Ihnen aus
Schritt 1 — RTO und RPO pro System festlegen
Wir setzen uns mit Ihnen 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 Ihnen drei bis fünf realistische Szenarien aus, die geübt werden sollen. Typischer Mix für eine mittelständische Firma:
- Szenario A — Einzelne Datei wiederherstellen: Jemand hat eine Konstruktionszeichnung gelöscht, sie wird in der Version von vorgestern gebraucht.
- Szenario B — Komplette VM oder Server wiederherstellen: Der ERP-Test-Server ist tot, er soll auf neuer Hardware oder in Azure aus dem Backup hochgezogen werden.
- Szenario C — M365-Postfach nach Kompromittierung wiederherstellen: Ein:e Mitarbeiter:in wurde gephisht, das Postfach wurde von Angreifern manipuliert, ein Stand von vor 24 Stunden wird gebraucht.
- Szenario D — SharePoint-Site oder OneDrive-Ordner wiederherstellen: Eine Site wurde versehentlich gelöscht oder verschlüsselt.
- Szenario E — Ransomware-Vollausfall: Mehrere Systeme sind verschlüsselt, was wird in welcher Reihenfolge wiederhergestellt?
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 Ihnen 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 wiederhergestellt, 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 haben Sie 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 Ihnen 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 Ihnen 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 das Tagesgeschäft zu blockieren. Liefer-Ergebnis: ein Kalender-Rhythmus mit Verantwortlichkeiten und ein Mini-Template, das beim nächsten Mal die Vorbereitung halbiert.
Worauf Sie achten sollten
- Bestehen Sie darauf, dass der Drill in einer isolierten Umgebung durchgeführt wird — nicht auf der Produktion. Wer „Restore-Test live im laufenden System” vorschlägt, hat keinen Plan B, wenn der Test schiefgeht. Eine separate Sandbox ist Pflicht.
- Fragen Sie nach dem Erfolgskriterium pro Szenario, bevor der Drill startet. „Wir testen den Restore” ist kein Kriterium. „Postfach mit Stand vor 24 Stunden ist im Test-Tenant verfügbar und lesbar” ist eines.
- Achtung bei Backup-Software, die ihre eigene Validierung als Restore-Test verkauft. Eine integrierte Job-Verifikation ist gut, aber sie ist kein vollständiger Drill. Sie prüft die Lesbarkeit der Backup-Datei, nicht die Funktionsfähigkeit des wiederhergestellten Systems.
- Klären Sie vor dem Drill, wer in welcher Reihenfolge informiert wird, wenn der Test schiefgeht. Auch eine Übung kann einen Vorfall auslösen — z. B. wenn beim Restore-Versuch die Backup-Lizenz limitiert ist und keine weiteren Jobs mehr laufen.
- Planen Sie das Runbook für die Person mit dem geringsten Wissen ein, nicht für sich selbst. Im Ernstfall ist die Spezialistin im Urlaub. Wenn das Runbook nur sie verstehen würde, ist es kein Runbook, sondern ein Notizzettel.
Was sich danach realistisch ändert
- Sie haben schwarz auf weiß, wie lange ein realistischer Restore pro Szenario dauert — und welche Datenmengen wirklich wiederherstellbar sind.
- Die Frage des Cyber-Versicherers nach getesteten Restore-Verfahren beantworten Sie mit einem Protokoll, nicht mit „wir machen das demnächst”.
- Wenn der Ernstfall eintritt, gibt es ein Runbook, das auch die Vertretung ausführen kann.
- RTO und RPO sind nicht mehr „Bauchgefühl”, sondern eine schriftliche Verabredung zwischen IT und Geschäftsführung — mit realistischen Werten.
- Lücken im Backup-Konzept (fehlende M365-Sicherung, zu kurze Retention, ungünstige Restore-Ziele) sind bekannt und priorisiert, statt unerkannt zu schlummern.
Was Sie beisteuern
- Eine Person, die das Backup-System administrativ kennt und währenddessen ansprechbar ist.
- Zugang zur Backup-Konsole, zur Ziel-Umgebung (Azure, lokale Hardware) und zu den Test-Daten.
- Etwa einen halben bis ganzen Arbeitstag der IT-Verantwortlichen pro Drill, plus rund 2 Stunden Stakeholder-Zeit für die RTO/RPO-Festlegung mit der Geschäftsführung.
- Bereitschaft, ehrliche Ergebnisse zu akzeptieren — auch wenn der erste Drill zeigt, dass die Restore-Zeit länger ist als bisher angenommen.
Risiken und wann es nicht passt
- Wenn Ihr Backup-System veraltet ist und ein Versions-Upgrade ohnehin ansteht — dann erst das Upgrade, dann der Drill. Es bringt wenig, eine Architektur zu testen, die in drei Monaten ersetzt wird.
- Wenn Sie noch gar keine systematische Backup-Lösung haben, sondern „ein paar Skripte und externe Festplatten” — dann erst die Lösung aufsetzen, dann den Drill. Wir helfen bei beidem, aber in dieser Reihenfolge.
- Wenn die Geschäftsführung den Drill als „Daumen hoch”-Übung erwartet, in der nichts schief gehen darf — dann lieber vorher klären, dass ein Drill genau dazu da ist, Lücken zu finden. Wer keine Lücken finden will, sollte keinen Drill machen.
So fängt das Gespräch an
- 30 Minuten Erstgespräch, kostenfrei, per Video oder Telefon.
- Was wir klären: aktuell eingesetzte Backup-Lösung, welche Systeme darunter laufen, dringendste Frage (Versicherung, Audit, Bauchgefühl), Zeitfenster für einen ersten Drill.
- Optional vorab nützlich: ein Screenshot der letzten Backup-Übersicht, Information ob M365-Backup vorhanden ist, grobe Vorstellung welche Systeme geschäftskritisch sind.
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-Aufbewahrung für endgültig gelöschte Mails liegt bei 14 Tagen (auf maximal 30 erweiterbar), gelöschte Postfächer bleiben 30 Tage wiederherstellbar. 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 Ihrer 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 Ihnen, 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.