Backup-Test-Tag: Restores in 30 Minuten beweisen

Der einzige Test, der ein Backup wirklich validiert, ist der Restore. Niemand bestreitet das in der Theorie. In der Praxis passieren Restores in vielen Unternehmen erst, wenn es tatsächlich brennt — und dann kommen die Überraschungen: Das Backup ist da, aber nicht lesbar. Die Tape-Library hat seit drei Monaten Fehler geworfen, die niemand priorisiert hat. Der M365-Restore funktioniert in der Theorie, aber die OAuth-Tokens sind abgelaufen.

Wir empfehlen unseren Kunden seit Jahren ein einfaches Format: den Backup-Test-Tag. Monatlich, idealerweise an einem festen Termin (z.B. zweiter Mittwoch). 30 Minuten pro Restore-Szenario, vier rotierende Szenarien — ein Quartal abgedeckt in vier Monaten. Dokumentiert, mit Checkliste, mit Verantwortlichen.

Dieser Artikel zeigt, wie wir den Backup-Test-Tag in Kundenprojekten aufsetzen — inklusive der Frage, was warum dokumentiert werden muss.

Warum 30 Minuten

Die häufigste Ausrede gegen Restore-Tests: “Wir haben keine Zeit.” Stimmt — aber 30 Minuten pro Monat hat jeder IT-Verantwortliche. Der Trick: Man testet nicht einen kompletten Disaster-Recovery-Lauf, sondern ein einzelnes Szenario in seinem natürlichen Zeitrahmen.

Ein PBS-Restore einer kleinen Test-VM dauert real 5–15 Minuten — mit Doku, Verify und Cleanup landet man bei 30 Minuten. Ein TrueNAS-Snapshot-Restore eines einzelnen Datasets oder einer einzelnen Datei dauert minuten. Vier Szenarien á 30 Minuten = zwei Stunden pro Quartal — und nach einem Jahr hat man 48 dokumentierte Restore-Tests, die jede Versicherung und jede NIS2-Prüfung akzeptiert.

Die vier Standard-Szenarien

Wir rotieren in vier Monatsblöcken durch:

Monat	Szenario	Ziel
Januar / Mai / September	PBS-Restore einer VM	Hypervisor- und Image-Backup-Layer prüfen
Februar / Juni / Oktober	TrueNAS-Snapshot-Restore	Storage-Snapshots und ZFS-Replikation prüfen
März / Juli / November	M365-Restore (Veeam / AvePoint)	Cloud-Backup-Layer prüfen
April / August / Dezember	Tape- oder Cloud-Tier-Restore	Air-Gap-/Long-Term-Backup prüfen

Jedes Szenario hat eine eigene Checkliste — die ist bewusst auf 10–15 Punkte begrenzt. Wer die abhakt, hat das Szenario validiert.

Szenario 1: PBS-Restore einer VM (30 Minuten)

Vorbereitung (5 Minuten)

1. Test-VM-ID festlegen — eine produktive VM mit kleinem Footprint (z.B. ein Print-Server, 8–20 GB)
2. Zielstorage prüfen — wo soll der Restore landen? Auf welchem Storage liegt genug Platz?
3. Restore-Konfliktstrategie klären — wir restoren in der Regel mit neuer VMID oder in einen leeren Storage, um die Produktion nicht zu touchieren

Restore (15 Minuten)

# Auf einem Proxmox-Node
proxmox-backup-client list \
  --repository pbs-user@pbs!datazone@backup-server:datastore1

# Letzten Snapshot der Test-VM auswählen
proxmox-backup-client snapshot list vm/142 \
  --repository pbs-user@pbs!datazone@backup-server:datastore1

# Restore via Proxmox-WebUI (einfacher) oder via API/CLI
# WebUI: Storage -> Backups -> [Backup auswählen] -> Restore -> Target VMID frei lassen

Oder per Web-UI: Storage > Backups > [Backup auswählen] > Restore, neue VMID setzen, “Start nach Restore” ausschalten.

Verify (5 Minuten)

• VM startet sauber (Boot-Loop-Check)
• Login funktioniert
• Wichtigste Anwendung auf der VM startet (Service-Check)
• Disk-Usage stimmt zum Backup-Zeitpunkt
• Netzwerk-Verbindung optional (“isoliertes Test-Netz” ist sauberer)

Aufräumen + Doku (5 Minuten)

qm destroy 999 --purge

Doku-Eintrag im internen Wiki / Confluence:

Datum: 2026-05-15
Szenario: PBS-Restore VM 142 (Print-Server)
Ausgeführt von: Florian Schermer
Ergebnis: OK
Dauer: 28 Minuten
Auffälligkeiten: Keine
Nächster Test: 2026-09-15

Szenario 2: TrueNAS-Snapshot-Restore (30 Minuten)

Vorbereitung (5 Minuten)

