Retention‑Pläne sinnvoll umsetzen: GFS, inkrementelle Intervalle und gesetzliche Vorgaben praxisnah

Retention‑Pläne sind ein operatives Muss: Sie legen verbindlich fest, welche Backups wie lange, wo und in welcher Form aufbewahrt werden. Das Fokus‑Keyword „Retention‑Pläne“ steht gleich zu Beginn, weil die richtige Planung dieser Aufbewahrungsregeln unmittelbare Auswirkungen auf Speicher‑Budget, Restore‑Fähigkeit und Compliance hat. Dieser Beitrag richtet sich an Administratoren, System Engineers, Operatoren und technische Dienstleister und erläutert GFS‑Rotation, inkrementelle Intervalle, MariaDB‑Spezifika sowie praktische Prüf‑ und Rückfallstrategien.

Warum ein Retention‑Plan mehr ist als „ältere Backups löschen”

Ein Retention‑Plan ist eine verbindliche Betriebsregel, die auf RTO (Recovery Time Objective) und RPO (Recovery Point Objective) basiert. RTO beschreibt die maximal tolerierbare Ausfallzeit, RPO die maximal akzeptable Datenverlustspanne. Beide Kennzahlen steuern die Auswahl von Voll‑ und inkrementellen Backups, Aufbewahrungsdauern, Prüfintervallen und Reporting‑Routinen.

Für den Betrieb heißt das: verbindliche Speicherplanung, automatisierte Löschläufe mit Dry‑Run‑Modus, dokumentierte Verantwortlichkeiten und getestete Rückfallpfade, falls Löschungen oder Restore‑Tests schiefgehen. Ohne diese operativen Vereinbarungen drohen nicht entdeckte Löschfehler, Compliance‑Lücken oder unvorhergesehene Restore‑Dauern.

Retention‑Pläne operationalisieren: Rollen, Abläufe, Governance

Ein Retention‑Plan wird nur dann belastbar, wenn nicht nur Technik, sondern auch Prozesse und Verantwortlichkeiten definiert sind. Operationalisierung bedeutet konkret:

• Verantwortlichkeiten definieren: Wer autorisiert Aufbewahrungs‑Ausnahmen? Wer validiert Restore‑Tests?
• Change‑Management: Jede Änderung am Retention‑Plan durchläuft Review, Staging‑Test und Freigabe (Change‑Ticket).
• Audit‑Trail: Jede Löschung, Quarantäne‑Verschiebung oder Wiederherstellung ist protokolliert und nachweisbar.

Warum das wichtig ist: Technik allein kann falsche Löschregeln ohne menschliche Kontrolle ausführen. Governance verhindert, dass formale Aufbewahrungsfristen technisch unterschritten werden.

GFS‑Strategie (Grandfather‑Father‑Son) in der Praxis

GFS ist ein etabliertes Rotationsschema mit Jahres‑, Monats‑ und Wochenlevel. Ziel: Langzeitarchivierung bei gleichzeitig schnellem Zugriff für kurzfristige Restores. Die Stufen (Grandfather=Jährlich, Father=Monatlich, Son=Wöchentlich/Tag) ordnen sich nach Zugriffshäufigkeit und Aufbewahrungsdauer.

Praktische Hinweise:

• Nutzen Sie eindeutige Namenskonventionen (z. B. /backup/{env}/{year}/{month}/{week}) und Metadatendateien mit UUID, Erstellungszeit, Checksums und Tool‑Version.
• Planen Sie Kapazität mit konservativen Wachstumsannahmen und Reservepools.
• Dokumentieren Sie Restore‑Pfad pro GFS‑Stufe: wie viele Schritte, erwartete Dauer und Abhängigkeiten (z. B. Binlogs zur Wiederherstellung).

Inkrementelle Intervalle: Kettenlänge, RPO und Integrität

Inkrementelle Backups sparen Speicher, erhöhen aber die Restore‑Komplexität. Die Kettenlänge (Anzahl der aufeinanderfolgenden inkrementellen Schritte) ist ein zentraler Parameter: je länger die Kette, desto anfälliger für fehlerhafte Zwischenschritte.

Empfehlung: Begrenzen Sie Kettenlängen (z. B. maximal 7–14 Schritte) und erzwingen Sie danach ein Vollbackup. Ergänzen Sie dies durch sofortige Integritätsprüfungen (Checksums, xtrabackup_info Prüfung) nach jeder Sicherung. Eine zu lange Kette erhöht die Wahrscheinlichkeit, dass ein einzelner Fehler die gesamte Kette unbrauchbar macht.

Intervalle konkret planen

Ein robustes Beispiel für mittlere Änderungsraten:

