Snapshot VM su Proxmox: best practice

Gli snapshot in Proxmox VE sono uno strumento potente ma spesso usato in modo improprio. Forniscono un punto di ripristino veloce per cambiamenti rischiosi, ma non sostituiscono un backup. Capirne i meccanismi e i limiti aiuta a evitare sorprese sgradevoli.

Come funzionano gli snapshot

Uno snapshot Proxmox congela uno stato del disco virtuale (e opzionalmente della RAM) creando un layer differenziale. Le scritture successive vanno in un file delta, lasciando intatto il volume base. Su storage qcow2 il delta si accumula nello stesso file; su ZFS e LVM-thin viene creato un dataset/volume separato. Su LVM "spesso" lo snapshot ha allocazione fissa e va dimensionato bene.

Snapshot con RAM

Quando crei uno snapshot con l'opzione Includere RAM, Proxmox salva anche lo stato della memoria via QEMU. Il rollback ripristina anche la sessione viva (processi, connessioni TCP). E utile per testare aggiornamenti o configurazioni delicate, ma rallenta sensibilmente snapshot e ripristino.

Limiti e impatto sulle prestazioni

Mantenere snapshot a lungo termine porta a degrado di I/O: ogni scrittura sul volume base implica copy-on-write o delta crescente. Le prestazioni si deteriorano in modo non lineare. Best practice: usa snapshot come buffer di test, eliminandoli o consolidandoli entro 24-72 ore. Per backup veri usa Proxmox Backup Server o esporta su storage esterno.

Procedura passo-passo

1. Prima di un cambio rischioso, crea uno snapshot con nome significativo (es. pre-upgrade-php8).
2. Includi la RAM solo se necessario; richiede VM accesa.
3. Esegui il cambio e verifica funzionalita.
4. Se tutto e ok, rimuovi lo snapshot per consolidare i delta.
5. Se fallisce, usa Rollback dalla GUI Proxmox.
6. Mai accumulare più di 2-3 snapshot per VM.
7. Monitora lo spazio del datastore (snapshot consumano spazio).
8. Documenta nel changelog le motivazioni di ogni snapshot.

Snapshot vs backup

Lo snapshot e non un backup: vive sullo stesso storage della VM. Se il datastore si guasta, sia VM che snapshot sono persi. Per disaster recovery serve un backup off-site: Proxmox Backup Server con repository ZFS o cloud, o esportazioni periodiche con vzdump.

Errori comuni e come risolverli

• Snapshot lasciati per settimane: degrado prestazionale e rischio di saturazione disco.
• Snapshot su LVM thick senza spazio: la scrittura puo fallire e corrompere la VM.
• Confondere snapshot e clone: clone duplica la VM, snapshot e solo un punto di ripristino.
• Affidarsi solo agli snapshot per HA: serve replica o cluster con storage condiviso.

Domande frequenti

D: Posso usare snapshot su VM con database attivi?
R: Si ma rischi inconsistenza; quiesce con fsfreeze o snapshot interni del DB sono più sicuri.

D: Posso fare snapshot in cluster?
R: Si, se lo storage e condiviso e supporta snapshot (ZFS, Ceph, LVM thin).

D: Quanti snapshot posso tenere?
R: Tecnicamente molti, in pratica 2-3 per evitare degrado.

Approfondimento tecnico: qcow2, ZFS, Ceph

Il comportamento degli snapshot dipende dallo storage backend. Con qcow2 (file unico per VM su NFS/locale) lo snapshot e una "catena" interna al file: ogni snapshot aggiunge un layer differenziale. Maggiore la catena, peggiore la performance e maggiore il tempo di consolidamento.

Con ZFS, gli snapshot sono istantanei e nativi del filesystem: occupano spazio solo per i blocchi cambiati (copy-on-write). Possono essere mantenuti a centinaia senza degrado. Con Ceph RBD, gli snapshot sono altrettanto efficienti, con il vantaggio di essere distribuiti tra i nodi del cluster. Con LVM thin, gli snapshot funzionano ma richiedono allocazione dinamica del pool: monitora data percent per evitare saturazione.

Scenari d'uso reali

Un amministratore prima di un'upgrade WordPress massiccio crea snapshot della VM web con RAM: rollback istantaneo in caso di problemi.

Un tester QA snapshot la VM all'inizio del giorno, lavora, rollback alla sera: ambiente sempre pulito.

Un cluster ZFS con replica zfs send/recv distribuisce snapshot incrementali a un sito di DR ogni 15 minuti: RPO bassissimo.

Checklist operativa snapshot

• Nomina gli snapshot con timestamp e motivazione.
• Massimo 2-3 snapshot per VM.
• Eliminazione entro 24-72 ore.
• Mai usare snapshot come backup permanente.
• Verifica spazio storage prima di creare snapshot.
• Documenta l'effetto delle operazioni in changelog.
• Snapshot con RAM solo quando necessario.

Risorse e riferimenti

pve.proxmox.com/wiki/Snapshots e documentazione qcow2, ZFS, LVM-thin. Per backup veri: Proxmox Backup Server (PBS) con deduplica e incrementali. vzdump tool nativo per export/restore. Per scenari ibridi, Veeam Backup & Replication supporta Proxmox dal 2024.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su snapshot vm su proxmox richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.