Proxmox Backup-Strategien: Snapshots, vzdump und Proxmox Backup Server

Zuerst die Antwort: die Strategie in drei Stufen

Für einen Proxmox-Host, der Ihnen wichtig ist, sieht die funktionierende Strategie so aus:

1. Snapshots für die nächste Stunde: Erstellen Sie einen vor riskanten Änderungen (Upgrades, Eingriffe an der Konfiguration), setzen Sie bei Problemen zurück, löschen Sie ihn danach. Snapshots leben auf dem Storage der VM: Sie schützen vor Ihren eigenen Fehlern, nicht vor dem Host selbst.
2. Geplante vzdump-Backups für den nächsten Monat: Backups im Snapshot-Modus nach Zeitplan, mit Retention-Regeln, auf Storage, der nicht dieselben Disks sind, auf denen die VMs laufen.
3. Proxmox Backup Server, sobald die Zahlen wachsen: deduplizierte, inkrementelle, verschlüsselte, verifizierte Backups auf eine zweite Maschine, offsite synchronisiert. Hier werden tägliche Backups mit vollständiger Historie jedes Gasts günstig genug, um sie tatsächlich zu machen.

Und die Regel, die aus alldem statt Show echten Schutz macht: Ein Backup ohne Restore ist eine Hypothese. Planen Sie Restore-Tests genauso ein wie die Backups.

Snapshots sind keine Backups

Eine Klarstellung wert, denn die GUI platziert "Snapshot" verführerisch nah bei "Backup". Ein VM-Snapshot friert einen Zeitpunkt ein auf demselben Storage, auf dem die VM lebt: Stirbt der Storage, stirbt der Snapshot mit. Langlebige Snapshots verschlechtern zudem die Performance und verkomplizieren den Storage, je mehr Deltas sich anhäufen.

Wofür Snapshots hervorragend geeignet sind, ist genau das, wofür Backups zu langsam sind: ein sofortiger Rückgängig-Knopf um eine riskante Änderung herum. Erstellen Sie einen, tun Sie die gefährliche Sache, bestätigen Sie, löschen Sie den Snapshot. Lebensdauer von Minuten bis Stunden: der Rat aus unserem Debian-Upgrade-Leitfaden, "legen Sie zuerst Ihren Rollback-Plan fest", konkret gemacht mit einem Klick. (RAID ist, der Vollständigkeit halber, weder Snapshots noch Backups: das ist Verfügbarkeit, eine dritte Sache.)

Stufe 2: vzdump richtig eingesetzt

vzdump ist die eingebaute Backup-Engine von Proxmox: Es erzeugt ein vollständiges, in sich geschlossenes Archiv eines Gasts, wiederherstellbar auf jedem Proxmox-Host. Der Unterschied zwischen "wir betreiben vzdump" und einer echten Strategie liegt in vier Einstellungen.

Modus: Snapshot, mit dem Guest Agent

Verwenden Sie den Snapshot-Modus für Routine-Zeitpläne: Er sichert laufende Gäste mit höchstens einer kurzen Unterbrechung. Seine Konsistenz hängt von einer Sache ab, die oft übersprungen wird: dem QEMU Guest Agent in jeder VM (das Paket qemu-guest-agent, plus die Checkbox in den VM-Optionen). Damit friert vzdump die Dateisysteme des Gasts ein (fs-freeze/fs-thaw) im Moment der Aufnahme, sodass das Archiv ein crash-consistent (oder besseres) Image enthält statt eines beschädigten. Reservieren Sie den stop-Modus für die Gäste, bei denen die Sicherheit einer kalten Kopie die geplante Ausfallzeit wert ist, und bei Datenbanken gilt weiterhin: doppelt hält besser. Ein Dump auf Anwendungsebene (pg_dump etc.) nach Zeitplan innerhalb des Gasts kostet wenig und ermöglicht Restores auf eine Weise, die ein Disk-Image nicht kann.

Zeitplan und Retention

Konfigurieren Sie dies unter Datacenter → Backup: welche Gäste, wann (nächtlich, gestaffelt, wenn der Storage geteilt wird), und (der Teil, der sowohl Datenverlust als auch volle Disks verhindert) die Retention. Proxmox räumt nach Regeln auf: keep-daily=7, keep-weekly=4, keep-monthly=6 gibt Ihnen zum Beispiel einen Monat tägliche Granularität und einen zwei Saisons langen Ausläufer, automatisch bereinigt. Jede Retention-Regel schlägt die zwei Standardeinstellungen, die man in der Praxis tatsächlich vorfindet: "alles behalten, bis die Disk voll ist" und "1 behalten".

Ziel: nicht dieselben Disks

Ein Backup auf dem Storage, den es schützt, ist ein Snapshot mit Umwegen. Minimal brauchbares Ziel: jeder Storage, der unabhängig ausfallen kann, ein zweites lokales Array, NFS anderswo, oder (Stufe 3) ein PBS-Datastore auf einer anderen Maschine.

Fleecing: für langsame Ziele

