Backup-Wartung operationalisieren: Job-Lifecycle, Storage-Quotas und automatisches Cleanup

Viele Teams richten Backups ein – und verlassen sich dann auf „es läuft“. Backup-Wartung operationalisieren heißt, den laufenden Betrieb so zu gestalten, dass Backups dauerhaft verlässlich, prüfbar und wiederherstellbar bleiben. Das bedeutet: ein klares Job-Lifecycle-Modell, harte, aber sinnvolle Storage-Quotas und ein automatisches Cleanup mit Guardrails, Audit und Rückfalloptionen. Dieser Leitfaden richtet sich an Administratoren, System Engineers, Operatoren und technische IT-Dienstleister und liefert praktische Prüfungen, typische Stolperfallen, Umsetzungsschritte, Automatisierungsbeispiele und Notfall-Runbooks.

Weshalb Backups im Betrieb scheitern

Backups zeigen oft erst später Fehler: ein grünes Abschluss-Flag kann unvollständige Daten verbergen, ein volles Repository schlägt beim Restore zurück, und inkorrekte Retention zerstört die Point-in-Time-Fähigkeit. Zwei zentrale Betriebsgrößen sind RPO (Recovery Point Objective: maximaler Datenverlust in Zeit) und RTO (Recovery Time Objective: maximale Wiederanlaufzeit). Operationalisieren bedeutet, diese Ziele dauerhaft einhalten zu können – nicht nur beim Initialsetup.

Backup-Wartung operationalisieren: Job-Lifecycle als Grundlage

Ein Job-Lifecycle ist kein Nice-to-have: Er definiert Zustände, aus denen automatisierte Entscheidungen (z. B. Löschen) sicher getroffen werden können. Eine klar definierte Zustandsmaschine reduziert Unsicherheit in Cleanup-Prozessen und macht Automatisierung auditierbar.

Zustandsmodell und pragmatische Erweiterungen

• Scheduled: geplant, noch nicht gestartet.
• Running: aktiv, mit Lock und Timeout; verhindert parallele Writes.
• Succeeded: vollständig geschrieben, Verifikation (Checksummen, Manifest) bestanden.
• Succeeded with warnings: Abschluss mit Problemen in Teilobjekten (z. B. fehlende Inkremente).
• Failed: fehlgeschlagen, mit Fehlerklasse (Auth, I/O, Netzwerk).
• Stale/Orphaned: Job ohne aktiven Prozess gefunden, Locking fehlgeschlagen oder Zombie-Objekte.
• Expired: Retention abgelaufen; Kandidat für Markierung.
• Marked-for-Purge: Soft-delete, noch reaktivierbar innerhalb Sperrzeit.
• Purged: endgültig gelöscht.
• Hold: Aufbewahrungssperre (Compliance, Incident).

Operativ heißt das: Purge darf nur Objekte betreffen, die den Status Marked-for-Purge haben, nicht auf Hold stehen und deren Integrität geprüft wurde. Logging der Übergänge (wer, wann, warum) ist Pflicht.

Vorsorge gegen typische Fallen

• Uneindeutige Erfolgskriterien: Definieren Sie explizit, welche Checks ein Succeeded erlauben (Manifest, Checksummen, Objekt-Zeiten).
• Kein Locking: Verwenden Sie Datei-Locks, DB-Locks oder Objekt-Metadaten, um parallel laufende Jobs auszuschließen.
• Fehlende Timeouts: Hängende Jobs blockieren Fenster — Timeouts mit Neustart- oder Alert-Logik sind notwendig.
• Unsichtbare Zustände: Integrieren Sie Zustandsmetriken ins Monitoring (z. B. Prometheus-Gauges für Job-Zustände).

Storage-Quotas: Kapazität als Betriebssicherheitsgrenze

Quotas sind mehr als Budgetsteuerung: Sie schützen vor plötzlichem Repository-Ausfall. Wichtige Ebenen sind Repository-Quota (Volume, Bucket), Tenant-Quota (bei mehreren Kunden/Mandanten) und Job-/Dataset-Quota (z. B. pro VM oder Datenbank).

Metriken und Headroom-Regeln

Monitoring sollte mindestens folgende Metriken liefern: aktuelle Belegung (GiB/TiB), freie Inodes (bei vielen kleinen Dateien), tägliche Wachstumsgeschwindigkeit (GiB/Tag) und der größte geplante Job. Eine einfache Headroom-Regel lautet: freier Platz ≥ größter Job + 20 % Puffer für Metadaten und Indexing.

Checkskript für Basischecks

#!/usr/bin/env bash
set -euo pipefail
TARGET_MOUNT="/backup"

echo "== Capacity =="
df -hP "$TARGET_MOUNT"

echo "== Inodes =="
df -hiP "$TARGET_MOUNT"

