Proxmox Backup Server: garbage collection e prune

Introduzione

Questo tutorial spiega come configurare la manutenzione di Proxmox Backup Server per l'archiviazione dei backup a lungo termine tramite job di prune e garbage collection. Configurerete il prune di Proxmox, pianificherete la garbage collection di Proxmox e stimerete l'utilizzo dello storage, in modo che il datastore non cresca fino a esaurire tutto lo spazio disco disponibile.

Al termine del tutorial avrete una policy di prune pianificata e una pianificazione della garbage collection per un datastore di Proxmox Backup Server, con esempi pratici di retention per backup giornalieri, settimanali e mensili.

Prerequisiti

Prima di iniziare, assicuratevi di disporre di:

• Proxmox Backup Server 4.2.x o successivo
• Un datastore PBS configurato, con backup esistenti o previsti
• Accesso come amministratore all'interfaccia web di Proxmox Backup Server
• Accesso alla shell come root o come altro utente con permessi di amministrazione PBS sufficienti
• Una conoscenza di base dei job di backup di Proxmox VE e dei namespace PBS
• Circa 30 minuti per completare la configurazione

Questo tutorial è destinato ad amministratori di sistema di livello intermedio.

Passaggio 1: comprendere come interagiscono prune e garbage collection

In Proxmox Backup Server, il prune (potatura) e la garbage collection sono operazioni di manutenzione distinte. Capire come interagiscono è essenziale per una gestione efficace dei datastore Proxmox.

Un job di prune decide quali snapshot di backup conservare e quali rimuovere dalla cronologia visibile dei backup. Quando PBS esegue il prune di uno snapshot, rimuove i metadati, gli indici, i log e le note dello snapshot. Non rimuove immediatamente i chunk di backup non utilizzati. I chunk a cui facevano riferimento gli snapshot eliminati vengono rimossi in seguito dalla garbage collection.

La garbage collection (GC) libera spazio nel datastore eliminando i chunk inutilizzati dall'archivio dei chunk. PBS utilizza chunk deduplicati, quindi uno stesso chunk può essere referenziato da più snapshot di backup. Per questo motivo PBS non può eliminare in modo sicuro i chunk nell'istante esatto in cui uno snapshot viene eliminato con il prune. Deve prima verificare che nessuno snapshot rimanente né alcun backup in esecuzione vi faccia ancora riferimento.

PBS utilizza inoltre un periodo di tolleranza (grace period) per la rimozione dei chunk. Durante la GC i chunk vengono contrassegnati e rimossi (mark and sweep), ma quelli che rientrano nel periodo di tolleranza vengono segnalati come rimozioni in sospeso (pending removals) e non vengono eliminati subito. Ciò protegge i backup in esecuzione e tiene conto del comportamento degli access time del filesystem, in particolare con il comune comportamento di mount relatime.

Passaggio 2: verificare la configurazione attuale del datastore

Potete farlo sia dalla CLI sia dall'interfaccia web.

Elencate i datastore disponibili:

proxmox-backup-manager datastore list

Output previsto: tabella con l'elenco dei datastore.

Scegliete il datastore in cui sono archiviati i backup di Proxmox VE. Negli esempi seguenti sostituite <DATASTORE_NAME> con il nome del vostro datastore.

Controllate lo stato attuale della garbage collection:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Dovreste vedere lo stato attuale della GC per il datastore. Se la GC non è mai stata eseguita, l'output potrebbe non mostrare alcuna esecuzione riuscita precedente.

Elencate i job di prune esistenti:

proxmox-backup-manager prune-job list

Dovreste vedere i job di prune esistenti oppure un elenco vuoto se non ne è stato configurato nessuno.

Per verificare tramite l'interfaccia web, andate in Datastore - <DATASTORE_NAME> - Prune & GC Jobs:

Passaggio 3: pianificare una policy di retention dei backup a lungo termine

Una policy di retention deve essere coerente con i requisiti di ripristino e con la capacità di storage. Per molti piani di retention dei backup Proxmox, una policy pratica a lungo termine utilizza lo schema nonno-padre-figlio (grandfather-father-son):

