DLDanpLab

Proxmox Backup Server 4.2 e S3: backup più resilienti per homelab e PMI

2026-06-01T12:45:59.000Z

Perché questo aggiornamento è importante

Per anni, in un homelab o in una piccola infrastruttura aziendale, la strategia più comune con Proxmox Backup Server era abbastanza lineare: un server PBS locale, datastore su ZFS, job schedulati da Proxmox VE, verifica periodica e magari una replica verso un secondo PBS in un'altra sede. È un approccio semplice, efficiente e molto più serio del classico backup su disco USB dimenticato in un cassetto.

Nel 2026 però il problema non è più soltanto "avere un backup". Il problema è avere un backup che sopravvive a ransomware, errore umano, furto credenziali, incendio, guasto storage e cancellazioni accidentali. Gli attaccanti non cifrano più solo i server: cercano anche NAS, snapshot, repository di backup, credenziali cloud e pannelli di gestione. Se il backup è sempre online e cancellabile dallo stesso dominio amministrativo della produzione, è comodo ma non è abbastanza.

Con Proxmox Backup Server 4.2, rilasciato a fine aprile 2026, Proxmox ha reso ufficiale il supporto agli object store S3-compatible come backend di storage per i datastore. In pratica, PBS può usare storage compatibili S3 come destinazione, aprendo scenari interessanti per copie offsite, repository economici e architetture più resistenti rispetto al singolo disco locale.

Non significa che S3 risolva tutto. Significa che oggi ha senso ripensare il backup Proxmox in modo più maturo: locale per restore veloci, remoto per disastri, regole di retention ben definite e, dove disponibile, immutabilità lato object storage.

Cosa cambia con PBS 4.2

Le novità più interessanti per un SysAdmin sono tre:

  1. S3-compatible object storage supportato ufficialmente come backend per datastore.
  2. Miglioramenti ai sync job, inclusa maggiore parallelizzazione e controllo delle copie.
  3. Cifratura lato server per i trasferimenti di sync, utile negli scenari multi-sede o cloud.

Prima di questo salto, S3 era una possibilità discussa, testata o usata con workaround, ma non era il percorso più lineare per un ambiente stabile. Con il supporto ufficiale, diventa una strada molto più difendibile anche in un contesto professionale: non il posto dove improvvisare il primo backup, ma un livello in più nella strategia.

Per un homelab evoluto o per una PMI con Proxmox VE, il disegno ideale diventa:

Proxmox VE cluster
    ↓ backup schedulato
PBS locale su LAN/ZFS
    ↓ sync o copia offsite
PBS/S3 datastore remoto
    ↓ retention separata
Object storage con policy dedicate

La parte importante è la separazione: credenziali diverse, retention diversa, accesso amministrativo diverso. Se l'attaccante compromette il nodo Proxmox, non deve automaticamente poter cancellare anche la copia remota.

3-2-1-1-0 applicato a Proxmox

La regola classica 3-2-1 dice:

  • 3 copie dei dati;
  • 2 supporti o sistemi diversi;
  • 1 copia offsite.

Oggi molti team ragionano su 3-2-1-1-0:

  • 3 copie;
  • 2 media diversi;
  • 1 copia fuori sede;
  • 1 copia offline o immutabile;
  • 0 errori verificati, cioè backup testati e restore provati.

In ambiente Proxmox, una mappa concreta può essere questa:

| Livello | Dove | Obiettivo | |---------|------|-----------| | Produzione | VM/LXC su Proxmox VE | Servizi attivi | | Backup primario | PBS locale su ZFS | Restore rapido | | Copia offsite | S3-compatible datastore o secondo PBS | Disastro sede/storage | | Immutabilità | Object Lock/WORM dove supportato | Difesa ransomware | | Verifica | PBS verify + test restore | Evitare backup inutilizzabili |

Il punto critico è l'ultima riga. Un backup non verificato è una speranza, non una procedura. PBS aiuta molto perché integra deduplica, prune, garbage collection e verify job, ma bisogna schedularli e guardare gli alert.

Esempio di architettura pratica

Scenario: piccolo ufficio, due nodi Proxmox, NAS o mini-server dedicato per PBS, connettività FTTC/FTTH e budget limitato.

1. PBS locale per restore veloci

Il primo datastore dovrebbe stare vicino ai nodi Proxmox. Idealmente su ZFS, con dischi separati dalla produzione.

# Esempio concettuale: datastore locale PBS
proxmox-backup-manager datastore create local-zfs /backup/datastore

Da Proxmox VE si aggiunge PBS come storage e si schedulano backup notturni:

Datacenter → Backup → Add
Storage: pbs-local
Schedule: 02:00
Mode: snapshot
Compression: zstd

Per VM critiche conviene aumentare la frequenza o aggiungere job separati.

2. Retention chiara

Una retention ragionevole per PMI può essere:

keep-last: 7
keep-daily: 14
keep-weekly: 8
keep-monthly: 6