Wenn Backups auf ein langsames Ziel (NFS über eine dünne Verbindung, ein stark ausgelastetes HDD-Array) Gäste träge machen, liegt das daran, dass die Schreibvorgänge des Gasts auf das Backup-Ziel warten. Fleecing (--fleecing enabled=1,storage=local-lvm) puffert alte Blöcke stattdessen auf schnellem lokalem Storage und entkoppelt so die I/O des Gasts von der Geschwindigkeit des Ziels: ein unauffälliges Feature, das die häufigste Beschwerde "Backups beeinträchtigen die Produktion" löst.

Stufe 3: Proxmox Backup Server

Die Einschränkung von vzdump ist Arithmetik: Jedes Backup ist ein vollständiges Archiv, sodass tägliche Backups einer 200-GB-VM 200 GB pro Tag kosten, und die meisten dieser Bytes sind Tag für Tag identisch. Proxmox Backup Server (ein kostenloses Open-Source-Begleitprodukt, das Sie auf einer zweiten Maschine installieren) verändert diese Rechnung:

• Deduplizierung + inkrementelle Übertragung. Daten werden als content-addressed chunks gespeichert; unveränderte Chunks werden nur einmal gespeichert, und laufende VMs werden inkrementell mit QEMU dirty bitmaps gesichert: Nur Blöcke, die seit dem letzten Backup geschrieben wurden, werden überhaupt gelesen, geschweige denn übertragen. Praktischer Effekt: Nach dem ersten Backup dauern nächtliche Backups großer VMs Minuten und kosten Gigabyte, nicht Hunderte davon. (Container bekommen ihren eigenen Beschleuniger: Der Änderungserkennungsmodus metadata überspringt unveränderte Dateien, indem er sie mit den Metadaten des vorherigen Snapshots vergleicht.)
• Wie viel spart Dedup? Proxmox veröffentlicht ehrlich gesagt kein offizielles Verhältnis. Es hängt von der Retention-Tiefe ab und davon, wie ähnlich sich Ihre Gäste sind. Community-Berichte landen üblicherweise im Bereich von 5–12× bei täglichen Backups und sinnvoller Retention; ein Verhältnis nahe 1× bedeutet meist einfach, dass die Retention auf einen einzigen Snapshot eingestellt ist.
• Verifizierung gegen Bitrot. Geplante Verify Jobs berechnen die Prüfsummen gespeicherter Chunks neu, sodass stille Storage-Korruption entdeckt wird, bevor der Restore stattfindet, für den die Daten gebraucht würden. Das ist PBS' still tödliches Feature: Kalte Archive verrotten unbemerkt; verifizierte nicht.
• Clientseitige Verschlüsselung (AES-256-GCM): Backups werden verschlüsselt, bevor sie den PVE-Host verlassen, sodass die PBS-Maschine (oder der S3-Bucket dahinter) nie Klartext enthält. Bewahren Sie den Schlüssel sicher auf; PBS unterstützt einen auf Papier druckbaren Hauptschlüssel für Notfälle.
• Offsite-Sync. Sync Jobs replizieren Datastores zwischen PBS-Instanzen (Push oder Pull, nur Delta). Ein zweites PBS an einem anderen Standort macht aus dem Setup ein echtes 3-2-1. Seit PBS 4.2 ist S3-kompatibler Objektspeicher ein offiziell unterstütztes Datastore-Backend, was "Offsite-Kopie in einem Bucket" ebenfalls zu einer vollwertigen Option macht.
• Restore-Ergonomie: Einzeldatei-Restore (eine Datei aus einem VM-Image-Backup über die GUI herauspicken) und Live-Restore (eine VM direkt von ihrem Backup starten, während es zurückgestreamt wird, RTO in Minuten für die Ungeduldigen).

Die Deployment-Form auf dedizierten Servern ist unkompliziert: PBS will seine eigene Maschine (Backups auf dem Hypervisor schützen nichts) mit kapazitätsorientiertem Storage (RAID-technisch: raidz2/RAID-6-Territorium) und einer Anbindung, die dick genug ist, dass Restore-Fenster tolerierbar bleiben (die Restore-Fenster-Rechnung aus dem Sizing-Leitfaden gilt auch hier: 4 TB über 1 Gbit/s sind ~9 Stunden; bei 10 Gbit/s wird daraus weniger als eine). PVE-Hosts erhalten anschließend jede Nacht einen Datacenter → Backup-Job, der auf das PBS-Datastore zielt, PBS führt Prune + Garbage Collection + wöchentliches Verify aus, und (wenn die Datenmenge es rechtfertigt) schiebt ein Sync Job die Daten an einen zweiten Standort.

Was ist mit Replikation und Ceph?

