Ein grüner Backup-Job ist noch keine belastbare Backup-Strategie. In einem Smart-Home-Homelab laufen sehr unterschiedliche Systeme: Home Assistant, Datenbanken, MQTT, Paperless, KI-Dienste und kleine Infrastruktur-Container. Sie alle gleich zu sichern ist bequem, aber nicht immer zuverlässig.
In meinem Proxmox-Setup hat sich eine zweigeteilte Strategie bewährt: normale Anwendungs-Gäste werden im Snapshot-Modus gesichert, Datenbank-Gäste erhalten ein eigenes Zeitfenster mit sauberem Stopp. Die Backups landen auf einem Proxmox Backup Server und werden mit einer überschaubaren Aufbewahrung automatisch bereinigt.
Warum ein einziger großer Job problematisch ist
Ein Home-Assistant-VM, ein Paperless-LXC und eine MariaDB haben unterschiedliche Anforderungen. Snapshot-Backups halten Ausfallzeiten klein, garantieren aber nicht bei jeder Anwendung denselben konsistenten Zustand. Ein Stop-Backup ist für Datenbanken besonders robust, würde bei allen Gästen jedoch unnötig viele Dienste gleichzeitig unterbrechen.
Hinzu kommt: Ein träger Container kann den gesamten Job verzögern. Genau das ist ein guter Grund, Datenbanken und normale Anwendungen getrennt zu behandeln.
Meine Aufteilung
1. Normale Anwendungs- und Infrastruktur-Gäste
Home Assistant, Paperless, TeslaLogger, Ollama, MQTT, Cloudflare-DDNS und ähnliche Gäste laufen in einem wöchentlichen Snapshot-Job. Das reduziert die Unterbrechung und hält die Sicherung planbar.
2. Datenbank-Gäste
MariaDB und InfluxDB sichere ich in einem nachgelagerten Stop-Job. Damit ist der Dateisystem- und Datenbankzustand beim Abbild klar. Vorher sollte geprüft werden, welche Anwendungen während dieses kurzen Fensters keine Daten schreiben können.
3. Der Backup-Server selbst
Der Proxmox Backup Server darf nicht gedankenlos in denselben Datastore sichern, den er selbst bereitstellt. Seine Konfiguration und sein Datastore benötigen eine eigene Schutzstrategie. Ebenso wichtig: Die Anzeige des virtuellen PBS-Systemdatenträgers ist nicht automatisch die Auslastung des eigentlichen Backup-Datastores.
Ein konkreter Wochenplan
- Sonntag 01:00 Uhr: Snapshot-Backup der normalen Gäste,
- Sonntag 02:00 Uhr: Stop-Backup der Datenbank-Gäste,
- Aufbewahrung: zunächst die letzten drei Sicherungen,
- tägliche Prune-Aufgabe auf dem Backup-Datastore,
- Benachrichtigung bei fehlgeschlagenen Jobs.
Drei Stände sind für mein Homelab ein pragmatischer Anfang, aber kein universeller Wert. Wer längere Zeiträume abdecken muss, ergänzt tägliche, wöchentliche und monatliche Stände entsprechend Speicherplatz und persönlichem Risiko.
Was zusätzlich in die Anwendung gehört
Gast-Backups schützen die komplette Maschine. Für wichtige Daten ergänze ich anwendungsnahe Exporte:
- MariaDB: konsistenter SQL-Dump,
- InfluxDB: zur eingesetzten Version passende Backup-Funktion,
- Paperless-ngx: Dokumente, Medien, Datenbank und Exportmanifest,
- TeslaLogger: Datenbank- und Anwendungsbackup,
- Home Assistant: vollständiges Home-Assistant-Backup.
Diese Exporte sollten nicht nur im selben Gast liegen. Sonst verschwinden sie gemeinsam mit dessen Datenträger.
Speicher richtig lesen
Proxmox kann mehrere Ebenen anzeigen: lokalen Systemdatenträger, Thin-Pool, virtuellen Datenträger der PBS-VM und den über PBS eingebundenen Datastore. Eine hohe Auslastung auf einer Ebene beweist nicht automatisch, dass der Datastore voll ist.
Vor einer Erweiterung prüfe ich deshalb immer:
pvesm status
lvs
vgs
df -hErst die Kombination zeigt, wo der Platz tatsächlich knapp wird. Bei Thin Provisioning ist zudem der reale freie Platz im Volume-Group-Kontext entscheidend.
Die Wiederherstellung gehört zum Backup
Mindestens gelegentlich sollte ein Gast unter einer neuen ID und ohne produktive Netzverbindung wiederhergestellt werden. Danach prüfe ich:
- Startet das Betriebssystem?
- Laufen die erwarteten Dienste?
- Ist die Datenbank lesbar?
- Sind die jüngsten Dokumente beziehungsweise Messwerte vorhanden?
- Lässt sich die Anwendung anmelden und bedienen?
Eine Prüfsumme bestätigt nur, dass ein Archiv unverändert ist. Erst ein Restore-Test bestätigt, dass daraus wieder ein funktionierender Dienst entsteht.
Typische Fehler
- Alle Gäste in einen Stop-Job packen und dadurch lange Ausfallzeiten erzeugen.
- Nur Snapshots verwenden und Datenbankkonsistenz nie prüfen.
- Den PBS-Gast in denselben PBS-Datastore sichern wollen.
- Alte Sicherungen ohne bestätigte Aufbewahrungsregel löschen.
- Backup-Erfolgsmeldungen lesen, aber nie einen Restore testen.
- Interne Exporte im Gast erzeugen, ohne sie extern zu sichern.
Fazit
Die beste Proxmox-Backup-Strategie ist nicht die mit den meisten Jobs, sondern die, deren Wiederherstellung man versteht. Durch die Trennung von normalen Gästen und Datenbanken bleiben Ausfallzeiten klein und Datenzustände nachvollziehbar. PBS übernimmt Deduplizierung, Aufbewahrung und Prüfung – die Verantwortung für einen echten Restore-Test bleibt aber bei uns.
Passend dazu: TeslaLogger auf Proxmox installieren · IDM-Wärmepumpe in Home Assistant · offizielle Proxmox-VE-Dokumentation