# Simple largest-file check
echo "== Largest files (top 10) =="
find "$TARGET_MOUNT" -type f -printf '%s %pn' | sort -nr | head -n 10 | awk '{printf "%.2f GiBt%sn", $1/1024/1024/1024, $2}'

Inodes werden häufig übersehen und führen bei vielen kleinen Backup-Chunks zu ‚Filesystem full‘-Fehlern, obwohl Platz vorhanden ist.

Automatisches Cleanup: Designprinzipien und Beispiele

Ein robustes Cleanup berücksichtigt Metadaten, Abhängigkeiten und Betriebsbedingungen. Wichtig sind Zwei-Phasen-Löschung (Soft-delete und anschließendes Purge), Dry-Run-Möglichkeiten, Guardrails (z. B. Max-Delete-Volumen pro Lauf) und Canary-Rollout.

Systemd-Timer: Beispiel für gesteuertes Cleanup

Ein sauberer Weg, periodische Cleanup-Jobs zu betreiben, sind systemd-timers. Hier ein Beispielunit + timer, das ein Cleanup-Skript in einer sicheren Umgebung startet:

# /etc/systemd/system/backup-cleanup.service
[Unit]
Description=Backup Cleanup Service
After=network.target

[Service]
Type=oneshot
User=backup
Group=backup
ExecStart=/usr/local/bin/backup-cleanup.sh --dry-run

# /etc/systemd/system/backup-cleanup.timer
[Unit]
Description=Run backup cleanup daily at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Der Timer startet im Dry-Run-Modus; bei erfolgreichem Dry-Run folgt ein manuelles oder canarybasiertes Aktivieren der echten Purge-Ausführung.

Dry-Run und Guardrails: Bash-Beispiel (erweitert)

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/backup/jobs"
RETENTION_DAYS=30
MAX_DELETE_GIB=200
DRY_RUN=1

