2 nuovi metodi per automatizzare snapshot Proxmox delle VM

Due metodi pratici per automatizzare gli snapshot Proxmox delle VM

Se gestisci un cluster Proxmox e vuoi automatizzare gli snapshot delle VM senza affidarti ogni volta al click nel pannello, i due approcci più solidi sono questi: usare un hook script agganciato al ciclo di vita della VM, oppure schedulare uno script esterno che chiama API Proxmox o CLI con logica di retention. In entrambi i casi il punto non è solo “creare uno snapshot”, ma farlo in modo ripetibile, tracciabile e con un minimo di sicurezza operativa.

Qui sotto trovi una guida pratica, orientata all’uso reale: quando scegliere un metodo, come implementarlo, quali controlli fare prima e dopo, e come evitare di trasformare gli snapshot in una falsa strategia di backup.

Quando usare gli snapshot e quando no

Uno snapshot non è un backup. È una fotografia puntuale dello stato del disco della VM, utile per:

• prima di un aggiornamento applicativo o di sistema;
• prima di modifiche a configurazione o pacchetti;
• per avere un rollback rapido entro una finestra temporale breve;
• per ambienti test, staging o sviluppo con frequenti cambiamenti.

Non usarli come sostituto del backup se ti serve:

• protezione contro guasti del datastore;
• retention lunga;
• recupero da cancellazioni o corruzioni storiche;
• copie fuori dall’host o fuori dal cluster.

Su Proxmox, la qualità operativa dello snapshot dipende molto dallo storage sottostante e dal tipo di disco virtuale. Se usi storage che supporta snapshot coerenti e VM con agent installato, l’esperienza migliora. Se invece il backend è lento o il disco è molto attivo, lo snapshot può impattare le performance.

Metodo 1: hook script con logica automatica

Il primo metodo è il più elegante quando vuoi legare l’automazione a un evento della VM o incapsulare una procedura standard. Proxmox supporta gli hook script per VM e container: uno script viene richiamato in determinati momenti del ciclo di vita della macchina virtuale. Non è pensato solo per snapshot, ma puoi usarlo per orchestrare azioni prima o dopo operazioni specifiche.

Per gli snapshot programmati, il pattern più utile è questo: uno script esterno definisce il nome snapshot, controlla che la VM sia in uno stato compatibile, crea lo snapshot e applica una retention semplice. In pratica il hook script diventa il punto di aggancio per standardizzare il processo.

Perché è utile

• centralizzi la logica in un solo punto;
• riduci errori manuali;
• puoi aggiungere controlli preliminari, logging e retention;
• funziona bene se hai poche VM critiche da trattare in modo uniforme.

Limite principale

Il limite è che il hook script, da solo, non sostituisce una pianificazione vera e propria. Per fare snapshot a orari fissi di più VM, di solito lo combini con cron o systemd timer. Quindi la parte forte del metodo è la logica, non la schedulazione.

Esempio operativo con script esterno richiamato da timer

Un approccio robusto è salvare uno script in /usr/local/sbin/pve-snapshot.sh e richiamarlo via cron o systemd timer. Lo script può usare qm snapshot per le VM e mantenere un numero limitato di snapshot per macchina.

#!/bin/bash
set -euo pipefail

VMID="101"
SNAP_PREFIX="auto"
KEEP=3
DATE="$(date +%F-%H%M)"
SNAP_NAME="${SNAP_PREFIX}-${DATE}"
LOG="/var/log/pve-snapshot-${VMID}.log"

exec >>"$LOG" 2>&1

echo "[$(date -Is)] start snapshot ${VMID} ${SNAP_NAME}"
qm snapshot "$VMID" "$SNAP_NAME" --description "Automated snapshot ${SNAP_NAME}"

mapfile -t snaps < <(qm listsnapshot "$VMID" | awk '/^\s*[0-9]+/{print $2}' | grep "^${SNAP_PREFIX}-" | sort)
count="${#snaps[@]}"
if [ "$count" -gt "$KEEP" ]; then
  delete_count=$((count-KEEP))
  for ((i=0; i<delete_count; i++)); do
    old="${snaps[$i]}"
    echo "[$(date -Is)] delete snapshot ${old}"
    qm delsnapshot "$VMID" "$old" --force 1
  done