Opzione di retention	Valore di esempio	Risultato
keep-daily	14	Conserva un backup al giorno per 14 giorni di backup
keep-weekly	8	Conserva un backup a settimana per 8 settimane di backup
keep-monthly	12	Conserva un backup al mese per 12 mesi di backup
keep-yearly	2	Conserva un backup all'anno per 2 anni di backup

Le opzioni di retention di PBS vengono elaborate per intervalli di tempo (time bucket). Ad esempio, keep-daily conserva l'ultimo backup di ciascun giorno mantenuto, e i giorni senza backup non vengono conteggiati. keep-weekly conserva l'ultimo backup di ciascuna settimana ISO mantenuta, e le settimane senza backup non vengono conteggiate.

Per una pianificazione di backup giornaliera, iniziate con una di queste policy:

Policy	Impostazioni di retention	Caso d'uso
Conservativa	keep-daily 7 keep-weekly 4 keep-monthly 6	Datastore di piccole dimensioni o cronologia di ripristino breve
Bilanciata	keep-daily 14 keep-weekly 8 keep-monthly 12	Backup tipici di VM e container
A lungo termine	keep-daily 30 keep-weekly 12 keep-monthly 24 keep-yearly 3	Datastore di grandi dimensioni o cronologia richiesta dalla conformità normativa

Passaggio 4: stimare lo storage necessario prima di applicare la retention

La pianificazione dello storage per l'archiviazione dei backup a lungo termine non equivale a moltiplicare la dimensione completa della VM per il numero di snapshot. Proxmox Backup Server utilizza la deduplicazione, quindi ogni nuovo backup di solito memorizza solo i chunk modificati più i metadati. Conviene comunque effettuare una stima prudenziale.

Utilizzate questa formula:

Storage stimato = dati protetti iniziali + dati modificati giornalieri * equivalente dei giorni conservati + margine di sicurezza

Esempio 1: retention bilanciata per un gruppo di VM:

Valore	Esempio
Dati VM protetti	2 TB
Media giornaliera dei dati modificati	80 GB
Policy di retention	14 giornalieri · 8 settimanali · 12 mensili
Margine di sicurezza	25 per cento

Punti di modifica conservati (valore approssimativo):

14 daily + 8 weekly + 12 monthly = 34 restore points

Dati modificati (valore approssimativo):

80 GB * 34 = 2720 GB

Totale approssimativo prima del margine:

2000 GB + 2720 GB = 4720 GB

Aggiungete un margine di sicurezza del 25 per cento:

4720 GB * 1.25 = 5900 GB

Per questo carico di lavoro prevedete circa 6 TB di capacità utilizzabile del datastore.

Esempio 2: policy per un datastore più piccolo:

Valore	Esempio
Dati VM protetti	1 TB
Media giornaliera dei dati modificati	30 GB
Policy di retention	7 giornalieri · 4 settimanali · 6 mensili
Margine di sicurezza	25 per cento

Punti di ripristino (valore approssimativo):

7 + 4 + 6 = 17 restore points

Storage (valore approssimativo):

1000 GB + (30 GB * 17) = 1510 GB
1510 GB * 1.25 = 1887.5 GB

Per questo carico di lavoro prevedete circa 2 TB di capacità utilizzabile del datastore.

Passaggio 5: creare un job di prune nell'interfaccia web

1. Aprite l'interfaccia web di Proxmox Backup Server.
2. Selezionate Datastore.
3. Selezionate <DATASTORE_NAME>.
4. Aprite la scheda Prune & GC.
5. Fate clic su Add Prune Job.
6. Impostate Datastore su <DATASTORE_NAME>.
7. Impostate Namespace se volete eseguire il prune di un solo namespace.
8. Configurate i valori di retention, ad esempio keep-daily a 14, keep-weekly a 8 e keep-monthly a 12.
9. Impostate la pianificazione, ad esempio 03:00.
10. Salvate il job di prune.

Risultato previsto: PBS crea un job di prune pianificato per il datastore o il namespace. Questo job rimuove periodicamente gli snapshot di backup che la vostra policy di retention non seleziona più.

Passaggio 6: creare un job di prune dalla riga di comando

Potete creare lo stesso job di prune anche dalla shell di PBS.

Per un job di prune su tutto il datastore:

proxmox-backup-manager prune-job create pve-longterm \
  --store <DATASTORE_NAME> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term Proxmox backup retention"

Risultato previsto: PBS crea un job di prune denominato pve-longterm.

Per un job di prune specifico per un namespace:

proxmox-backup-manager prune-job create pve-namespace-longterm \
  --store <DATASTORE_NAME> \
  --ns <NAMESPACE> \
  --schedule "03:00" \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --comment "Long-term retention for namespace"

Risultato previsto: PBS esegue il prune solo del namespace selezionato. Ciò è utile quando cluster, tenant o ambienti diversi richiedono policy di retention differenti.

Elencate il job di prune:

proxmox-backup-manager prune-job list

Output previsto: tabella con l'elenco dei job di pulizia dei backup Proxmox.

Passaggio 7: configurare la pianificazione della garbage collection

Dopo che il prune ha rimosso i metadati dei vecchi snapshot, la GC deve essere eseguita per recuperare lo spazio dei chunk inutilizzati. Una pianificazione settimanale della GC è un buon punto di partenza per la maggior parte delle configurazioni.

Impostate una pianificazione settimanale della GC:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --gc-schedule "Sun 04:00"

Potete configurarla tramite l'interfaccia web in Datastore - <DATASTORE_NAME> - Prune & GC Jobs → Garbage Collection Jobs → Edit:

Risultato previsto: PBS pianifica la garbage collection del datastore ogni domenica alle 04:00.

Controllate lo stato della GC:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

L'output previsto include il nome del datastore e informazioni sull'esecuzione della GC più recente o successiva.

Potete anche avviare la GC manualmente:

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

Risultato previsto: PBS avvia un task di GC per il datastore.

Passaggio 8: scegliere una pianificazione sicura per prune e GC

Una pianificazione pratica è la seguente:

Attività	Pianificazione di esempio	Motivo
Job di backup di Proxmox VE	Ogni giorno alle 01:00	Crea prima i nuovi backup
Job di prune PBS	Ogni giorno alle 03:00	Rimuove gli snapshot fuori dalla retention
Job di GC PBS	Ogni domenica alle 04:00	Recupera i chunk inutilizzati dopo il prune

Questo ordine mantiene disponibili i nuovi backup prima che i vecchi snapshot vengano rimossi. Inoltre dà a PBS il tempo di completare le scritture dei backup prima dell'avvio dei task di prune e GC.

Negli ambienti con carico elevato evitate di eseguire contemporaneamente task di backup, verifica, prune, sincronizzazione e GC. Distanziate nel tempo i job di manutenzione per ridurre la contesa di I/O.

Passaggio 9: verificare la configurazione

Elencate i job di prune:

proxmox-backup-manager prune-job list

Verificate che il job abbia il datastore, il namespace, la pianificazione e i valori keep previsti.

Mostrate un job di prune:

proxmox-backup-manager prune-job show pve-longterm

Risultato previsto: PBS mostra le opzioni di retention configurate.

Controllate la configurazione della GC:

proxmox-backup-manager garbage-collection list

Risultato previsto: PBS elenca lo stato della garbage collection di tutti i datastore, inclusi quelli senza job di GC.

Controllate l'utilizzo del datastore dall'interfaccia web:

• Aprite Datastore.
• Selezionate <DATASTORE_NAME>.
• Esaminate l'utilizzo del datastore e la cronologia dei task.
• Aprite Tasks e verificate che i job di prune e GC terminino correttamente.

Risultato previsto: il datastore mostra l'attività di manutenzione pianificata e i vecchi snapshot vengono rimossi in base alla configurazione del prune di Proxmox.

Passaggio 10: monitorare la crescita dello storage nel tempo

Dopo aver configurato i job di prune in PBS, monitorate l'utilizzo dello storage per almeno un intero ciclo di retention. Ad esempio, se configurate keep-monthly 12, servono diversi mesi di dati prima che l'andamento a lungo termine diventi chiaro.

Esaminate queste metriche:

Metrica	Cosa verificare
Spazio utilizzato del datastore	Conferma se l'ottimizzazione dello storage dei backup funziona
Log dei task di prune	Confermano che gli snapshot vengono rimossi
Log dei task di GC	Confermano che i chunk inutilizzati vengono eliminati
Rimozioni in sospeso (pending removals)	Indicano i chunk in attesa del periodo di tolleranza della GC
Andamento della dimensione dei job di backup	Mostra se i dati modificati sono in aumento

