Proxmox
Proxmox: snapshot, stop e suspend non fanno lo stesso backup
Le tre modalità di backup bilanciano in modo diverso continuità del servizio e coerenza dei dati. La scelta dipende dalle applicazioni, dal guest agent e dalla finestra di fermo.
La modalità conta quanto la destinazione
Quando si configura un job di backup in Proxmox VE, scegliere snapshot, stop o suspend non è un dettaglio: cambia il rapporto tra disponibilità della macchina virtuale e coerenza dei dati copiati. La documentazione ufficiale descrive tre comportamenti distinti e indica snapshot come modalità predefinita. Le pagine Proxmox consultate il 5 novembre 2026 riportano Proxmox VE 9.2, pubblicato il 21 maggio 2026; prima di applicare una procedura è comunque opportuno verificare la versione realmente installata nel proprio cluster.
Snapshot: continuità quasi totale
In modalità snapshot la macchina virtuale resta attiva durante la copia. È l’opzione con il minor tempo di indisponibilità e, per questo, si adatta bene ai servizi che non possono essere fermati ogni notte. Non va però confusa con una fotografia perfettamente transazionale dell’applicazione: mentre il backup procede, sistema operativo e programmi continuano a modificare memoria e dischi. Proxmox coordina la copia, ma rimane un piccolo rischio di incoerenza applicativa, soprattutto con database o carichi che scrivono intensamente.
Stop: priorità alla coerenza
Con stop, Proxmox esegue un arresto ordinato della macchina virtuale prima del backup e la riavvia se era attiva. La documentazione lo presenta come il modo con la maggiore coerenza, a fronte di una reale interruzione del servizio. È una scelta sensata quando l’applicazione tollera una finestra di manutenzione e il tempo di ripristino del servizio è prevedibile. Prima di adottarla occorre misurare durata del backup, tempi di spegnimento e avvio, perché un job lento può trasformare una breve finestra in un fermo percepibile dagli utenti.
Suspend: compatibilità, non un compromesso universale
Suspend mette in pausa la macchina virtuale, avvia la copia e poi la riprende. Può essere utile per compatibilità con configurazioni particolari, ma non è automaticamente la via di mezzo migliore. Proxmox avverte che può produrre un’interruzione più lunga e non offre necessariamente un vantaggio di coerenza rispetto a snapshot. In assenza di una ragione tecnica verificata, la documentazione raccomanda in genere snapshot. La modalità va quindi provata sul singolo carico, non scelta solo perché il nome sembra meno invasivo di stop.
Il ruolo del QEMU Guest Agent
Per le macchine virtuali, il QEMU Guest Agent può aiutare la modalità snapshot: Proxmox può richiedere il congelamento del file system prima della fase critica e il successivo sblocco tramite fsfreeze e fsthaw. Questo riduce il rischio di file system incoerenti, ma non sostituisce le funzioni applicative. Un database può richiedere hook, dump nativi o procedure application-aware. L’agente deve essere installato nel sistema guest, abilitato nella configurazione della VM e verificato: considerarlo attivo senza controllarne lo stato crea una falsa sicurezza.
Esempio pratico in una piccola azienda
Immaginiamo due VM: un file server usato durante l’orario di lavoro e un gestionale con database. Per il file server si può programmare uno snapshot notturno con QEMU Guest Agent funzionante, conservando una finestra di fermo periodica per test e manutenzione. Per il gestionale, invece, si valuta prima il metodo supportato dal database: dump applicativo seguito dal backup della VM, oppure stop in una finestra concordata se il fermo è accettabile. Dopo il job si controllano log, dimensione e durata; a intervalli regolari si esegue un ripristino isolato, senza collegare la VM restaurata alla rete di produzione.
Limiti da mettere in conto
La modalità di acquisizione non risolve da sola l’intera strategia. Servono retention coerente, spazio sufficiente, monitoraggio degli errori, copie separate dal cluster e prove di ripristino documentate. Proxmox Backup Server può fornire deduplicazione, verifica e gestione delle copie, ma va dimensionato e protetto; una replica sullo stesso storage non copre guasti, cancellazioni o compromissioni comuni. Inoltre VM e container hanno meccanismi differenti, quindi una regola unica può essere sbagliata. La scelta corretta nasce da requisiti di continuità e perdita dati ammessa, non dal semplice valore predefinito.
Fonti e riferimenti
Fonti consultate il 05/11/2026.