Backup-Praxis: 30-Tage-Rotation und der Restore-Drill

Jeden Morgen leuchtet das Backup-Dashboard grün. Alle Jobs erfolgreich, keine Warnungen, keine Fehler. Der IT-Verantwortliche hakt den Punkt ab und arbeitet weiter. Ein Jahr später, um 03:14 Uhr, verschlüsselt eine Ransomware die File-Server. Um 09:00 Uhr steht das Team im Serverraum und stellt fest: Die Backups sind da, aber das Zurückspielen dauert nicht die geplanten vier Stunden, sondern zweieinhalb Tage. Und die Datenbank-Wiederherstellung schlägt fehl, weil seit acht Monaten der Log-Truncate nicht sauber lief.

Dieses Muster sehen wir in der Praxis regelmäßig. Backups werden gebaut, in Betrieb genommen und danach nicht mehr angefasst. Die eigentliche Kernfrage — lässt sich der Betrieb im Ernstfall wirklich in der versprochenen Zeit wiederherstellen — wird nie gestellt. In diesem Beitrag beschreiben wir eine belastbare 30-Tage-Rotation nach dem Grandfather-Father-Son-Prinzip, den quartalsweisen Restore-Drill und die RTO/RPO-Matrix, die im Rechenzentrum an der Wand hängen sollte.

Warum 30 Tage und warum Grandfather-Father-Son

Die reine Aufbewahrungsdauer ist keine willkürliche Zahl. 30 Tage sind in der SMB-Praxis das Minimum, mit dem sich zwei typische Bedrohungsszenarien abdecken lassen: erstens die schleichende Datenkorruption, die oft erst nach zwei bis drei Wochen auffällt, zweitens die Ransomware, die in modernen Kampagnen mehrere Tage bis Wochen im Netz sitzt, bevor der Verschlüsselungs-Trigger fällt. Wer nur sieben Tage Retention hat, restauriert im schlimmsten Fall bereits kompromittierte Snapshots.

Grandfather-Father-Son (GFS) staffelt die Aufbewahrung so, dass Sie mit überschaubarem Speicherbedarf trotzdem tief in die Vergangenheit blicken können:

• Son — tägliche Backups, aufbewahrt für sieben Tage
• Father — wöchentliche Vollbackups, aufbewahrt für vier bis fünf Wochen
• Grandfather — monatliche Vollbackups, aufbewahrt für zwölf Monate

Damit haben Sie für jeden Tag der letzten Woche einen Wiederherstellungspunkt, für jede Woche des letzten Monats einen, und für jeden Monat des letzten Jahres einen. Der Speicherbedarf steigt dabei nicht linear, sondern degressiv, wenn Sie sinnvoll deduplizieren.

Beispielrotation mit Proxmox Backup Server und TrueNAS

In den meisten unserer Projekte läuft die primäre Sicherung über Proxmox Backup Server mit einem TrueNAS SCALE als Sekundärziel. PBS 3.x liefert die inkrementelle Deduplizierung, TrueNAS die unabhängige zweite Instanz auf ZFS mit Snapshots. Die Rotation lässt sich in PBS über die Prune-Optionen sauber abbilden:

keep-last: 7
keep-weekly: 5
keep-monthly: 12
keep-yearly: 3

Der zugehörige Sync-Job zum TrueNAS-Ziel läuft nachts nach Abschluss der lokalen Backups. Auf dem TrueNAS greift zusätzlich eine ZFS-Snapshot-Policy, die die Backup-Datasets selbst noch einmal versioniert und damit den PBS-Datenbestand gegen Kompromittierung des PBS selbst schützt. Das ist der zweite von drei Baustellen, die wir häufig verwaist antreffen — die erste ist die fehlende Off-Site-Kopie, die dritte der Restore-Drill.

Die 3-2-1-1-0-Regel, kurz erklärt

Die klassische 3-2-1-Regel wurde in der aktuellen Bedrohungslage erweitert. Wir arbeiten mit 3-2-1-1-0:

• 3 Kopien der Daten, inklusive Original
• 2 unterschiedliche Speichermedien
• 1 Kopie außer Haus
• 1 Kopie offline oder immutable (Air-Gap oder S3 Object Lock)
• 0 Fehler im letzten Restore-Test

Die letzte Ziffer ist die entscheidende. Sie erzwingt, dass überhaupt getestet wird. Ohne diesen Punkt bleibt jede Backup-Strategie ein Papiertiger.

Der quartalsweise Restore-Drill

Ein Restore-Drill ist kein DR-Test im großen Stil, sondern eine kontrollierte, dokumentierte Wiederherstellungsübung, die in vier Schritten abläuft:

