Proxmox Backup-Strategie fürs Smart Home: Snapshots, Datenbanken und PBS richtig sichern

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

Die Jobs im Proxmox-Webinterface einrichten

Vorher unter Datacenter → Storage prüfen, ob der Proxmox Backup Server als Storage erreichbar ist. Dann Datacenter → Backup → Add öffnen: Storage auswählen, Zeitplan setzen, bei Selection mode gezielt nur die gewünschten Gast-IDs eintragen und den Modus Snapshot wählen. Für Datenbanken einen zweiten Job mit den betreffenden IDs und Modus Stop anlegen. Die beiden Listen dürfen sich nicht unbeabsichtigt überschneiden. Den PBS-Gast nicht in einen Job aufnehmen, der auf dessen eigenen Datastore zielt.

Ein einmaliger manueller Test auf dem Proxmox-Host, mit einer einzelnen unkritischen Test-Gast-ID, macht Storage- und Berechtigungsfehler früh sichtbar:

pvesm status
vzdump <TEST-CTID> --mode snapshot --storage <PBS-STORAGE> --compress zstd

Vor vzdump Gast-ID und Ziel-Storage doppelt prüfen; der Befehl erzeugt ein echtes Backup und benötigt Platz. Den Stop-Modus nicht probeweise auf einer produktiven Datenbank ausführen, wenn das Ausfallfenster nicht abgestimmt ist. Im Task Log auf TASK OK achten, danach im PBS-Datastore den entstandenen Snapshot kontrollieren.

• 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 -h

Erst 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

Für den Restore-Test in Proxmox im Storage unter Backups den Snapshot auswählen und Restore anklicken. Eine neue freie Gast-ID und ein isoliertes Netzwerk wählen, damit kein zweiter MQTT-Broker, DHCP-Dienst oder Datenbankserver im Produktionsnetz auftaucht. Nicht auf die produktive ID zurückspielen. Erst nach der Funktionsprüfung den Testgast wieder kontrolliert entfernen.

Zusätzlich lässt sich die PBS-Prüfung des Datastores über dessen Verify Jobs terminieren. Ein Verify-Job prüft Backup-Chunks, ersetzt aber weiterhin keinen Anwendungs-Restore. Bei Datenbanken nach dem Restore eine Testabfrage und einen neuen Schreibvorgang in der isolierten Umgebung prüfen.

Mindestens gelegentlich sollte ein Gast unter einer neuen ID und ohne produktive Netzverbindung wiederhergestellt werden. Danach prüfe ich:

1. Startet das Betriebssystem?
2. Laufen die erwarteten Dienste?
3. Ist die Datenbank lesbar?
4. Sind die jüngsten Dokumente beziehungsweise Messwerte vorhanden?
5. 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