fi

echo "[$(date -Is)] done"

Questo esempio è volutamente semplice. Prima di usarlo in produzione, va adattato con controlli aggiuntivi: VM in stato coerente, spazio libero sul datastore, finestra oraria, esclusioni per VM molto attive, e soprattutto test su una macchina non critica.

Schedulazione con systemd timer

Se vuoi qualcosa di più pulito del cron, usa systemd timer. Ti dà log migliori, stato consultabile e meno ambiguità sui permessi.

[Unit]
Description=Snapshot automatico Proxmox VM 101

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/pve-snapshot.sh

Timer:

[Unit]
Description=Esegue snapshot automatico Proxmox ogni notte

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Con questo schema, il vantaggio è che puoi vedere subito se il job è partito, fallito o ha accumulato ritardi.

Metodo 2: automazione via API Proxmox o CLI centralizzata

Il secondo metodo è quello che consiglio quando devi gestire più VM, più host o una retention più articolata. Invece di legare l’azione al singolo host o al singolo evento, costruisci un job centralizzato che interroga Proxmox e crea snapshot su una lista di VM definite da tag, gruppo, nome o file di inventario.

Qui hai due varianti:

• CLI locale: usi qm snapshot direttamente sul nodo Proxmox;
• API Proxmox: chiami le API HTTPS con un token dedicato e fai orchestration da un server esterno.

La CLI è più semplice e veloce da mettere in piedi. L’API è più adatta se vuoi centralizzare, integrare con Ansible, GitLab CI, script Python o un sistema di scheduling esterno.

Quando scegliere la CLI

La CLI va bene se:

• hai un singolo nodo o pochi nodi;
• lo script gira direttamente sul server Proxmox;
• vuoi minimizzare dipendenze e complessità;
• non ti serve una integrazione esterna.

Quando scegliere l’API

L’API è la scelta migliore se:

• vuoi eseguire il job da un server di management;
• hai bisogno di auditing centralizzato;
• vuoi integrare policy, tag, blacklist e retention più ricche;
• vuoi evitare accesso SSH al nodo per l’automazione.

Per l’API, usa sempre un token dedicato con privilegi minimi. Evita password in chiaro negli script. Se devi salvare credenziali, usa un secret manager o almeno un file protetto con permessi stretti.

Esempio di flusso con API

Il flusso tipico è questo:

1. recuperi la lista delle VM target;
2. verifichi stato, tag o policy;
3. crei lo snapshot con nome standard;
4. attendi il completamento della task Proxmox;
5. applichi retention eliminando gli snapshot vecchi.

Con l’API, uno script Python o Bash può chiamare gli endpoint di Proxmox e leggere il ticket o il task ID. Il vantaggio è la flessibilità: puoi includere filtri per cluster, nodo, tag o commenti. Se hai molte VM, questo approccio scala meglio del “uno script per VM”.

Esempio minimo con CLI centralizzata

Se vuoi restare semplice, puoi fare un job Bash che legge una lista di VM da un file e lancia gli snapshot sul nodo corretto. Per esempio:

#!/bin/bash
set -euo pipefail

DATE="$(date +%F-%H%M)"
LIST="/etc/pve-snapshot/vms.txt"
KEEP=5

while read -r VMID NODE; do
  [ -z "${VMID:-}" ] && continue
  echo "Snapshot VM ${VMID} su ${NODE}"
  ssh "root@${NODE}" "qm snapshot ${VMID} auto-${DATE} --description 'Automated snapshot ${DATE}'"
done < "$LIST"

Questo non è il design più raffinato, ma è immediato. In produzione va migliorato con controllo errori, logging strutturato e gestione del parallelismo. Se fai snapshot su molte VM insieme, rischi di impattare storage e I/O.

Best practice da non saltare

Qualunque metodo scegli, ci sono regole pratiche che fanno la differenza tra automazione utile e disastro annunciato.

1. Definisci una convenzione di naming

Usa un nome snapshot che permetta sorting e retention automatica. Esempio: auto-YYYY-MM-DD-HHMM. Evita nomi generici come test o backup, perché diventano ingestibili quando crescono.

2. Limita il numero di snapshot