1. Zufällige Auswahl. Ein Teammitglied wählt aus der Backup-Konsole eine VM oder ein Dataset. Nicht die “einfache”, nicht die “wichtige” — eine per Würfel oder Zufallsgenerator bestimmte.
2. Isolierte Wiederherstellung. Der Restore läuft auf einen separaten Proxmox-Host oder in ein isoliertes VLAN, damit die produktive Umgebung nicht beeinflusst wird und eventuell mitgesicherte Schadsoftware nicht aktiv wird.
3. Verifikation auf Anwendungsebene. Es reicht nicht, dass die VM bootet. Die Datenbank muss geöffnet, das ERP muss angemeldet, ein Testdokument muss versioniert und wieder geöffnet werden. Wir dokumentieren für jedes System, welcher konkrete Funktionstest als “restore verified” gilt.
4. Protokollierung. Startzeit, Endzeit, gefundene Probleme, tatsächliche RTO. Das Protokoll wandert in die Betriebsdokumentation und bildet die Grundlage für die nächste RTO/RPO-Matrix-Überarbeitung.

In einem typischen Kundenprojekt entdecken wir beim ersten Drill regelmäßig, dass die theoretische RTO um Faktor zwei bis fünf zu optimistisch war. Ursachen sind meist: nicht gecachte Deduplizierungs-Metadaten, überlastete 1-GbE-Anbindung des Sicherungsziels, oder ein simples Fehlen der Wiederherstellungs-Runbooks in Griffweite des diensthabenden Kollegen.

Die RTO/RPO-Matrix

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind keine Backup-Software-Einstellungen, sondern geschäftliche Zielvorgaben. Die Matrix sollte pro System explizit ausgewiesen sein:

System	RPO (max. Datenverlust)	RTO (max. Ausfallzeit)	Backup-Frequenz	Testzyklus
ERP-Datenbank	15 min	2 h	Log-Shipping alle 15 min + tägl. Full	monatlich
Fileserver Buchhaltung	1 h	4 h	Snapshots stündlich, PBS täglich	quartalsweise
Fileserver Marketing	24 h	24 h	PBS täglich	quartalsweise
Terminalserver	24 h	8 h	PBS täglich	quartalsweise
Domain Controller	24 h	1 h	PBS täglich, zweiter DC live	halbjährlich
Web-Server	24 h	4 h	PBS täglich	quartalsweise

Diese Matrix hat zwei Funktionen. Erstens zwingt sie die Geschäftsleitung, sich zu positionieren — eine RTO von einer Stunde für den Fileserver hat einen ganz anderen Preisschild als 24 Stunden. Zweitens macht sie die IT auditierbar. Wenn der ERP-Restore beim Drill vier Stunden dauert, aber laut Matrix zwei Stunden zulässig sind, ist das ein dokumentierter Handlungsbedarf.

Typische stille Fehler

Backups, die grün laufen aber im Restore scheitern, folgen einer Handvoll wiederkehrender Muster:

• VSS-Fehler bei laufenden SQL-Diensten ohne saubere Log-Freigabe — Backup meldet “OK”, Datenbank ist im Restore inkonsistent.
• Fehlende oder abgelaufene Verschlüsselungs-Keys bei PBS-Verschlüsselung — das Chunk-Repository ist da, entpackbar aber nicht.
• NTFS-Berechtigungen werden zwar mitgesichert, bei Restore auf abweichende Domänen-SID aber unbrauchbar.
• Application-Server mit hardcodierten IPs, die nach Restore in isoliertes VLAN keine externen Ressourcen finden und die Verifikation blockieren.
• Bandwidth-Throttling in der Sicherungssoftware, das im Regelbetrieb passt, den Restore aber unbrauchbar verlangsamt.

Alle diese Fehler werden nicht durch das Monitoring der Backup-Software gefunden, sondern nur durch den echten Restore.

DATAZONE unterstützt Sie

Wir bauen für mittelständische Kunden Backup-Strategien, die im Ernstfall halten — von der GFS-Rotation über die 3-2-1-1-0-Umsetzung bis zum protokollierten quartalsweisen Restore-Drill inklusive RTO/RPO-Matrix. Wenn Sie unsicher sind, ob Ihre aktuellen Sicherungen überhaupt restaurierbar sind, sprechen Sie uns an. Wir führen einen ersten kontrollierten Restore-Test mit Ihnen durch und dokumentieren die tatsächlichen Wiederherstellungszeiten — unaufgeregt und mit belastbaren Zahlen. Details zu unserer Backup-Beratung oder direkt über unser Kontaktformular.