• Tägliche inkrementelle Sicherungen, Aufbewahrung 14 Tage (schnelle Wiederherstellung für aktuelle Daten).
• Wöchentliches Vollbackup oder differenzielles Backup, Aufbewahrung 4 Wochen.
• Monatliches Vollbackup (Father), Aufbewahrung 12 Monate.
• Jährliches Vollbackup (Grandfather), Aufbewahrung 7–10 Jahre für gesetzlich relevante Daten.

MariaDB‑Spezifika: Binlogs, XtraBackup, LVM‑Snapshots und PITR

Für MariaDB sind Binlogs (Binary Logs) zentral: sie zeichnen alle Änderungsbefehle auf und ermöglichen Point‑In‑Time‑Recovery (PITR) sowie Replikation. Percona XtraBackup ist ein gängiges Tool für Hot‑Backups von InnoDB‑basierten Datenbanken. LVM‑Snapshots können bei großen Dateisystemen als Basis für konsistente Backups dienen, weil sie kurzzeitig einen konsistenten Dateisystem‑Stand festhalten.

Binlog‑Management: praktische Befehle, Konfiguration und Fallstricke

Wichtige SQL‑Prüfungen für Binlogs:

# Liste der vorhandenen Binlog‑Dateien und Größen
mysql -e "SHOW BINARY LOGS;"
# Aktuelle Position und Dateiname
mysql -e "SHOW MASTER STATUS;"
# Prüfen, wie weit Replikate sind
mysql -e "SHOW SLAVE STATUSG"

Konfigurationsempfehlung in my.cnf (beispielhaft):

# /etc/my.cnf.d/backup.cnf
[mysqld]
log_bin = /var/lib/mysql/mysql-bin
binlog_format = ROW
server_id = 42
# Automatisches Ablaufen von Binlogs nach 30 Tagen
binlog_expire_logs_seconds = 2592000

Wann das scheitert: Eine aggressive binlog_expire Einstellung kann PITR unmöglich machen, wenn Sie länger zurück als konfiguriert wiederherstellen müssen. Ebenso führen asynchrone Replikationsslaves mit großem Lag dazu, dass erforderliche Binlogs bereits gelöscht wurden. Abstimmungen mit Replikationsarchitektur und Restore‑Szenarien sind deshalb Pflicht.

XtraBackup: Ablauf, Prüfungen und typische Fehler

XtraBackup erzeugt ein inkrementelles/vervollständigtes Backup inklusive Metadaten. Entscheidende Prüfungen sind:

• Metadaten prüfen: xtrabackup_info und xtrabackup_checkpoints müssen vorhanden und logisch konsistent sein.
• Integrität prüfen: xtrabackup –check und ein isolierter Test‑Restore sind Standard.
• Transportschicht prüfen: Fehler beim Kopieren (z. B. rsync, scp, object upload) führen zu inkonsistenten Sicherungen.

Beispiel: Vollbackup erstellen und inkrementell ergänzen (vereinfacht):

# Vollbackup
xtrabackup --backup --target-dir=/backup/full/2026-07-01 --user=backup --password=secret
# Inkrementelles Backup
xtrabackup --backup --target-dir=/backup/inc/2026-07-02 --incremental-basedir=/backup/full/2026-07-01 --user=backup --password=secret

Vorbereitung (prepare) und Restore (vereinfachte Schritte):

# Prepare (apply logs)
xtrabackup --prepare --target-dir=/backup/full/2026-07-01
# Kopieren/Restore in Data‑Directory (in Wartungsfenster)
systemctl stop mariadb
rsync -a /backup/full/2026-07-01/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

Wenn prepare fehlschlägt (z. B. wegen fehlender Incremental‑Teile), dann ist eine Wiederherstellung nur bis zum letzten intakten Punkt möglich. Planen Sie daher regelmäßige Vollbackups und zusätzlich Test‑Restores in einer isolierten Umgebung.

Binlog‑Wiedereinspielung mit mysqlbinlog

Für PITR spielen Sie Binlogs bis zum gewünschten Zeitpunkt ein. Wichtiger Hinweis: mysqlbinlog erzeugt SQL‑Statements, die Sie in einer Testumgebung prüfen sollten.

# Binlog bis zu einem Zeitpunkt erzeugen
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.000123 | mysql -u root -p
# Alternativ: aus mehreren Dateien
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.00012* | mysql -u root -p

Gefährlich ist das automatische Einspielen ohne Prüfung: umfangreiche Transaktionen oder DDLs können Produktionszustände verändern. Führen Sie mysqlbinlog idealerweise in einer isolierten Datenbankinstanz vorab aus und prüfen Sie Größe und erwartete Laufzeit.

Automatisierung: Scheduler, Validierung und Dry‑Run

