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

Jeden Morgen leuchtet das Backup-Dashboard gruen. Alle Jobs erfolgreich, keine Warnungen, keine Fehler. Der IT-Verantwortliche haakt den Punkt ab und arbeitet weiter. Ein Jahr spaeter, um 03:14 Uhr, verschluesselt eine Ransomware die File-Server. Um 09:00 Uhr steht das Team im Serverraum und stellt fest: Die Backups sind da, aber das Zurueckspielen dauert nicht die geplanten vier Stunden, sondern zweieinhalb Tage. Und die Datenbank-Wiederherstellung schlaegt fehl, weil seit acht Monaten der Log-Truncate nicht sauber lief.

Dieses Muster sehen wir in der Praxis regelmaessig. Backups werden gebaut, in Betrieb genommen und danach nicht mehr angefasst. Die eigentliche Kernfrage — laesst 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 haengen sollte.

Warum 30 Tage und warum Grandfather-Father-Son

Die reine Aufbewahrungsdauer ist keine willkuerliche 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 auffaellt, zweitens die Ransomware, die in modernen Kampagnen mehrere Tage bis Wochen im Netz sitzt, bevor der Verschluesselungs-Trigger faellt. Wer nur sieben Tage Retention hat, restauriert im schlimmsten Fall bereits kompromittierte Snapshots.

Grandfather-Father-Son (GFS) staffelt die Aufbewahrung so, dass Sie mit ueberschaubarem Speicherbedarf trotzdem tief in die Vergangenheit blicken koennen:

• Son — taegliche Backups, aufbewahrt fuer sieben Tage
• Father — woechentliche Vollbackups, aufbewahrt fuer vier bis fuenf Wochen
• Grandfather — monatliche Vollbackups, aufbewahrt fuer zwoelf Monate

Damit haben Sie fuer jeden Tag der letzten Woche einen Wiederherstellungspunkt, fuer jede Woche des letzten Monats einen, und fuer 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 laeuft die primaere Sicherung ueber Proxmox Backup Server mit einem TrueNAS SCALE als Sekundaerziel. PBS 3.x liefert die inkrementelle Deduplizierung, TrueNAS die unabhaengige zweite Instanz auf ZFS mit Snapshots. Die Rotation laesst sich in PBS ueber die Prune-Optionen sauber abbilden:

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

Der zugehoerige Sync-Job zum TrueNAS-Ziel laeuft nachts nach Abschluss der lokalen Backups. Auf dem TrueNAS greift zusaetzlich eine ZFS-Snapshot-Policy, die die Backup-Datasets selbst noch einmal versioniert und damit den PBS-Datenbestand gegen Kompromittierung des PBS selbst schuetzt. Das ist der zweite von drei Baustellen, die wir haeufig verwaist antreffen — die erste ist die fehlende Off-Site-Kopie, die dritte der Restore-Drill.

Die 3-2-1-1-0-Regel, kurz erklaert

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 ausser 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 ueberhaupt getestet wird. Ohne diesen Punkt bleibt jede Backup-Strategie ein Papiertiger.

Der quartalsweise Restore-Drill

Ein Restore-Drill ist kein DR-Test im grossen Stil, sondern eine kontrollierte, dokumentierte Wiederherstellungsuebung, die in vier Schritten ablaeuft:

1. Zufaellige Auswahl. Ein Teammitglied waehlt aus der Backup-Konsole eine VM oder ein Dataset. Nicht die “einfache”, nicht die “wichtige” — eine per Wuerfel oder Zufallsgenerator bestimmte.
2. Isolierte Wiederherstellung. Der Restore laeuft 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 geoeffnet, das ERP muss angemeldet, ein Testdokument muss versioniert und wieder geoeffnet werden. Wir dokumentieren fuer jedes System, welcher konkrete Funktionstest als “restore verified” gilt.
4. Protokollierung. Startzeit, Endzeit, gefundene Probleme, tatsaechliche RTO. Das Protokoll wandert in die Betriebsdokumentation und bildet die Grundlage fuer die naechste RTO/RPO-Matrix-Ueberarbeitung.

In einem typischen Kundenprojekt entdecken wir beim ersten Drill regelmaessig, dass die theoretische RTO um Faktor zwei bis fuenf zu optimistisch war. Ursachen sind meist: nicht gecachte Deduplizierungs-Metadaten, ueberlastete 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 geschaeftliche 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 + taegl. Full	monatlich
Fileserver Buchhaltung	1 h	4 h	Snapshots stuendlich, PBS taeglich	quartalsweise
Fileserver Marketing	24 h	24 h	PBS taeglich	quartalsweise
Terminalserver	24 h	8 h	PBS taeglich	quartalsweise
Domain Controller	24 h	1 h	PBS taeglich, zweiter DC live	halbjaehrlich
Web-Server	24 h	4 h	PBS taeglich	quartalsweise

Diese Matrix hat zwei Funktionen. Erstens zwingt sie die Geschaeftsleitung, sich zu positionieren — eine RTO von einer Stunde fuer 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 zulaessig sind, ist das ein dokumentierter Handlungsbedarf.

Typische stille Fehler

Backups, die gruen 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 Verschluesselungs-Keys bei PBS-Verschluesselung — das Chunk-Repository ist da, entpackbar aber nicht.
• NTFS-Berechtigungen werden zwar mitgesichert, bei Restore auf abweichende Domaen-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 unterstuetzt Sie

Wir bauen fuer mittelstaendische Kunden Backup-Strategien, die im Ernstfall halten — von der GFS-Rotation ueber 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 ueberhaupt restaurierbar sind, sprechen Sie uns an. Wir fuehren einen ersten kontrollierten Restore-Test mit Ihnen durch und dokumentieren die tatsaechlichen Wiederherstellungszeiten — unaufgeregt und mit belastbaren Zahlen. Details zu unserer Backup-Beratung oder direkt ueber unser Kontaktformular.