Se il datastore continua a crescere più rapidamente del previsto, riducete la retention o aggiungete storage prima che il filesystem si riempia.

Correzioni comuni:

Problema	Correzione
Il datastore si riempie troppo in fretta	Ridurre keep-daily, keep-weekly o keep-monthly
Troppo pochi punti di ripristino recenti	Aumentare keep-daily
La cronologia mensile è troppo breve	Aumentare keep-monthly
I backup si sovrappongono alla manutenzione	Spostare prune o GC a un orario successivo
La GC libera poco spazio	Verificare che i job di prune rimuovano effettivamente i vecchi snapshot

Ripristino delle modifiche

Per rimuovere un job di prune:

proxmox-backup-manager prune-job remove pve-longterm

Risultato previsto: PBS rimuove la configurazione del job di prune.

Per disattivare la pianificazione della GC senza eliminare il datastore:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --delete gc-schedule

Risultato previsto: PBS rimuove la pianificazione automatica della GC per il datastore.

Per modificare la retention invece di rimuovere il job di prune:

proxmox-backup-manager prune-job update pve-longterm \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Risultato previsto: PBS mantiene il job di prune ma applica la nuova policy di retention nelle esecuzioni future.

Risoluzione dei problemi

La GC non libera spazio immediatamente

Causa: il prune ha rimosso i metadati degli snapshot, ma i chunk sono ancora referenziati da altri snapshot oppure rientrano nel periodo di tolleranza della GC.
Soluzione: attendete il termine del periodo di tolleranza ed eseguite di nuovo la GC più tardi. Controllate i log dei task per le rimozioni in sospeso.

Il prune conserva più backup del previsto

Causa: keep-daily, keep-weekly e keep-monthly utilizzano intervalli di tempo. I giorni, le settimane o i mesi senza backup non vengono conteggiati. Inoltre le regole di retention si sovrappongono.
Soluzione: utilizzate il simulatore di prune di PBS prima di modificare la retention in produzione. Questo consente di visualizzare in anteprima il comportamento della retention prima di applicare le modifiche.

Il datastore continua a crescere dopo prune e GC

Causa: i dati modificati ogni giorno possono essere superiori alla stima, i backup possono includere nuovi dischi oppure la retention può essere troppo ampia per il datastore.
Soluzione: ricalcolate la stima del volume con i dati realmente modificati. Riducete la retention o ampliate lo storage.

Il job di prune non ha effetto su un namespace

Causa: il job di prune potrebbe essere configurato per il namespace sbagliato o per una profondità del namespace errata.
Soluzione: controllate le impostazioni del job di prune e verificate il valore di --ns. Se volete che il job si applichi a un solo namespace, impostate il namespace in modo esplicito.

I client di backup possono ancora eliminare i backup

Causa: le credenziali di backup possono avere permessi di eliminazione, oppure la retention può essere configurata al di fuori di PBS.
Soluzione: applicate il principio del privilegio minimo ai client di backup. Per la resistenza al ransomware, preferite i job di prune lato PBS anziché concedere permessi di eliminazione ai client di backup.

Conclusioni

Avete configurato la manutenzione di Proxmox Backup Server per la retention a lungo termine creando un job di prune e pianificando la garbage collection. Avete inoltre appreso perché i chunk non vengono eliminati immediatamente, in che modo la GC completa la pulizia del datastore e come stimare i requisiti di storage prima di applicare la retention a lungo termine. Queste pratiche favoriscono l'ottimizzazione dei backup Proxmox migliorando l'efficienza dello storage e mantenendo la retention dei backup prevedibile e gestibile.

Come passi successivi, aggiungete job di verifica, configurate le notifiche per i task di prune e GC non riusciti e controllate la crescita del datastore ogni mese. In questo modo l'ottimizzazione dello storage dei backup resta prevedibile e le impostazioni di retention non consumano silenziosamente tutta la capacità disponibile.

Versione del documento: 1.0
Ultimo aggiornamento: giugno 2026
Responsabile: Team di documentazione tecnica