Der Restore-Test: Warum dein Backup erst nach dem Test zählt

Ein Backup, das nie wiederhergestellt wurde, ist keine Sicherung — es ist eine Hoffnung. Die unangenehmste Frage in jedem IT-Gespräch ist deshalb nicht „Haben Sie ein Backup?”, sondern: „Wann haben Sie zuletzt daraus etwas wiederhergestellt?” In der Praxis scheitern Backups selten beim Speichern. Sie scheitern beim Restore: Das Band ist leer, die Cloud-Synchronisation lief seit Monaten nur halb, das Passwort für das verschlüsselte Archiv kennt niemand mehr. Dieser Beitrag zeigt, wie Sie in rund 30 Minuten prüfen, ob Ihre Sicherung hält, was sie verspricht — und was Sie dabei dokumentieren sollten. Er baut auf unserem Artikel zur 3-2-1-1-0-Backup-Regel auf; wer die Grundstruktur noch nicht stehen hat, beginnt am besten dort.

Warum Backups beim Restore scheitern

Die typischen Fehlerbilder sind erstaunlich unspektakulär:

• Das Backup läuft — aber nicht vollständig. Neue Server, neue Postfächer oder ein neuer Ordner wurden nie in den Sicherungsauftrag aufgenommen. Gesichert wird brav das, was vor zwei Jahren wichtig war.
• Der Auftrag schlägt still fehl. Speicher voll, Zugangsdaten abgelaufen, Netzlaufwerk nicht erreichbar. Ohne Benachrichtigung merkt das niemand, bis es zu spät ist.
• Die Kette ist länger als gedacht. Die Wiederherstellung braucht eine bestimmte Softwareversion, einen Lizenzschlüssel oder genau das eine Administratorkonto, das es nicht mehr gibt.
• Verschlüsselung ohne Schlüssel-Management. Das Backup ist sauber verschlüsselt — und der Schlüssel lag ausschließlich auf dem verschlüsselten System. Das ist kein Szenario aus dem Lehrbuch, sondern Alltag.

Keiner dieser Fehler fällt auf, solange nur gesichert wird. Alle fallen auf, wenn man wiederherstellt. Genau deshalb ist der Restore-Test die eigentliche Qualitätskontrolle.

Der 30-Minuten-Restore-Test

Sie brauchen dafür kein Labor und keinen Notfall. Ein ruhiger Vormittag genügt:

1. Ziel festlegen (5 Minuten). Wählen Sie drei repräsentative Objekte: eine einzelne Datei aus einem Projektordner, ein komplettes Postfach-Element (etwa eine gelöschte E-Mail) und ein Element aus Ihrer wichtigsten Fachanwendung oder Datenbank. Damit decken Sie die drei häufigsten Ernstfälle ab: versehentliches Löschen, einzelnes verlorenes Objekt, fachlicher Datenverlust.

2. Wiederherstellung durchführen (15 Minuten). Stellen Sie alle drei Objekte in einem Testbereich wieder her — nicht am Originalort. Wichtig: Führen Sie den Test so durch, wie es im Ernstfall wäre. Wenn im Ernstfall der externe Dienstleister restoren würde, soll der Dienstleister den Test machen — aber Sie schauen zu und stellen die Fragen.

3. Ergebnis prüfen (5 Minuten). Öffnen Sie die wiederhergestellten Dateien. Ist die Datei lesbar, aktuell, vollständig? Stimmen Datum und Inhalt? Ein erfolgreicher Kopiervorgang ohne Inhaltsprüfung ist nur ein halber Test.

4. Zeit stoppen (5 Minuten). Notieren Sie, wie lange die Wiederherstellung tatsächlich gedauert hat — inklusive Suche nach Zugangsdaten und Rückfragen. Diese Zahl ist ehrlicher als jede Angabe im Datenblatt Ihres Backup-Systems.

Das war’s. Kein Komplett-Restore des Servers, kein Wochenendprojekt. Wer diesen kleinen Test quartalsweise macht, weiß mehr über seine Sicherung als die meisten Betriebe nach Jahren.

Was Sie dokumentieren sollten

Ein Restore-Test ohne Protokoll ist eine halbe Sache. Eine halbe Seite genügt, aber sie gehört an einen festen Ort:

• Datum und durchführende Person. Wer hat wann getestet.
• Was wurde wiederhergestellt. Die drei Testobjekte, konkret benannt.
• Ergebnis. Erfolgreich / teilweise / fehlgeschlagen — mit kurzer Begründung.
• Dauer. Wie lange hat es gedauert, vom Auftrag bis zur geöffneten Datei.
• Auffälligkeiten und Maßnahmen. Was hat gehakt, was wird geändert, bis wann, durch wen.
• Nächster Termin. Der Test gehört in den Kalender, nicht auf die Liste guter Vorsätze.

