Zehn fast gleiche virtuelle Maschinen zu sichern muss nicht das Zehnfache an Platz kosten. Deduplizierung behält eine Kopie und viele Verweise.
Kurz gesagt
Deduplizierung ersetzt mehrfache Kopien von Daten durch Verweise auf eine gemeinsame Kopie und spart so Speicherplatz, übertragene Daten oder beides [1]. Der Proxmox Backup Server (PBS) zerlegt Backups dazu in Chunks, erkennt jeden Chunk am SHA-256-Prüfwert seines Inhalts und speichert einen Chunk nur einmal, egal wie viele Snapshots ihn nutzen [3]. Unsere Einschätzung: Deduplizierung passt hervorragend zu Backup-Zielen, weil Sicherungen derselben Systeme voller Wiederholungen sind. Sie ersetzt aber kein Backup, und auf anderen Dateisystemen ist sie nicht umsonst.
So funktioniert’s
- Chunks und Prüfwerte. PBS teilt Backup-Daten in Chunks fester oder dynamischer Größe. Gleicher Inhalt ergibt denselben Prüfwert, und der Prüfwert benennt die Chunk-Datei im Datastore [3].
- Fest oder dynamisch. VM-Abbilder nutzen Chunks fester Größe, typischerweise 4 MiB. Bei Datei-Backups würden feste Größen schon brechen, wenn eine Datei wächst, deshalb setzt PBS Chunk-Grenzen per Rolling Hash (eine Buzhash-Variante), damit Chunks wiederverwendbar bleiben [3].
- Inkrementeller Upload, volle Snapshots. Der Client lädt die Chunk-Liste des vorigen Snapshots und sendet für Chunks, die der Server schon hat, nur den Prüfwert. Jeder Snapshot verweist trotzdem auf alle seine Chunks und zählt deshalb als vollständige Sicherung [3][4].
- Verschlüsselung ändert die Rechnung. Bei verschlüsselten Chunks bildet PBS den Prüfwert über den Klartext zusammen mit dem Schlüssel. Gleiche Daten unter zwei Schlüsseln ergeben zwei verschiedene Prüfwerte und werden schlüsselübergreifend nicht dedupliziert [3][4].
- Prune gibt keinen Platz frei. Prune entfernt nur die Metadaten eines Snapshots. Die Garbage Collection (GC) löscht danach Chunks, die kein Snapshot mehr referenziert. Sie arbeitet in zwei Phasen, markieren und aufräumen, und verschont Chunks, die neuer sind als eine Grenze: 24 Stunden und 5 Minuten vor dem Start, sofern kein älteres Backup noch läuft. Proxmox schlägt vor, mit einem wöchentlichen Zeitplan zu beginnen [5].
- Geteilte Chunks brauchen Kontrolle. Weil viele Snapshots von einem Chunk abhängen können, bietet PBS Verify-Jobs und empfiehlt, alle Backups mindestens monatlich erneut zu prüfen, um Bit-Rot zu finden [5]. Unsere Lesart: Ein beschädigter Chunk kann jeden Snapshot treffen, der auf ihn verweist.
- Andere Orte, andere Kosten. Im Dateisystem ZFS arbeitet die Deduplizierung synchron, und die OpenZFS-Dokumentation rät davon ab, sie ohne besonderen Grund einzuschalten. Sie plant mindestens 1,25 GiB RAM pro TiB gespeicherter Daten ein, empfiehlt zuerst Kompression und sagt, dass sich der Gewinn nur lohnt, wenn das simulierte Verhältnis deutlich über 2x liegt [6]. Wie viel du sparst, hängt immer von den Daten ab [2].
Ein Praxisbeispiel
Nimm eine virtuelle Platte von 100 GiB in Chunks zu 4 MiB: Das sind 25.600 Chunks. Angenommen, über Nacht ändern sich nur 120 Chunks (erfundene Zahlen zur Veranschaulichung). Das nächste Backup lädt dann rund 480 MiB neue Chunks hoch, und der neue Snapshot listet trotzdem alle 25.600 Chunks und lässt sich wie eine vollständige Sicherung wiederherstellen [3][4]. Ein PBS-Setup haben wir in unserem Inventar (14. bis 16. Okt. 2026) nicht dokumentiert, deshalb ist das eine Rechenübung und keine Messung.
Prüfliste
- Verstehe das gelesene Dedup-Verhältnis als Ergebnis deiner Daten, nicht als Versprechen [2].
- Plane die Garbage Collection nach dem Prune ein, sonst kommt der Platz nie zurück [5].
- Nimm einen gemeinsamen Schlüssel für Backups, die sich gegenseitig deduplizieren sollen, denn verschiedene Schlüssel tun das nicht [3].
- Lege Verify-Jobs an und prüfe alte Backups regelmäßig erneut [5].
- Simuliere, bevor du Dedup in ZFS einschaltest, und probiere zuerst Kompression [6].
- Halte eine zweite Kopie an anderem Ort; Deduplizierung speichert weniger Daten, sie schützt sie nicht, also folge der 3-2-1-Regel.