Türkei (Türkisch)
Germany (German)
Worldwide (English)
Proxmox VE behandelt Snapshots und Backups getrennt. Backups speichern VM/CT-Konfiguration und Daten in einem eigenständigen Format; Snapshots sind Wiederherstellungspunkte auf dem aktuellen Storage.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Snapshots und echte Backups anhand Retention, Offsite-Kopie, Ransomware, Restore-Test, RPO/RTO und Proxmox/PBS unterscheiden.
Proxmox VE behandelt Snapshots und Backups getrennt. Backups speichern VM/CT-Konfiguration und Daten in einem eigenständigen Format; Snapshots sind Wiederherstellungspunkte auf dem aktuellen Storage.
Ein Snapshot schützt allein nicht gegen Storage-Ausfall, Pool-Verlust oder unbefugtes Löschen. Eine echte Backup-Strategie braucht einen getrennten Failure Domain und getestete Restores.
Ein Snapshot ist ein schneller Wiederherstellungspunkt. ZFS, LVM-thin und qcow2 implementieren ihn unterschiedlich. Meist hängt der Snapshot vom gleichen Storage ab; bei vollständigem Storage-Verlust kann auch der Snapshot verloren gehen.
Snapshots eignen sich vor Kernel-/Anwendungs-Updates oder Konfigurationsänderungen. Viele alte Snapshots können Kapazität und Performance belasten.
Ein Backup erzeugt eine wiederherstellbare Kopie unabhängig vom Live-Storage. Proxmox VE `vzdump` und Proxmox Backup Server können Daten auf einem separaten Ziel speichern.
Backup-Qualität bedeutet mehr als eine vorhandene Datei. Retention, Verifikation, Restore-Test, Verschlüsselung, Immutability/Offline-Kopie und Zugriffsabgrenzung gehören dazu.
Wird das Hypervisor-Konto kompromittiert, können Snapshots zusammen mit VMs gelöscht werden. Ein Snapshot auf demselben Storage bietet keine administrative oder physische Unabhängigkeit.
RPO beschreibt akzeptablen Datenverlust, RTO die Wiederherstellungszeit. Ein tägliches Backup kann ein RPO von bis zu 24 Stunden bedeuten. Kritische Datenbanken benötigen häufigere Sicherungen oder Logs/Replikation.
Snapshots ermöglichen schnellen Rollback, ersetzen aber keine unabhängige Backup-Strategie. In Produktion werden meist beide kombiniert.
Beispiel: Live-VM-Storage, tägliches Backup auf getrenntem Storage und zweite Kopie an anderem Standort. Ziel ist, dass ein einzelner Strom-, Controller-, Account- oder Standortausfall nicht alle Kopien zerstört.
Ein erfolgreicher Backup-Job garantiert nicht, dass die Wiederherstellung bootet oder konsistent ist. Regelmäßig in eine Test-VM restaurieren und Anwendung/DB prüfen.
vzdump --helppvesm statusqm listsnapshot <VMID>pct listsnapshot <CTID>Snapshot für schnellen Rollback vor Änderungen; unabhängiges Backup für Hardware-/Node-Ausfall, Ransomware oder versehentliches Löschen. Kritische Systeme nutzen meist beides.
| Merkmal | Snapshot | Backup |
|---|---|---|
| Schneller Rollback | Sehr gut | Möglich, oft langsamer |
| Schutz bei Storage-Ausfall | Niedrig auf gleichem Storage | Hoch bei getrenntem Ziel |
| Lange Retention | Meist ungeeignet | Geeignet |
| Offsite-Kopie | Nicht inhärent | Ja |
Mindestanforderungen nicht mit Produktionskapazität verwechseln. Peak-Workload, Backup, Wachstumsreserve, Ressourcenpolitik und Recovery-Plan gemeinsam bewerten.
Allein nicht. Bei gleichem Storage und Management ist es keine unabhängige Disaster-Recovery-Kopie.
Bei kritischen Daten ja. Snapshots bieten schnellen Rollback, Backups unabhängige Wiederherstellung.
CPU, RAM, Storage, Netzwerk und Betrieb gemeinsam bewerten; ein größeres Paket ohne Engpassanalyse ist selten eine dauerhafte Lösung.