Dieses Protokoll hat drei Vorteile: Es macht Wissen unabhängig von einzelnen Personen, es zeigt Versicherungen und Prüfern auf Wunsch, dass das Thema ernst genommen wird — und es zwingt dazu, gefundene Probleme tatsächlich zu beheben statt sie nur zu kennen.

Häufige Fehler beim Testen

Nur die IT testet, nie die Anwender. Die Fachabteilung sollte die wiederhergestellte Datei öffnen und bestätigen, dass sie die richtige ist. Die IT kann Bits prüfen, keine fachliche Vollständigkeit.

Immer dasselbe Testobjekt. Wer jedes Mal dieselbe Datei restoret, testet irgendwann nur noch einen Sonderfall. Rotieren Sie die Objekte — und nehmen Sie gelegentlich etwas aus einem älteren Sicherungsstand, denn im Ernstfall brauchen Sie oft genau den Stand von vor drei Wochen.

Der große Test wird aufgeschoben. Mindestens einmal im Jahr sollte ein größerer Restore anstehen: ein komplettes Laufwerk oder ein virtueller Server in einer Testumgebung. Der 30-Minuten-Test ersetzt das nicht, er ergänzt es.

Niemand weiß, wer zuständig ist. Der Restore-Test braucht eine benannte verantwortliche Person — intern oder beim Dienstleister. „Das macht schon wer” ist der Zustand, in dem Backups zu Hoffnungen werden.

Wie der Test ins Gesamtkonzept passt

Der Restore-Test ist das „0” in der 3-2-1-1-0-Regel: null Fehler nach der Prüfung. Er lohnt sich besonders dort, wo ein Angriff die Sicherung selbst bedroht — bei Ransomware entscheidet die Wiederherstellbarkeit über die Existenz des Betriebs. Dass solche Angriffe fast immer mit einer getäuschten Person beginnen, haben wir in unserem Artikel zu den fünf Phishing-Warnsignalen beschrieben. Backup und Mitarbeitenden-Sensibilisierung sind zwei Seiten derselben Medaille: Das Backup begrenzt den Schaden, die Sensibilisierung verhindert ihn.

Und falls Ihnen der Restore-Test zu aufwendig erscheint: Vergleichen Sie die 30 Minuten mit der Alternative — einem Dienstleister-Einsatz unter Zeitdruck, einem Wochenende Betriebsstillstand und der offenen Frage, ob die Daten überhaupt zurückkommen.

FAQ

Wie oft sollten wir testen? Als vernünftiger Rhythmus für KMU hat sich bewährt: quartalsweise der kleine 30-Minuten-Test, jährlich ein größerer Restore eines kompletten Systems. Nach jeder Änderung an Servern, Anwendungen oder Backup-Software testen Sie zusätzlich — neue Umgebung, neuer Test.

Wir haben ein Cloud-Backup bei Microsoft 365 — brauchen wir das trotzdem? Ja. Die Synchronisation in Microsoft 365 oder Google Workspace ist kein vollwertiges Backup, und auch ein echtes Cloud-Backup muss getestet werden: Können Sie eine einzelne, vor vier Wochen gelöschte Datei gezielt zurückholen? Wenn Sie das noch nie probiert haben, ist heute ein guter Tag dafür.

Was, wenn der Test fehlschlägt? Dann hat der Test seinen Zweck erfüllt — besser heute als im Ernstfall. Beheben Sie die Ursache, dokumentieren Sie die Änderung und wiederholen Sie den Test zeitnah, bis er sauber durchläuft. Ein fehlgeschlagener Test ist kein Skandal, sondern der Normalfall beim ersten Mal.

Muss das ein externer Dienstleister machen? Nein, aber jemand muss es können — und zwar schriftlich dokumentiert können, nicht nur aus dem Gedächtnis. Wenn der Restore vom Know-how einer einzelnen Person abhängt, ist das ein eigenes Risiko, unabhängig vom Backup-System.

Nächster Schritt

Sie wollen wissen, ob Ihre Sicherung im Ernstfall trägt — ohne selbst im System herumzuprobieren? Wir führen den Restore-Test gemeinsam mit Ihnen durch, prüfen Ihre Backup-Struktur gegen die 3-2-1-1-0-Regel und richten Protokoll und Benachrichtigungen so ein, dass der Test ab dann Routine ist. IT, Datenschutz und KI aus einer Hand, lokal in Österreich. Vereinbaren Sie ein Erstgespräch. IT. Weitergedacht.