Garbage Collection erklärt — was wirklich Speicher in PBS freigibt

Prune markiert Snapshots als nicht mehr benötigt. Aber: die eigentlichen Datenblöcke (Chunks) bleiben erst mal auf der Festplatte. Erst die Garbage Collection (GC) räumt verwaiste Chunks weg und gibt den Speicher frei. Ohne GC bleibt der Speicherverbrauch hoch, egal wie viel Du prunest.

Warum nicht direkt löschen?

Der Trick an PBS ist Deduplizierung: identische 4-MB-Datenblöcke werden nur einmal gespeichert, auch wenn sie in 50 verschiedenen Snapshots vorkommen. Würde Prune einen Snapshot löschen und dabei alle seine Chunks gleich mit, würde es Chunks zerstören, die noch von anderen Snapshots gebraucht werden.

Deshalb der Zweischritt:

1. Prune löscht den Snapshot-Eintrag (Manifest + Index)
2. Garbage Collection prüft alle Chunks: Wird dieser Chunk noch von irgendeinem Snapshot referenziert? Wenn nein → weg.

Wie GC funktioniert

GC läuft in zwei Phasen:

Phase 1 — Mark

PBS geht durch alle existierenden Snapshots und markiert jedes referenzierte Chunk-File als „in Benutzung”. Das passiert über mtime-Touch — PBS aktualisiert den Modification-Timestamp aller relevanten Chunk-Files auf “jetzt”.

Phase 2 — Sweep

PBS scannt den Chunk-Pool und löscht alle Chunks, deren mtime älter ist als ein konfigurierbares Threshold (Standard: 24h 5min). Das sind die Chunks, die weder in Phase 1 markiert wurden noch frisch von einem laufenden Backup geschrieben werden.

Das 24h-Threshold ist Sicherheit: Chunks, die gerade erst von einem laufenden Backup geschrieben wurden, sollen nicht versehentlich gelöscht werden.

Wo GC konfiguriert wird

Datastore → Prune & GC in der PBS-GUI.

Dort findest Du:

• GC Schedule: wann GC automatisch läuft. Empfehlung: weekly Sun 04:00 — Sonntag früh, wenn nichts los ist.
• Status: wann der letzte Lauf war, wie viele Chunks wegen GC gelöscht wurden, wie lange er dauerte.

Auf der CLI:

proxmox-backup-manager garbage-collection start <datastore>

Wie lange dauert GC?

Hängt von der Datastore-Größe und der Anzahl Chunks ab:

• 100-GB-Datastore: 5–15 Minuten
• 1-TB-Datastore: 30–90 Minuten
• 10-TB-Datastore: 4–10 Stunden
• 50-TB-Datastore: 1–3 Tage

GC ist disk-I/O-intensiv (sie liest jedes Chunk-File). Auf unserer Infrastruktur mit ZFS und NVMe-Caches geht das deutlich schneller als auf reinen HDD-Pools.

Während GC läuft, können Backups parallel weiterlaufen — PBS handhabt das sauber. Du musst keine Wartungsfenster planen.

Was sehe ich nach einer erfolgreichen GC?

Im Task-Log eines abgeschlossenen GC-Laufs:

INFO: starting garbage collection on store <datastore>
INFO: marking used chunks
INFO: marked 145823 chunks
INFO: removed 12384 chunks (size 49.2 GiB)
INFO: pending removals: 0 chunks
INFO: garbage collection finished after 1850s

Wichtige Zeilen:

• marked X chunks: so viele Chunks sind in Benutzung
• removed X chunks (size Y): so viel wurde freigegeben
• pending removals: Chunks, die noch nicht gelöscht wurden (z.B. weil mtime zu jung)

Best Practices

• GC einmal pro Woche ausreicht für die meisten Datastores.
• Nach großen Prune-Aktionen manuell triggern: wenn Du gerade einen Massen-Prune gemacht hast (z.B. eine alte VM komplett aus dem Backup gelöscht), starte GC manuell — sonst dauert’s, bis der Speicher wieder frei ist.
• GC während der Verify nicht parallel laufen lassen: zwei I/O-intensive Jobs gleichzeitig macht den Datastore langsam. Im Schedule auseinander legen (etwa Sonntag GC, Samstag Verify).
• Notifications einrichten: Du willst wissen, wenn GC fehlschlägt — siehe E-Mail-Notifications.

Warum manchmal weniger Speicher freigegeben wird als erwartet

Beispiel: Du hast 100 GB Snapshots geprunt, GC läuft, aber nur 30 GB werden frei. Warum?

Deduplizierung. Die geprunten Snapshots haben sich Chunks mit anderen, noch aktiven Snapshots geteilt. Diese Chunks bleiben — auch wenn der Snapshot, dessen Manifest sie referenzierte, weg ist. Solange ein anderer Snapshot sie braucht, bleiben die Chunks.

Das ist nicht buggy, das ist by design. PBS speichert sehr platzsparend — und der Effekt ist, dass auch beim Pruning nicht so viel Speicher zurückkommt wie naiv gedacht.

Mehr dazu in Speicherverbrauch verstehen.

Häufige Fragen

Was, wenn GC fehlschlägt? Schau ins Task-Log — meistens ist es ein I/O-Fehler oder eine korrupte Chunk-Datei. Wir betreuen unsere Datastores mit ZFS-Scrub und Hardware-Monitoring; bei Fehlern auf unserer Seite kontaktieren wir Dich.

Kann ich GC manuell stoppen? Ja, im Task-Fenster auf “Stop”. GC fährt sauber runter — keine Datenkorruption, kein halb-fertiger Zustand. Du startest sie später einfach neu.

Warum dauert GC länger als das Backup selbst? GC liest jedes Chunk-File auf der Festplatte — auch die, die nicht referenziert sind. Backup schreibt nur die neuen Chunks. Daher ist GC immer langsamer als Backup.

Sind während GC die Backups gefährdet? Nein. Phase 1 (Mark) markiert alle aktiven Chunks. Während Mark eine Backup läuft, werden auch diese neuen Chunks frisch geschrieben (mit aktuellem mtime), und in Phase 2 nicht gelöscht. PBS ist konkurrenzsicher.

Was bedeutet “pending removals”? Chunks, die in Phase 2 nicht gelöscht wurden, weil ihr mtime zu jung ist (innerhalb der 24h-Schwelle). Beim nächsten GC-Lauf werden sie nochmal geprüft — wenn sie immer noch nicht referenziert sind, fliegen sie raus.

Kann ich die 24h-Schwelle ändern? In der CLI ja (--phase1-mode-Optionen), aber wir empfehlen davon ab. Das 24h-Window ist genau der Sicherheits-Puffer gegen Race-Conditions zwischen GC und laufenden Backups.

Warum ist Prune+GC besser als „normales” Datei-Löschen? Weil PBS deduplizierend speichert. Würde es Snapshots wie eine normale Datei behandeln, würde Du den Vorteil der Deduplizierung verlieren. So wie es jetzt ist, kannst Du 50 Snapshots à 100 GB haben, die in Wahrheit nur 150 GB belegen — und Prune+GC räumt das sauber auf.

Weiter geht’s

• Prune erklärt
• Speicherverbrauch verstehen — Deduplizierung & Reporting
• Retention Policies konfigurieren