Automatisierte Jobs sollten idempotent, nachvollziehbar und sicher sein. Cron ist weit verbreitet; systemd‑Timer bietet bessere Sichtbarkeit und Restart‑Policy. Ein Beispiel für einen systemd‑Timer und Service zur täglichen Validierung:

# /etc/systemd/system/backup-validate.service
[Unit]
Description=Backup Validation Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/validate-backup.sh

# /etc/systemd/system/backup-validate.timer
[Unit]
Description=Run backup validation daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Das Validierungsskript sollte Exit‑Codes definieren (0=OK, 1=Warnung, 2=Fehler) und strukturierte Logs in JSON schreiben, damit Monitoring‑Systeme (z. B. Prometheus Pushgateway, ELK) Alerts erzeugen können.

Objekt‑Storage und Lifecycle Policies (S3‑kompatibel)

Für langfristige Aufbewahrung bietet Objektstorage Kostenvorteile. Nutzen Sie Lifecycle‑Regeln, um Objekte zu Glacier‑ähnlichen Tiers zu verschieben. Ein Lifecycle‑Beispiel (JSON) für S3‑kompatible Bucket‑Regeln:

{
  "Rules": [
    {
      "ID": "move-to-cold",
      "Filter": {"Prefix": "backup/old/"},
      "Status": "Enabled",
      "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}],
      "Expiration": {"Days": 3650}
    }
  ]
}

Wichtig: Aktivieren Sie Object Lock (WORM) nur für Daten, die rechtlich unveränderbar sein müssen. Lifecycle‑Regeln dürfen nicht ohne menschliche Freigabe automatisch gesetzlich relevante Kopien löschen.

Risikobetrachtung: Ransomware, Datenkorruption und Operatorfehler

Retention‑Pläne müssen Risiko‑Szenarien antizipieren. Ransomware versucht häufig, alle Kopien zu verschlüsseln oder zu löschen. Maßnahmen:

• Immutable Storage oder Object Lock für kritische Backups.
• Separate Admin‑Konten für Backup‑Systeme, MFA, und eingeschränkte Netzwerke für Backup‑Zugriffe.
• Quarantäne‑Buckets und verzögerte Löschung (z. B. 7–14 Tage), um versehentliche oder böswillige Löschungen auffangen zu können.

Bei Datenkorruption helfen Checksums, sofortige Alarmierung und die Möglichkeit, auf ältere GFS‑Stufen zuzugreifen.

Rollback‑Strategie und Recovery‑Runbook

Ein robustes Runbook listet konkrete, getestete Schritte für einen Restore und ein mögliches Rollback. Wichtige Elemente:

1. Initiale Lageeinschätzung: betroffene Systeme, RTO/RPO, betroffene Datenklassen.
2. Auswahl der Wiederherstellungsquelle: vollständige Sicherung, Replikat oder Offsite‑Kopie.
3. Test‑Restore in Isolierung und Verifikation der Integrität (Checksums, Anwendungs‑Smoke‑Tests).
4. Produktiv‑Restore in Wartungsfenster mit Kommunikationsplan (Stakeholder‑Benachrichtigung, Nutzerinfos).
5. Post‑Restore‑Audit: Vergleich von Datensätzen, Konsistenzprüfungen und Lessons Learned‑Dokumentation.

Definieren Sie klare Entscheidungsstufen: Wer entscheidet bei fehlschlagenden Restores? Wann wird auf alternative Quellen (z. B. Replikat) gewechselt?

Tests und Audit: Wie oft und mit welchen Akzeptanzkriterien?

Testfrequenz: schnelle Restore‑Proben (wöchentlich), vollständige Restore‑Durchläufe (monatlich) und Desaster‑Simulationen (jährlich). Akzeptanzkriterien müssen messbar sein, z. B. „Vollrestore eines DB‑Schemas in < 4 Stunden“ oder „PITR bis maximal 15 Minuten RPO“. Dokumentieren Sie Abweichungen und Ursachen.

Typische Stolperfallen und wie Sie sie vermeiden

• Fehlende Metadaten: Bewahren Sie xtrabackup_info und checksums zusammen mit den Daten auf.
• Automatische Löschregeln ohne Dry‑Run: immer Dry‑Run und Quarantänephase einführen.
• Ungetestete Lifecycle Policies: Testen Sie Migrationen in einer Staging‑Bucket‑Umgebung.
• Binlog‑Löschung ohne Abgleich mit Replikaten: prüfen Sie Replikations‑Lag und SLAs, bevor Sie binlogs verwerfen.
• Keine Kapazitätsreserve: planen Sie für Spitzen, nicht nur für Mittelwerte.

Checkliste zur Einführung eines Retention‑Plans (Praxis)

