# 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:
- Tier 1 (Critical): RPO 15 Min, RTO 1h. (AD, SQL, ERP).
- Tier 2 (Standard): RPO 24h, RTO 4h. (Fileserver, Web-Frontends).
- Tier 3 (Dev/Test): RPO 7 Tage, RTO “Best Effort”. (Testumgebungen).
# 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).
- Aktion: Ihr Backup-Job im PBS oder Veeam sucht dynamisch nach diesem Tag.
- Ergebnis: Der Admin muss den Backup-Job nie wieder anfassen. Er muss nur die neue VM korrekt taggen.
# 2. Folder/Storage-basierte Sicherung
Sichern Sie alles, was auf einem bestimmten Storage-Volume liegt (z.B. prod-zfs-storage).
- Vorteil: Keine VM kann “durchrutschen”.
# 3. Deep Dive: Automated Enforcement
Die Firewall für Backups.
Wie verhindern Sie, dass ein Junior-Admin eine VM ohne Backup erstellt?
- Technik: Nutzen Sie Compliance-Scripte (z.B. via Ansible).
- Workflow: Ein nächtlicher Job vergleicht die Liste aller VMs in Proxmox mit der Liste aller VMs im Backup-Server.
- Alarm: Wenn eine VM in Proxmox existiert, aber nicht im Backup -> Sofortiges Ticket an das Team.
# 4. Day-2 Operations: SLA Guardrails
Qualität sichern.
Setzen Sie SLA-Monitore ein.
- Policy: “Jedes Tier-1 Backup muss verschlüsselt und unveränderlich (Immutable) sein.”
- Enforcement: Die Backup-Software verweigert das Speichern von Tier-1 Daten in ungeschützten Repositories.
# 5. Troubleshooting & “War Stories”
Wenn die Policy versagt.
# Top 3 Fehlerbilder
-
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.
-
Symptom: Speicherplatz läuft über durch falsches Tiering.
- Ursache: Ein User hat eine Dev-VM fälschlicherweise als
Tier 1getaggt. - Fix: Quotas auf Backup-Repositories setzen.
- Ursache: Ein User hat eine Dev-VM fälschlicherweise als
-
Symptom: Neue VMs werden nicht gesichert.
- Ursache: Tag-Name falsch geschrieben (z.B.
backup-dailystattbackup:daily).
- Ursache: Tag-Name falsch geschrieben (z.B.
# “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:
- VMs ohne Backup-Job.
- VMs mit fehlgeschlagenen Backups in den letzten 48h.
- VMs, die gegen die Retention-Policy verstoßen.
# 7. Fazit & Empfehlung
Policies sind das Regelwerk, Automatisierung ist der Polizist.
- Empfehlung: Nutzen Sie Resource Pools in Proxmox, um VMs logisch zu gruppieren und binden Sie Backup-Jobs an diese Pools.
- Wichtig: Machen Sie Backup-Checks zum Teil Ihres Provisioning-Workflows. Eine VM ist erst dann “Live”, wenn das erste Backup erfolgreich war.
# 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 |