# Backup Policies: Governance & Automatisierung der Datensicherung

TL;DR / Management Summary In einer dynamischen Umgebung werden täglich neue VMs, Container und Datenbanken erstellt. Das größte Risiko ist die “Vergessene Ressource”, die niemals in einen Backup-Job aufgenommen wurde. Wir nutzen Policy-Based Backups: Anstatt einzelne Server auszuwählen, definieren wir Regeln (z.B. “Alle VMs im VLAN 10 sichern”). Ein Senior Admin nutzt Tagging oder Container-basierte Jobs, um sicherzustellen, dass jede neue Ressource ab der ersten Sekunde automatisch geschützt ist.


# 1. Einführung & Klassifizierung

Daten nach Wichtigkeit ordnen.

Nicht alle Daten sind gleich wichtig. Eine gute Policy unterteilt in Tiers:


# 2. Automatisierte Zuweisung

Weg von der manuellen Liste.

# 1. Tag-basiertes Backup

In Proxmox oder VMware weisen Sie einer VM einen Tag zu (z.B. backup:daily).

# 2. Folder/Storage-basierte Sicherung

Sichern Sie alles, was auf einem bestimmten Storage-Volume liegt (z.B. prod-zfs-storage).


# 3. Deep Dive: Automated Enforcement

Die Firewall für Backups.

Wie verhindern Sie, dass ein Junior-Admin eine VM ohne Backup erstellt?


# 4. Day-2 Operations: SLA Guardrails

Qualität sichern.

Setzen Sie SLA-Monitore ein.


# 5. Troubleshooting & “War Stories”

Wenn die Policy versagt.

# Top 3 Fehlerbilder

  1. Symptom: Backup-Job schlägt fehl, weil er versucht, eine gelöschte VM zu sichern.

    • Ursache: Die dynamische Liste wurde nicht aktualisiert.
    • Lösung: Nutzen Sie “Dynamische Container” (Proxmox Resource Pools), die sich beim Job-Lauf selbst refreshen.
  2. Symptom: Speicherplatz läuft über durch falsches Tiering.

    • Ursache: Ein User hat eine Dev-VM fälschlicherweise als Tier 1 getaggt.
    • Fix: Quotas auf Backup-Repositories setzen.
  3. Symptom: Neue VMs werden nicht gesichert.

    • Ursache: Tag-Name falsch geschrieben (z.B. backup-daily statt backup:daily).

# “War Story”: Die “Schatten-VM” des Entwicklers

Ein Entwickler setzte eine neue Produktions-Datenbank auf, um einen Fehler schnell zu beheben. Er nannte die VM Test-DB-Fix. Da der Backup-Job nur VMs sicherte, die mit SRV- begannen, wurde dieser Datenbank-Server niemals gesichert. Der GAU: Drei Monate später (die VM war längst produktiv) starb der Host. Das Ergebnis: Totaler Datenverlust von 3 Monaten Kunden-Daten. Lehre: Nutzen Sie eine Inclusion-Policy: Alles wird gesichert, außer es ist explizit als no-backup getaggt. Drehen Sie die Logik um, um menschliches Versagen auszuschließen.


# 6. Monitoring & Reporting

Der Compliance Report.

# Der ‘Orphaned VM’ Report

Erstellen Sie wöchentlich eine Liste:


# 7. Fazit & Empfehlung

Policies sind das Regelwerk, Automatisierung ist der Polizist.


# Anhang: Beispiel einer Backup-Matrix

Attribut Tier 1 Tier 2 Tier 3
Frequenz Alle 1h Täglich Wöchentlich
Aufbewahrung 30 Tage + 12 Mo 14 Tage 2 Versionen
Offsite Ja (Echtzeit) Ja (Nachts) Nein
Immutable Ja Ja Nein

# Referenzen