1. Erfassen: Welche Datenklassen sind relevant und welche rechtlichen Fristen gelten?
2. Klassifizieren: RTO/RPO pro Datenklasse definieren und dokumentieren.
3. Design: GFS‑Schema, inkrementelle Intervalle, Storage‑Tiers, Object Lock und Quarantäne festlegen.
4. Automatisierung: Idempotente Skripte, Dry‑Run, systemd‑Timer, strukturierte Logs und Alarme implementieren.
5. Validierung: Regelmäßige Restore‑Tests, Integritätsprüfungen und Reporting einführen.
6. Dokumentation: Retention‑Policy als verbindliches Dokument inkl. Rollen und Audit‑Trail.
7. Review: Periodische Überprüfung (z. B. halbjährlich) und Aktualisierung bei geänderten rechtlichen Vorgaben.

Fazit: Operative Robustheit schaffen

Retention‑Pläne verbinden Compliance, Wirtschaftlichkeit und Betriebssicherheit. Praktisch heißt das: GFS für Langzeitbedarf, begrenzte inkrementelle Ketten für Effizienz, automatisierte Integritätsprüfungen und dokumentierte Restore‑Proben für Verlässlichkeit. Für MariaDB sind zusätzlich Binlog‑Management, XtraBackup‑Chain‑Integrität und regelmäßige PITR‑Tests Schlüsselthemen. Testen Sie Änderungen in Staging, halten Sie Löschoperationen reversibel bis zur finalen Verifikation und betreiben Sie Monitoring mit klaren Alarmen.

Wenn Sie diese Schritte einhalten, wird Ihr Retention‑Plan kein einmaliges Dokument, sondern ein lebender Betriebsprozess: automatisiert, prüfbar und rechtssicher. So schützen Sie Ihre Daten und stellen gleichzeitig wirtschaftliche Aufbewahrung sicher.

Weiterführende Ressourcen

Interne Links zu vertiefenden Beiträgen (z. B. Backup‑Tests mit Ansible, Ransomware‑Resilienz, MariaDB PITR) sollten hier eingebunden werden, damit Runbooks, Playbooks und Audit‑Checklisten direkt erreichbar sind.

Retention‑Management: Metadaten, Legal‑Hold und Monitoring

Ein oft unterschätzter Teil der Retention ist der Metadaten‑Katalog: Er dokumentiert, welche Backup‑Batches zu welchen Datenklassen, rechtlichen Fristen, Prüfergebnissen und Verschlüsselungs‑Schlüsseln gehören. Ohne einen zuverlässigen Katalog wird Löschautomation gefährlich — weil das System nicht sicher unterscheiden kann, welche Kopie noch unter Legal‑Hold steht oder für eine laufende Prüfung relevant ist.

Architekturhinweis: Trennen Sie das Metadaten‑Repository von den Objekt‑Stores. Verwenden Sie eine kleine, hochverfügbare Datenbank (z. B. ein einzelnes schema‑gesichertes MariaDB‑Schema oder ein dokumentenorientierter Store) mit versionierten Einträgen. Jeder Backup‑Batch bekommt eine UUID, Status (available, quarantined, deleting, deleted), owner und legal_hold_flag. Diese Infos steuern die Löschpipeline.

Zwei‑Phasen‑Löschung reduziert Risiko: 1) Tombstone setzen + Quarantäne (z. B. 7–14 Tage), 2) nach erfolgreichem Reconcile und Audit endgültig löschen. Das erlaubt Dry‑Run, manuelle Eingriffe und automatisierte Rücksetzungen bei Fehlern.

Operationales Monitoring sollte messbare Kennzahlen liefern:

• Prozentuale Retention‑Compliance (Soll vs. Ist nach Fristen)
• Anzahl Tombstones und Alter der Tombstones
• Löschfehler pro Tag und Zeit bis zur manuellen Auflösung
• Diskrepanz zwischen Metadaten und tatsächlichem Storage (Reconcile‑Rate)

Beispielabfrage (Metadatentabelle backups):

-- Backups, die laut Policy bereits gelöscht sein sollten
SELECT id, uuid, created_at, retention_until, status
FROM backups
WHERE retention_until < NOW() AND status != 'deleted';
-- Tombstones älter als 14 Tage
SELECT COUNT(*) FROM backups WHERE status = 'quarantined' AND updated_at < NOW() - INTERVAL 14 DAY;

Weitere Punkte: Schlüsselverwaltung (KMS) für verschlüsselte Backups separat und mit RBAC betreuen; Versionsnummern für Backup‑Tools einführen und bei Migrationen Kompatibilitätsprüfungen durchführen. Schließlich: integrieren Sie Reconcile‑Jobs in Ihr Incident‑Runbook — automatische Benachrichtigung plus eskalierende Pager‑Prozedur, wenn Reconcile‑Rate eine niedrige Schwelle unterschreitet.

Für dieses Thema sind auch Mariadb Backups und Binlog Retention wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.