mapfile -d '' CANDIDATES <<(find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -print0)
if [[ ${#CANDIDATES[@]} -eq 0 ]]; then echo "No candidates older than ${RETENTION_DAYS} days."; exit 0; fi

TOTAL_BYTES=0
for f in "${CANDIDATES[@]}"; do
  if [[ -f "$f" ]]; then
    b=$(stat -c%s "$f")
    TOTAL_BYTES=$((TOTAL_BYTES + b))
  fi
done
TOTAL_GIB=$(awk -v b="$TOTAL_BYTES" 'BEGIN { printf "%.2f", b/1024/1024/1024 }')

echo "Candidates: ${#CANDIDATES[@]} files, approx ${TOTAL_GIB} GiB"
if (( $(echo "$TOTAL_GIB > $MAX_DELETE_GIB" | bc -l) )); then
  echo "Guardrail triggered: candidates exceed ${MAX_DELETE_GIB} GiB. Aborting."; exit 2
fi

if [[ "$DRY_RUN" -eq 1 ]]; then
  printf '%sn' "${CANDIDATES[@]}" | head -n 100
  echo "DRY_RUN enabled: nothing deleted."
  exit 0
fi

for f in "${CANDIDATES[@]}"; do rm -f -- "$f"; done

echo "Deleted ${#CANDIDATES[@]} files."

Wichtig: Verwenden Sie solche Skripte nie ungeprüft für Datenbank-Backups ohne zusätzliche Abhängigkeitsprüfung (z. B. Binlogs vs Full-Backups).

MySQL-spezifische Praxis: Binlogs, Full-Backups und PITR

Bei MySQL hängt Wiederherstellbarkeit oft von einem Full-Backup plus Binlogs (Binary Logs) ab. Binlogs sind das Transaktionsprotokoll, das Point-in-Time-Recovery (PITR) ermöglicht. Ein inkonsistentes oder zu frühes Löschen von Binlogs macht PITR unmöglich, selbst wenn Full-Backups vorhanden sind.

Wichtige Betriebsregeln und Automatismen

• Koppeln Sie Binlog-Retention an Full-Backup-Intervall plus Sicherheitsmarge (z. B. 1,5× Intervall).
• Führen Sie auf dem Backup-Server einen Manifest-Store, der für jedes Full-Backup die erste und letzte Binlog-Position oder GTID dokumentiert.
• Setzen Sie automatische Alerts, wenn die ältesten verfügbaren Binlogs jünger sind als der älteste benötigte Full-Backup-Anker.

Prüf- und Diagnosebefehle

-- Aktuelle Binlogs
SHOW BINARY LOGS;

-- Aufbewahrungsrichtlinie
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW VARIABLES LIKE 'expire_logs_days';

-- GTID Status
SHOW GLOBAL VARIABLES LIKE 'gtid_mode';
SHOW MASTER STATUS; -- zeigt aktuelle Position

Zum Ausspielen von Binlogs bei einem Restore kann mysqlbinlog genutzt werden. Beispiel: Full-Backup zurückspielen und danach Binlogs bis zu einem Zeitpunkt anwenden.

# Full-Backup zurückspielen (Beispiel mit mysql-client)
mysql -u root -p < /backups/full-2026-07-01.sql

# Binlogs bis zu einem Zeitpunkt ausspielen
mysqlbinlog --start-position=123 --stop-datetime='2026-07-10 14:30:00' /var/lib/mysql/binlog.000123 | mysql -u root -p

Erklärt: mysqlbinlog liest Binlog-Dateien; die Optionen --start-position und --stop-datetime begrenzen den Bereich. Bei GTID-basierten Setups nutzen Sie GTID-Anker statt Positionen.

Automatische Binlog-Archivier-Strategie (Best-Practice)

Statt Binlogs lokal zeitbasiert zu löschen, archivieren Sie Binlogs sofort nach Rollout an ein separates Backup-Repository (Object Storage, Tape). Erst wenn ein Full-Backup den Anker dokumentiert und die Binlogs erfolgreich archiviert sind, markiert das System lokale Binlogs für Purge.

Monitoring, Alerting und KPIs

Operationalisierte Backup-Wartung braucht Metriken, konkrete Schwellen und Eskalationspfade. Wichtige KPIs:

• Job Success Rate (letzte 7/30 Tage)
• Time-to-Restore (gemessene RTO in Drills)
• Coverage für RPO (Existenz von passenden Binlogs/Incrementals)
• Repository Headroom (GiB frei vs größter Job)
• Number of Marked-for-Purge objects

Prometheus-Alert-Beispiel: Repo unter 15 % freiem Platz:

groups:
- name: backup.rules
  rules:
  - alert: BackupRepositoryLowSpace
    expr: (backup_repo_free_percent < 15)
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Backup repository low space"
      description: "Das Backup-Repository hat weniger als 15% freien Speicher für mehr als 10 Minuten."

Audit, RBAC und Compliance-Holds

Auditierbarkeit ist zentral: Wer hat ein Objekt markiert/unmarked/gelöscht? Speichern Sie Aktionen in einem unveränderbaren Audit-Log (Append-only), idealerweise außerhalb des Backup-Targets. Für Holds benötigen Sie RBAC: Nur autorisierte Rollen dürfen Holds setzen/entfernen.

Restore-Validierung automatisieren

Regelmäßige Restore-Drills sind der einzige Weg, Vertrauen zu schaffen. Automatisieren Sie einfache Wiederherstellungen (Smoke-Restore) für kritische Datenquellen und anspruchsvollere Tests (PITR) für MySQL. Dokumentieren Sie RTO und RPO pro Drill und heben Sie Abweichungen hervor.

Beispiel: Automatisierter MySQL-PITR-Test

1. Stellen Sie einen isolierten MySQL-Testserver bereit (Container oder VM).
2. Restaurieren Sie das Full-Backup.
3. Wenden Sie archivierte Binlogs bis zu einem definierten Zeitpunkt an.
4. Führen Sie Smoke-Queries und Konsistenzprüfungen aus (Rowcounts, Checksummen).

# Beispiel-Pipeline (sketch)
# 1. spin up test server
# 2. restore full
mysql -u root -p -h testserver < /archives/full-latest.sql
# 3. apply binlogs
for f in /archives/binlogs/binlog.*; do mysqlbinlog "$f" | mysql -u root -p -h testserver; done
# 4. run smoke tests (SQL oder application-level)
mysql -u root -p -h testserver -e "SELECT COUNT(*) FROM important_table;"

Rückfallstrategien bei Fehl-Purges

Falls Cleanup zuviel löscht, helfen folgende Strategien:

• Zwei-Phasen-Löschung: Reaktivierung markierter Stände innerhalb Sperrzeit.
• Object-Storage-Versioning: Delete-Marker statt endgültigem Entfernen; Wiederherstellung möglich, aber zeitaufwendig.
• Air-Gap-Kopien: Separater Offline-Standort als letzte Rettungsleine.
• Notfallsupport-Prozedur: Sofortiger Incident-Mode (globaler Hold) und manuelle Wiederherstellungspriorisierung.

Deployment-Plan: 30–60 Tage Checklist

• Job-Lifecycle spezifizieren, Implementierung von Timeouts und Lock-Mechanismen.
• Monitoring mappen: Metriken definieren, Alerts konfigurieren und Eskalationspfade festlegen.
• Quotas anlegen: Repo/Tenant/Dataset, plus Growth-Rate-Alerts.
• Cleanup implementieren: Zwei-Phasen, Dry-Run, Guardrails, Canary.
• MySQL: Full- und Binlog-Policy dokumentieren, Archivierung sicherstellen, PITR testen.
• Audit & RBAC: Aktion-Logging, Approval-Workflow für Holds und Purges.
• Restore-Drills automatisieren und KPI-Reporting einführen.

Fazit

Backup-Wartung operationalisieren bedeutet, Backups als Plattform zu betreiben: strukturierte Job-Zustände, harte Quotas als Sicherheitsgrenze und ein automatisiertes, aber geprüftes Cleanup mit Rückfahroptionen. Besonders datenbanknahe Umgebungen wie MySQL erfordern enge Abstimmung von Full-Backups, Binlog-Archivierung und PITR-Tests — falsches Cleanup hier zerstört Wiederherstellungsfähigkeit. Mit Runbooks, Messwerten, Guardrails und regelmäßigen Restore-Drills machen Sie Backups widerstandsfähig und auditierbar. Planen Sie Zeit für Validierung und üben Sie Wiederherstellungen: nur getestete Backups sind verlässliche Backups.

Backup-Wartung operationalisieren: Control-Plane, Data-Plane und Integrationshinweise

Ein oft unterschätzter Teil der Operationalisierung ist die klare Trennung zwischen Control-Plane (Metadaten, Job‑Zustände, Audit, Quotas) und Data‑Plane (Objekt- oder Block-Storage, Binlog-Archive). Diese Trennung macht Prozesse berechenbar, erlaubt sichere Rollbacks und reduziert Blast‑Radius bei Fehlern.

Architekturhinweise

• Control-Plane in einer relationalen Datenbank betreiben (z. B. PostgreSQL) mit Transaktionen für atomare Zustandsübergänge; Metadaten sollten nicht im Objektstore alleine stehen.
• Data-Plane ist das Objekt- oder Block-Storage. Dort liegen die eigentlichen Backup-Artefakte; nutzen Sie objektseitige Features (Tags, Versioning, Lifecycle) als zusätzliche Schutzschicht.
• Leader-Election für Cleanup‑Tasks: Verhindern Sie parallele Purge‑Läufe über eine einfache Locking‑Strategie (DB-Locks, etcd, Redlock) statt ad-hoc-Dateilocking.
• Idempotente Operationen: Jede Cleanup‑Aktion muss wiederholbar ohne Seiteneffekte sein; nutzen Sie markierte Zustände statt sofortiger Löschung.

Integrationsdetails und Fallstricke

Bei Cloud‑Object‑Stores beachten Sie Eventual-Consistency: Listen-Operationen sind nicht immer sofort aktuell. Verlassen Sie sich für kritische Entscheidungen auf manifestierte Metadaten in der Control‑Plane, nicht allein auf das Ergebnis eines List-Calls. API‑Rate‑Limits und Throttling können Cleanup‑Jobs abbrechen; bauen Sie Backoff‑Strategien und Max‑Delete‑Limits pro Lauf ein.

Wenn Ihre Umgebung sowohl agentenbasierte als auch agentenlose Backups nutzt, modellieren Sie Abhängigkeiten explizit: Ein Snapshot eines Storage‑Arrays kann mehrere Datenbank‑Backups ersetzen; Cleanup muss diese Konsistenzgruppen erkennen.

Key‑Management und Verschlüsselung

Verwalten Sie Verschlüsselungsschlüssel zentral (Cloud KMS, HashiCorp Vault). Nutzen Sie Envelope‑Encryption: Daten werden mit einem Data Encryption Key (DEK) verschlüsselt, der wiederum mit einem Key Encryption Key (KEK) geschützt wird. Dokumentieren Sie Schlüsselrotation und Recovery‑Pfad; fehlender KEK macht Archive unwiederbringlich.

Beispiel: einfaches Retention‑Manifest (YAML)

# manifest.yaml
full_backup_id: fb-2026-07-01
binlog_range:
  first_binlog: mysql-bin.000123
  last_binlog: mysql-bin.000130
retention_days: 90
hold: false
archived: true
archive_location: s3://backup-archive/mysql/2026-07-01/

Das Manifest wird in der Control‑Plane gespeichert und referenziert die Data‑Plane‑Objekte. Cleanup‑Jobs prüfen das Manifest auf „archived“ und „hold“ bevor sie lokales Löschen auslösen.

Zusammengefasst: Designen Sie Backup‑Prozesse mit klarer Verantwortlichkeit zwischen Metadaten und Daten, machen Sie Cleanup idempotent und durch Leader‑Election serialisierbar, und schützen Sie Archive mit Key‑Management sowie Objekt‑Versioning. Diese Maßnahmen reduzieren Risiko, erleichtern Audits und machen Ihre Backup‑Wartung skalierbar für individuelle Unternehmenssoftware und heterogene Infrastrukturen.

Für dieses Thema sind auch Backup Job Lifecycle und Retention-Policy wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.