Zwei benachbarte Features werden mit Backups verwechselt. ZFS-Replikation (pvesr) kopiert Gast-Volumes nach Zeitplan auf einen anderen Knoten (so oft wie jede Minute), hervorragend für schnelles Failover mit lokalem Storage, aber sie repliziert jede Löschung und jede Korruption originalgetreu mit, innerhalb von Minuten; das ist Verfügbarkeit, keine Historie. Ceph ebenso: selbstheilender, replizierter Storage, der Ihre ransomware-verschlüsselten Blöcke mit makelloser Redundanz bewahrt. Beide arbeiten mit Backups zusammen (sie decken den Fall "Knoten ist gestorben" ab; Backups decken den Fall "wir brauchen den Stand von letztem Dienstag" ab). Keines von beiden ersetzt sie. Mehr zu beiden im Cluster- und HA-Leitfaden.

Die Restore-Übung

Mindestens vierteljährlich: Stellen Sie eine VM auf eine Wegwerf-VMID wieder her (qmrestore oder GUI, Restore-as-new: Das Original wird nicht überschrieben), starten Sie sie, bestätigen Sie, dass die Anwendung tatsächlich funktioniert, löschen Sie sie wieder. Zwanzig Minuten, die aus "wir haben Backups" "wir haben Restores" machen. Nehmen Sie dabei gleich die Zeit. Überrascht Sie die Dauer, ist das jetzt besser als während eines Vorfalls: Dann finden Sie heraus, ob Live-Restore, mehr Bandbreite oder eine feinere Retention-Granularität die Konfiguration wert ist.

Häufig gestellte Fragen

Sind Backups im Snapshot-Modus einer laufenden Datenbank sicher?

Sicher, aber verbesserungsfähig. Da der Guest Agent bei der Aufnahme die Dateisysteme einfriert, ist das Image auf Dateisystemebene konsistent, und moderne Datenbanken (PostgreSQL, MySQL/InnoDB) erholen sich davon sauber: Das entspricht der Erholung nach einem Stromausfall, wofür sie ausgelegt sind. Was Ihnen ein Disk-Image nicht bietet, ist Flexibilität für einen bestimmten Zeitpunkt oder einfache partielle Restores. Fügen Sie deshalb für Datenbanken, auf die es ankommt, Dumps auf Anwendungsebene oder WAL-Archivierung innerhalb des Gasts hinzu. Die Kombination (Image-Backups für die Wiederherstellung des Gesamtsystems, Dumps für die chirurgisch präzise Wiederherstellung) ist die vernünftige Antwort.

Wie oft sollte ich sichern?

Arbeiten Sie rückwärts von der Frage "wie viel Arbeit können wir uns leisten zu verlieren?" Das ist Ihr Backup-Intervall. Ein nächtliches Backup ist die Standarduntergrenze für normale Gäste; dank des inkrementellen Kostenmodells von PBS ist mehrmals täglich für stark genutzte Datenbanken durchaus erschwinglich (und pvesr-Replikation kann die Lücke bei der Verfügbarkeit daneben auf eine Minute verkleinern). Was ebenso stark ins Gewicht fällt: die Retention-Tiefe. Beschädigung und Ransomware werden oft erst Tage später entdeckt. Bei einer Strategie mit nur drei nächtlichen Backups kann der Schaden am Ende in jeder Kopie stecken, bevor es jemand bemerkt.

Kann PBS auch Dinge sichern, die keine Proxmox-Gäste sind?

Ja: Der proxmox-backup-client läuft auf jedem Linux-Host und schiebt Backups auf Dateiebene in dieselben deduplizierten, verschlüsselten, verifizierten Datastores. Wenn Sie ohnehin PBS betreiben, ist das ein natürlicher Ort für die Konfiguration und Daten Ihrer nicht virtualisierten Maschinen: eine Backup-Infrastruktur, eine Retention-Richtlinie, ein Ort, um Restores zu testen.

Schützt das vor Ransomware?

Das ist der größte Teil der Antwort, mit zwei Bedingungen. Erstens Trennung: Ein PBS, das nur über seine API mit eigenen Zugangsdaten erreichbar ist, lässt sich von einem kompromittierten Gast nicht verschlüsseln, aber Backups auf einem NFS-Share, das der Hypervisor read-write mountet, schon. Zweitens Historie und Sync: eine Retention, die tief genug zurückreicht, um hinter die Infektion zu gelangen, Verify Jobs, damit Sie wissen, dass die Chunks intakt sind, und ein Offsite-Sync (zweites PBS oder S3), den ein einzelner kompromittierter Standort nicht erreichen kann. Die clientseitige Verschlüsselung von PBS schützt Ihre Backups vor dem Storage; die Zugriffstrennung schützt sie vor dem Angreifer.

Deployment auf Serverside

Das naheliegende PBS-Deployment hier ist ein zweiter dedizierter Server: stark kapazitätsorientierte Storage-Konfiguration, in unserem privaten Netzwerk mit Ihren Proxmox-Hosts, sodass der nächtliche Backup-Traffic nie Ihre öffentliche Bandbreite berührt, in einer anderen Failure-Domain als der Host, den er schützt. Provisioning in unter einer Minute auf ASN 55285, und durchgehend dieselben Images mit Proxmox vorinstalliert.

Der Rest der Serie: Einrichtung, Networking, LXC vs. VMs, und (wo Replikation und Failover die Aufgabe von Backups übernehmen) Clustering und Hochverfügbarkeit.