1. Dataset auswählen — ein produktives Dataset mit nicht-kritischen Daten (z.B. tank/shared/test)
2. Snapshot-Liste prüfen — auf der TrueNAS-WebUI oder per CLI: zfs list -t snapshot tank/shared/test
3. Restore-Methode wählen: Clone, Rollback, oder File-Level-Restore

Restore (10 Minuten)

Drei Varianten, je nach Test-Ziel:

Variante A — File-Level (am häufigsten):

# SSH auf TrueNAS
zfs list -t snapshot tank/shared/test
# Pfad zum gewünschten Snapshot finden:
ls /mnt/tank/shared/test/.zfs/snapshot/auto-2026-05-14_02-00/
# Datei zurückkopieren:
cp /mnt/tank/shared/test/.zfs/snapshot/auto-2026-05-14_02-00/wichtige-datei.xlsx \
   /mnt/tank/shared/test/wichtige-datei-restored.xlsx

Variante B — Clone (für isolierte Tests):

zfs clone tank/shared/test@auto-2026-05-14_02-00 tank/shared/test-restore-2026-05-15
# Dataset über WebUI als SMB-Share veröffentlichen, dann prüfen

Variante C — Rollback (destruktiv, vorsichtig!):

In der Regel nicht für den Test-Tag — Rollback wirft alle Snapshots nach dem Ziel-Snapshot weg.

Verify (10 Minuten)

• Datei ist lesbar und identisch zum Erwartungswert (Hash-Check)
• ZFS-Properties korrekt (compress, atime etc.)
• Bei Clone: SMB-Zugriff funktioniert
• Audit-Log auf TrueNAS zeigt die Operationen

Aufräumen + Doku (5 Minuten)

Restore-Dateien löschen, Clones zerstören (zfs destroy ...), Doku-Eintrag schreiben.

Szenario 3: M365-Restore (30 Minuten)

Microsoft 365 ist für viele Mittelstandskunden inzwischen der wichtigste Datenspeicher. Microsofts native Wiederherstellungsoptionen reichen für Compliance-Anforderungen nicht — Veeam Backup for Microsoft 365, AvePoint Cloud Backup oder vergleichbare Lösungen sichern Exchange, SharePoint, OneDrive und Teams separat.

Vorbereitung (5 Minuten)

1. Testuser auswählen — eigenes Test-Konto, das in dem M365-Tenant existiert (kein Produktiv-User)
2. Test-Item auswählen — eine spezifische E-Mail, ein SharePoint-Dokument, eine OneDrive-Datei
3. Restore-Ziel festlegen — in Original-Location, in alternative Location, oder in Test-Postfach

Restore (15 Minuten)

In der Veeam-M365-Konsole:

1. Backup-Job für den Tenant öffnen
2. Restore-Wizard starten (Exchange / SharePoint / OneDrive — je nach Test)
3. Test-Item suchen und auswählen
4. Restore-Target wählen (für Test: alternatives Postfach oder lokaler Export)
5. Restore starten

Verify (5 Minuten)

• Item ist im Ziel sichtbar
• Metadaten korrekt (Datum, Absender etc.)
• Bei E-Mail: Anhänge intakt
• Bei SharePoint/OneDrive: Versions-History erhalten

Aufräumen + Doku (5 Minuten)

Test-Items aus alternativem Postfach löschen, Doku schreiben.

Szenario 4: Tape- oder Cloud-Tier-Restore (30 Minuten)

Dieses Szenario ist das am häufigsten vergessene — und das, in dem die meisten Fehler stecken. Tapes, die seit Monaten “im Bankschließfach” liegen, haben unter Umständen Block-Fehler. Cloud-Tiers wie S3 Glacier haben Egress-Kosten und Wartezeiten von mehreren Stunden, die im Notfall überraschend lang werden.

Vorbereitung (5–10 Minuten)

1. Backup-Medium besorgen — Tape aus dem Schließfach holen oder Cloud-Restore-Job vorbereiten
2. Restore-Ziel festlegen — eigenes Test-Volume, niemals Produktion
3. Spezifisches Item für Restore — eine VM, ein Dataset, eine Dateigruppe

Restore (15–20 Minuten)

Hier passiert das, was die Stoppuhr durcheinanderbringt: Tape-Restores brauchen Spulzeit. Ein LTO-8-Tape spult zum Block-Offset in 30–90 Sekunden, Restore selbst ist bei 200 GB ca. 15–20 Minuten netto. Bei Cloud-Glacier-Tiers kann allein die Restore-Bereitstellung mehrere Stunden brauchen — diese Wartezeit ist ein wichtiger Befund des Test-Tags.

Wenn der Test länger als 30 Minuten dauert, ist das kein Fehler — es ist genau die Information, die im Notfall hilft: “Tape-Restore unserer 2-TB-VM dauert ca. 2 Stunden. Recovery-Time-Objective entsprechend planen.”

Verify (5 Minuten)

• Restore-Daten lesbar
• Integrität geprüft (Backup-Verify ggf. zusätzlich)
• Restore-Zeit gemessen und dokumentiert

Aufräumen + Doku (5 Minuten)

