Zum Hauptinhalt springen
Wissens-Artikel·Hosting & Betrieb · 8 min · Stand 2026-04-28

Restore-Test: Warum jedes KMU ihn mindestens halbjährlich braucht

Ein Backup, das nie zurückgespielt wurde, ist nur eine Annahme. Wie ein Restore-Test ablaufen sollte, was dokumentiert werden muss und welche typischen Fehler er aufdeckt.

Veröffentlicht2026-04-28Aktualisiert2026-04-28Lesezeit8 minVerbleibend8 minSGFHosting & BetriebAutorSYSINFRA

Backup ohne Test ist Hoffnung

Ein Backup, das nie zurückgespielt wurde, ist keine belastbare Sicherheitsmassnahme. Die meisten Probleme zeigt erst der Test: defekte Backup-Sets, fehlende Schlüssel, inkonsistente Datenbanken, fehlende Treiber, vergessene Dependencies.

Genau deshalb ist der Restore-Test der wichtigste Teil einer Backup-Strategie, wichtiger als die Backup-Software selbst.

Was ein Restore-Test umfasst

ElementWas geprüft wird
LesbarkeitIst das Backup-Set überhaupt entpackbar?
KonsistenzLassen sich Daten wieder öffnen / Datenbank starten?
VollständigkeitSind alle relevanten Daten enthalten?
GeschwindigkeitWie lange dauert der Restore?
AbhängigkeitenSind Schlüssel, Lizenzen, Konfigurationen verfügbar?
DokuKonnte der Restore nachvollziehbar durchgeführt werden?

Was oft falsch läuft

„Jobs sind grün." Backup-Job-Status sagt nur, dass die Sicherung gelaufen ist. Nicht, dass sie wiederherstellbar ist.

Test im gleichen System. Wenn Backup auf gleicher Maschine zurückgespielt wird, ist die Aussagekraft begrenzt.

Kein Protokoll. Ohne Bericht wiederholt sich der Test selten.

Nur eine Datei testen. Eine einzelne Datei zurückzuholen ist kein Restore-Test eines Systems.

Frequenz nach Systemkritikalität

SystemEmpfohlene Frequenz
ERP, Buchhaltungquartalsweise
Datei-Serverhalbjährlich
Mail (M365 Backup)halbjährlich
Websitenach Plugin-/Major-Update
Online-Shopquartalsweise
ERP-Hot-Standbymonatlich

Beispiel aus dem KMU-Alltag

Ein Architekturbüro testet zum ersten Mal nach 18 Monaten den Restore des File-Servers. Ergebnis: Der Restore funktioniert, aber dauert 11 Stunden statt der angenommenen 3. Das angenommene RTO war eine Illusion. Die Reaktion: Backup-Strategie umgestellt auf inkrementelle Snapshots mit kürzerer Recovery-Zeit. Das Risiko wurde nicht durch ein Backup-Tool reduziert, sondern durch den Test.

Konkrete Empfehlung

  1. Restore-Test pro kritischem System mindestens halbjährlich
  2. Ergebnis dokumentieren (Datum, System, Dauer, Probleme, Massnahmen)
  3. Test in isolierter Umgebung, nicht produktiv
  4. Test umfasst ganze Restores, nicht nur einzelne Dateien
  5. Test nach jeder grösseren Änderung wiederholen

Wann wir helfen

Wir führen Restore-Tests als geplante Übung durch und liefern ein Protokoll als Nachweis (auch für Cyberversicherungen). Teil von Hosting & Infrastruktur. Siehe Backup ist nicht gleich Restore und RPO und RTO.

Häufige Fragen

Wie lange dauert ein Restore-Test? Halber Tag bis 2 Tage je nach System.

Stört er den Produktivbetrieb? Bei sauberer Planung kaum. Restores laufen meistens isoliert.

Reicht es, wenn der Anbieter testet? Nur wenn das Protokoll nachvollziehbar an Sie geliefert wird.

Was ist ein Restore-Drill? Realistisch geplanter Test mit Zeitmessung, näher am echten Notfall als ein „Datei zurückholen".

Was kostet das? Klar abgrenzbar als Projektarbeit oder im Wartungsmandat.