Speicherverbrauch im PBS verstehen — Deduplizierung und Reporting

PBS speichert deutlich platzsparender als naiv erwartet. Wenn Du in der GUI siehst, dass Du 50 Snapshots à 100 GB hast, denkst Du: 5 TB. In Wahrheit belegt das oft nur 200–400 GB. Hier erklären wir, warum.

Wie PBS deduplizierend speichert

PBS zerlegt jedes Backup in Chunks von ca. 4 MB. Jeder Chunk bekommt einen Hash (SHA-256) und wird unter dem Hash im Pool abgelegt. Wenn ein zweiter Backup-Snapshot denselben Datenblock enthält (gleicher Hash), wird er nicht erneut gespeichert — der zweite Snapshot referenziert einfach den vorhandenen Chunk.

Das passiert automatisch und produkt-übergreifend:

• Die täglichen Backups einer VM teilen sich 95–99 % der Chunks (nur die Differenz pro Tag ist neu).
• Verschiedene VMs mit gleichem Betriebssystem teilen sich oft 30–50 % der Chunks (Linux-Kernel-Files, /usr-Verzeichnis, Standard-Pakete).
• Gleicher Snapshot zweimal sichern → exakt 0 zusätzlicher Speicher.

Wo Du den Speicherverbrauch siehst

In der PBS-GUI an drei Stellen:

1. Datastore-Summary

Datastore → <dein-datastore> → Summary: zeigt belegt/frei in GB plus eine Auslastungs-Grafik der letzten Wochen.

Das ist die wirklich belegte Datenmenge auf der Disk — nach Deduplizierung. Wichtigste Zahl für Dich.

2. Snapshot-Größen

Datastore → Content → <vm> → Snapshot anklicken: pro Snapshot wird die “Size” angezeigt.

Achtung: Das ist die unkomprimierte, nicht-deduplizierte Datenmenge des Backups. Wenn Du das aufsummierst, kommt die naive Zahl raus (50 Snapshots × 100 GB = 5 TB) — die hat aber nichts mit dem tatsächlichen Disk-Verbrauch zu tun.

3. Datastore-Statistik (CLI)

proxmox-backup-manager datastore status <datastore>

Zeigt:

• Total: Disk-Größe insgesamt
• Used: tatsächlich belegt
• Avail: frei
• Index size: wie viel Manifests/Index-Files belegen
• Chunk size: wie viel die Chunks belegen
• Deduplication factor: Verhältnis von “Wenn nicht dedupliziert” zu “Tatsächlich belegt”

Eine Deduplication factor: 8.5 heißt: ohne Deduplizierung würde der Datastore 8,5× mehr Speicher brauchen.

Wieviel Speicher ein typisches Setup braucht

Faustformel:

• 1 VM mit 100 GB Daten, daily Backups, 30 Tage Retention → 130–180 GB Disk-Verbrauch.
• 5 VMs à 100 GB, daily Backups, 30 Tage Retention → 400–700 GB Disk-Verbrauch (deutlich weniger als 5×130 GB, weil VMs sich Chunks teilen).
• 10 VMs à 50 GB, daily Backups, 6 Monate Retention → 600–900 GB Disk-Verbrauch.

Variationen:

• Datenbank-VMs mit hoher Änderungsrate: höherer Verbrauch (mehr “neue” Chunks pro Tag).
• Statische File-Server: niedriger Verbrauch (wenig Änderung).
• VMs mit gleichem OS: stark dedupliziert.

Bei On-Demand-Tarifen — wie wir abrechnen

Wenn Du auf unserem PBS-On-Demand-Tarif bist (9,99 €/TB/Monat), zählen wir den tatsächlichen Disk-Verbrauch (nach Deduplizierung), gemessen täglich, gemittelt über den Monat.

Wenn Du also den ganzen Monat 1,3 TB belegt hast, zahlst Du 1,3 × 9,99 € = ca. 13 €/Monat.

Das erste TB ist immer inklusive — Du zahlst nur, was darüber hinaus geht.

Wenn der Verbrauch nicht sinkt nach dem Prune

Klassisches Szenario: Du hast 30 Snapshots geprunt, der Datastore ist immer noch voll. Was tun?

1. Garbage Collection läuft noch nicht: Prune markiert nur, GC räumt erst auf. Schau, wann der nächste GC-Lauf ist.
2. GC startet manuell: Datastore → Prune & GC → Run garbage collection.
3. Auch nach GC bleibt der Verbrauch hoch: Die geprunten Snapshots haben sich Chunks mit anderen Snapshots geteilt. Diese Chunks bleiben, weil sie noch gebraucht werden.

Die einzige Möglichkeit, einen Datastore wirklich zu schrumpfen: Snapshots löschen, bis nichts mehr referenziert. Das ist meist unrealistisch — Du willst ja Backups behalten.

Mehr dazu in Garbage Collection.

Häufige Fragen

Was sind “Index size” und “Chunk size”? Index-Files (.fidx) sind klein und beschreiben, welche Chunks zu welchem Snapshot gehören. Chunks sind die eigentlichen Datenblöcke, der Großteil des Verbrauchs.

Wie sehe ich, welche VM den meisten Speicher braucht? Schwierig direkt — wegen Deduplizierung “gehört” ein Chunk nicht eindeutig zu einer VM. Annäherung: in der GUI in Content nach VM-Knoten gruppieren, Snapshot-Größen zusammenrechnen. Oder per CLI: proxmox-backup-manager group list <datastore>.

Macht es einen Unterschied, ob ich Snapshots zur gleichen Zeit lösche oder über mehrere Tage verteilt? Nein. Was zählt, ist die finale Menge der referenzierten Chunks nach GC. Die Reihenfolge des Löschens ist egal.

Warum sehe ich manchmal “Out of space” beim Backup, obwohl noch Speicher da ist? Manchmal Reporting-Verzögerung. Tatsächlich kann’s auch an temporärem Speicher beim Schreiben liegen, der größer ist als das fertige Backup. Bei häufigen Out-of-Space-Fehlern: schreib uns ein Ticket, wir prüfen die Disk-Auslastung.

Wie kann ich Speicher manuell freigeben? Snapshots löschen (manuell oder via Prune), dann GC laufen lassen. Andere Hebel gibt’s nicht — PBS managed das vollautomatisch.

Warum ist meine Backup-Größe pro Snapshot konstant, obwohl die VM kaum was ändert? Die Snapshot-”Size” in der GUI ist die unkomprimierte Größe des Snapshots — der wäre genauso groß, als hätte er kein einziges Chunk mit anderen geteilt. Tatsächlicher Disk-Verbrauch ist deutlich kleiner. Schau Dir den Datastore-Summary an, nicht die einzelne Snapshot-Größe.

Kann ich Deduplizierung deaktivieren? Nein. Deduplizierung ist Kernarchitektur von PBS — ohne sie wäre der Speicher-Verbrauch unrealistisch hoch.

Weiter geht’s

• Garbage Collection — was wirklich Speicher freigibt
• Retention Policies konfigurieren
• Performance-Tuning bei langsamen Backups