Test-Daten löschen, Tape zurückbringen, Doku mit Zeitmessung.

Die Doku — keine Bürokratie, sondern Beweis

Jede der vier Szenario-Durchläufe wird in einem Restore-Log dokumentiert. Wir empfehlen ein einfaches Markdown-Dokument oder ein Confluence-Seite mit Tabelle:

Datum	Szenario	Ausgeführt von	Dauer	Ergebnis	Auffälligkeiten	Nächster Test
2026-01-14	PBS-VM-Restore	F. Schermer	28 min	OK	—	2026-05-13
2026-02-11	TrueNAS-Snapshot	F. Schermer	22 min	OK	—	2026-06-10
2026-03-11	M365 Exchange	M. Bauer	31 min	OK	OAuth-Token erneuern	2026-07-08
2026-04-08	LTO-8-Tape	F. Schermer	47 min	OK	Spulzeit 90 s, akzeptabel	2026-08-12

Das ist das Dokument, das man einer Versicherung, einer NIS2-Prüfung, einer GoBD-Außenprüfung oder einer ISO-27001-Auditierung vorlegt. Vier Zeilen pro Quartal, ein Dutzend pro Jahr.

Was NIS2, GoBD und ISO 27001 dazu sagen

• NIS2 (umgesetzt in § 30 BSIG): “geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen” inklusive Backup- und Wiederherstellungsverfahren — die Wiederherstellbarkeit muss nachweisbar getestet sein
• GoBD: Verfahrensdokumentation muss “Datensicherung und Wiederherstellung” beschreiben — ein Restore-Test-Log ist hierfür das beweisstärkste Element
• ISO 27001, Annex A.12.3: “Information backup” — Anforderung an regelmäßige Backup-Tests
• DSGVO Art. 32 (1) c: “Verfügbarkeit und Belastbarkeit” der Verarbeitungssysteme — Wiederherstellbarkeit nach Vorfall

In allen vier Standards ist das Schlagwort dasselbe: regelmäßig getestet. Niemand definiert “regelmäßig” mit konkretem Intervall — aber monatlich ist nachweislich ausreichend und in Audits noch nie als zu selten kritisiert worden.

Was schief geht — und was man daraus lernt

Aus echten Test-Tagen unserer Kunden die häufigsten Befunde:

• PBS-Backup-Server voll — Retention war zu großzügig, neue Backups konnten nicht geschrieben werden
• TrueNAS-Replikation hing seit 17 Tagen — niemand hatte die Mail-Reports gelesen
• M365-Backup hatte abgelaufene App-Registrations — Veeam zog seit Monaten keine neuen Daten
• Tape-Laufwerk-Reinigungsfehler — der Reinigungs-Counter hatte den Schwellwert überschritten
• Restore-Performance schlechter als RTO — Backup war OK, aber 2-TB-Restore brauchte 6 statt 2 Stunden

Jeder dieser Befunde wäre im Notfall fatal. In einem Test-Tag im Mai sind es 30 Minuten und ein Ticket.

Was wir bei DATAZONE empfehlen

Konkrete Umsetzung für ein typisches KMU mit 50–200 Mitarbeitenden:

1. Fester Termin im Kalender — zweiter Mittwoch im Monat, 14:00–14:30, IT-Verantwortliche blocken sich das Zeitfenster
2. Vier Szenarien rotiert wie oben, Checkliste pro Szenario im Wiki
3. Notfall-Dokumentation immer im selben Update-Zyklus — wer macht was im Ernstfall, mit Telefonnummern
4. Quartalsweiser Review mit Geschäftsführung — vier Test-Logs als Anhang, 15 Minuten Diskussion
5. Externer Audit alle 2 Jahre — Dienstleister prüft Restore-Fähigkeit in einer realistischen Übung

Wer das durchhält, hat nicht nur eine bessere Backup-Strategie — er hat einen Nachweis, der bei jedem Audit und jedem Versicherungsfall trägt.

Verwandte DATAZONE-Artikel

• Proxmox Backup Server 4.1: Verify, Sync und Garbage-Collection
• Restic: Verschlüsselte Backups
• Ransomware 2026: Schutzmaßnahmen
• TrueNAS Datensicherheit gegen Ransomware

Fazit

Ein Backup, das nicht getestet wurde, ist keine Datensicherung — es ist eine Annahme. Der Backup-Test-Tag ist die billigste Lebensversicherung der IT, die wir kennen: Vier Mal 30 Minuten pro Quartal. Das passt in jeden Kalender. Was nicht passt, ist der Tag im November, an dem die einzige Antwort auf “können wir das Backup zurückspielen?” lautet: “Wir haben es nie probiert.”

Quellen

• BSI: Mindeststandard für Backup-Tests im IT-Grundschutz
• NIS2-Umsetzung in Deutschland (NIS2UmsuCG)
• ISO/IEC 27001:2022 Annex A.12.3
• Proxmox Backup Server: Verify Jobs und Restore-Doku