Lasciare decine di snapshot su una VM è un errore classico. Impatta gestione, performance e spesso anche la chiarezza operativa. Una retention semplice, come 3 o 5 snapshot, è spesso sufficiente per rollback rapidi.

3. Verifica lo stato del datastore

Prima di creare snapshot automatici, controlla spazio libero e salute storage. Se il datastore è quasi pieno, uno snapshot può fallire o peggiorare la situazione. Un controllo minimo può essere fatto con metriche del nodo o con pvesm status e i log del sistema.

4. Usa il guest agent se disponibile

Se la VM ha il guest agent installato e supportato, puoi migliorare la coerenza delle operazioni. Non sempre risolve tutto, ma aiuta in molte procedure di manutenzione.

5. Logga sempre

Ogni snapshot automatico dovrebbe lasciare traccia: VMID, nome snapshot, esito, orario, eventuale errore. Senza log, l’automazione diventa una scatola nera e la diagnosi si allunga inutilmente.

6. Separa test e produzione

Prima di applicare la procedura a VM critiche, prova su una VM non essenziale con lo stesso tipo di storage. È il modo più rapido per scoprire se il problema è la sintassi, il backend storage o la policy di permessi.

Controlli prima di mettere tutto in produzione

Prima di attivare la schedulazione, fai questi controlli minimi:

1. esegui manualmente lo script su una VM di test;
2. verifica che lo snapshot compaia in qm listsnapshot <VMID>;
3. controlla i log in /var/log/ o nel journal di systemd;
4. simula il caso di errore, ad esempio storage quasi pieno o VM spenta, e osserva il comportamento;
5. conferma che la retention rimuova solo gli snapshot attesi.

Se usi systemd, controlla con:

systemctl status pve-snapshot.timer
systemctl status pve-snapshot.service
journalctl -u pve-snapshot.service -n 50 --no-pager

Se usi cron, verifica l’output del job e il file di log dedicato. L’obiettivo è capire subito se il job parte, se fallisce e se lascia residui.

Problemi tipici e come riconoscerli

Gli snapshot automatici falliscono spesso per cause ripetitive:

• storage insufficiente: errore durante la creazione o il merge; verifica spazio e alert del datastore;
• permessi insufficienti: tipico quando il job gira da utente non privilegiato o con token troppo limitato;
• VM molto attiva: lo snapshot può essere lento o impattante;
• naming collision: snapshot con nome già esistente;
• timeout o task bloccata: controlla i task ID e i log di Proxmox.

Se un job fallisce, non forzare subito una cancellazione o una pulizia massiva. Prima individua il punto esatto: creazione snapshot, attesa task, retention o cleanup. È lì che si capisce se il problema è logico, infrastrutturale o di permessi.

Quale dei due metodi scegliere

Se hai poche VM e vuoi una soluzione veloce, il metodo con CLI locale + cron o systemd timer è il più rapido da mettere in produzione. Ti dà controllo diretto e pochi componenti.

Se invece hai un ambiente più ampio, con più nodi o bisogno di governance, meglio l’approccio API centralizzata. È più pulito per auditing, integrazione e manutenzione nel tempo.

Il hook script è utile come componente di supporto o come meccanismo per standardizzare azioni collegate alla VM, ma da solo non è la risposta completa per una pianificazione complessa. In pratica: hook script per automatizzare il comportamento, API/CLI per orchestrare la schedulazione.

Conclusione operativa

Automatizzare gli snapshot Proxmox ha senso solo se lo fai con limiti chiari: naming coerente, retention, log e controllo dello storage. Il resto è dettaglio implementativo. Il punto è scegliere l’architettura giusta per il tuo numero di VM e il tuo livello di governance.

Se vuoi partire in modo semplice, usa uno script locale con qm snapshot e un timer. Se vuoi scalare e integrare bene, passa all’API con token dedicato e inventario centralizzato. In entrambi i casi, testa prima su una VM non critica e mantieni sempre un rollback chiaro: cancellare lo snapshot o ripristinare la VM al punto precedente, quando la finestra operativa lo consente.

Assunzione: l’ambiente è un Proxmox VE recente con accesso shell amministrativo o API abilitata, e gli snapshot sono supportati dallo storage usato dalle VM.