Non è una regola universale. Dipende da spazio, RPO/RTO e requisiti legali. Però è meglio di "tengo tutto finché il disco esplode".

3. Copia S3/offsite

Con PBS 4.2 ha senso valutare un datastore S3-compatible per la seconda copia. Può essere un provider tipo Wasabi, Backblaze B2 compatibile S3, MinIO in altra sede, oppure storage S3 aziendale.

La logica è:

PBS locale
    → sync/copia verso datastore remoto
    → credenziali dedicate solo al bucket necessario
    → lifecycle e retention lato provider

Le credenziali S3 non devono essere le stesse usate per amministrare tutto l'account cloud. Devono avere permessi minimi: bucket specifico, path specifico, niente privilegi inutili.

Attenzione: S3 non vuol dire automaticamente immutabile

Questo è il punto dove molti si confondono. Usare S3 non significa automaticamente avere backup immutabili. L'immutabilità vera dipende da funzionalità come Object Lock, modalità governance/compliance, versioning e policy WORM lato provider.

In altre parole:

S3 datastore ≠ backup immutabile garantito
S3 + Object Lock configurato bene + credenziali limitate = difesa molto più forte

Se il provider S3 supporta Object Lock, bisogna configurarlo prima di caricare dati, definire retention coerenti e separare l'account che scrive backup dall'account che può modificare policy. Se invece si usa un semplice bucket cancellabile con una chiave admin, si è solo spostato il problema dal NAS al cloud.

Per un homelab può bastare anche una soluzione più semplice: secondo PBS spento o raggiungibile solo durante la finestra di sync, disco offline ruotato manualmente, oppure bucket S3 con credenziali molto limitate. Per una PMI, invece, conviene documentare bene accessi, retention e test di restore.

Checklist operativa per SysAdmin

Prima di dichiarare "siamo coperti", io controllerei questi punti:

  • [ ] PBS aggiornato e monitorato.
  • [ ] Backup job schedulati per tutte le VM/LXC importanti.
  • [ ] Retention definita e non lasciata al caso.
  • [ ] Verify job attivo almeno settimanalmente.
  • [ ] Garbage collection pianificata.
  • [ ] Copia offsite realmente separata dalla produzione.
  • [ ] Credenziali S3 dedicate e con privilegi minimi.
  • [ ] Alert via email/Discord/Teams in caso di errore.
  • [ ] Test restore documentato almeno una volta al mese.
  • [ ] Procedura scritta per recuperare una VM senza dipendere dalla memoria del SysAdmin.

Un esempio di test restore minimo:

1. Scegli una VM non critica.
2. Ripristinala con un nome diverso.
3. Avviala su rete isolata.
4. Verifica boot, login, servizi e dati applicativi.
5. Documenta tempo di restore e problemi trovati.

Questa parte è noiosa, ma è quella che fa la differenza il giorno in cui serve davvero.

Errori comuni

Backup sullo stesso storage della produzione

Se il datastore PBS sta sullo stesso array dei dischi VM, un guasto storage può portarsi via tutto. Può andare bene per test, non per produzione.

Nessuna verifica

PBS può fare verify dei backup. Se non lo usi, stai rinunciando a una delle funzioni più utili.

Chiavi troppo potenti

Una chiave S3 con permessi admin è comoda, ma pericolosa. Meglio una chiave dedicata e limitata.

Nessun isolamento amministrativo

Se Proxmox, PBS, NAS, S3 e password manager sono tutti accessibili con la stessa identità, l'attaccante ha un percorso troppo facile.

Mai provato un restore

Il restore è l'unica metrica che conta. Non importa quanto è elegante la dashboard: se non ripristini, non sai se il backup funziona.

Conclusione

Proxmox Backup Server 4.2 rende più interessante e più professionale l'uso di object storage S3 nelle infrastrutture Proxmox. Per homelab e PMI è una buona notizia: si può costruire una strategia offsite più solida senza per forza comprare appliance costose o software enterprise.

La cosa importante è non vendersi illusioni. S3 è un backend, non una bacchetta magica. La resilienza nasce dalla combinazione di backup locale, copia remota, credenziali separate, retention sensata, possibile immutabilità e test restore periodici.

Se dovessi implementarlo oggi in un ambiente piccolo, partirei così: PBS locale su ZFS, verify settimanale, sync verso datastore remoto S3-compatible, credenziali minime, alert automatici e un test restore mensile. È semplice, sostenibile e soprattutto difendibile quando qualcosa va storto.

Fonti e spunti

  • Proxmox: rilascio di Proxmox Backup Server 4.2 con supporto ufficiale a S3-compatible object stores.
  • Proxmox PBS Roadmap: S3-compatible object stores promossi da technology preview a backend supportato.
  • Help Net Security: riepilogo delle novità PBS 4.2, inclusi S3, sync paralleli e cifratura server-side.
  • Discussioni community Proxmox su Object Lock, S3 e backup immutabili.