Tutti i post
infrastructure Pubblicato il 13 March 2026 3 min di lettura

Gestione Backup e Snapshot su Proxmox: GUI vs CLI

Guida tecnica alla programmazione degli snapshot automatici su Proxmox VE: confronto tra backup completi via GUI e snapshot atomici via CLI.

proxmoxhomelabbackuplinuxautomation

Il Problema: Strategie di Disaster Recovery su Proxmox

In un ambiente di produzione o in un homelab avanzato, la persistenza del dato è critica. Proxmox VE offre diverse metodologie per garantire la continuità operativa dei container LXC. Spesso però si confonde il backup completo con lo snapshot, portando a un utilizzo inefficiente delle risorse di storage.

Come possiamo programmare salvataggi automatici che siano rapidi e poco esigenti in termini di spazio?

Approccio standard: La GUI di Proxmox

L’interfaccia web di Proxmox fornisce uno strumento nativo sotto la voce Datacenter -> Backup. Questo permette di creare job schedulati per intere VM o LXC.

Pro

  • Semplicità: Configurazione visuale senza necessità di scrivere script.
  • Ripristino Granulare: Possibilità di ripristinare un intero container su un nuovo ID o su un nodo diverso del cluster.
  • Destinazioni esterne: Supporta nativamente storage NFS, SMB o Proxmox Backup Server.

Contro

  • Pesantezza: Il backup standard (vzdump) crea un archivio compresso del disco. Anche con backup incrementali (se si usa PBS), il carico di I/O è superiore a uno snapshot.
  • Tempo di esecuzione: Il processo di compressione e trasferimento richiede tempo proporzionale alla dimensione del disco.

La “CLI Way”: Snapshot a livello di Filesystem

Per chi cerca l’efficienza massima, la riga di comando permette di sfruttare le capacità atomiche dei filesystem moderni (come ZFS o Thin-LVM) per creare snapshot istantanei. Uno snapshot non copia i dati, ma “congela” lo stato dei blocchi in un determinato istante.

Pro

  • Velocità: La creazione è quasi istantanea (millisecondi).
  • Storage Efficiency: Occupa spazio solo per le differenze (delta) generate dopo lo snapshot.
  • Nessun Downtime: Non c’è bisogno di sospendere il container per lunghi periodi.

Contro

  • Hardware dependent: Richiede filesystem che supportino gli snapshot (ZFS, BTRFS, LVM-Thin).
  • Non è un vero backup: Se il disco fisico si rompe, perdi sia il container che lo snapshot. Lo snapshot serve per il rollback rapido, non per il disaster recovery a lungo termine.

Implementazione: Snapshot automatici via CLI

Per automatizzare gli snapshot via CLI, possiamo utilizzare il comando nativo pct snapshot. Di seguito un esempio di script Bash che può essere inserito in un cron job o in una systemd timer unit.

Lo script

Salviamo lo script in /usr/local/bin/lxc-snap.sh e rendiamolo eseguibile con chmod +x /usr/local/bin/lxc-snap.sh.

#!/bin/bash

CONTAINER_ID=105
SNAPSHOT_NAME="Auto_$(date +%Y%m%d_%H%M%S)"
LOG_FILE="/var/log/proxmox_snapshots.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "Inizio creazione snapshot per LXC $CONTAINER_ID (nome: $SNAPSHOT_NAME)..."

pct snapshot "$CONTAINER_ID" "$SNAPSHOT_NAME" --description "Snapshot automatico programmato"

if [ $? -eq 0 ]; then
    log "SUCCESS: snapshot $SNAPSHOT_NAME creato correttamente."
else
    log "ERROR: creazione snapshot $SNAPSHOT_NAME fallita per LXC $CONTAINER_ID."
    exit 1
fi

La funzione log() antepone un timestamp a ogni riga e scrive sia su file che su stdout — il che risulta utile sia per la consultazione manuale del log che per la cattura da parte di systemd, come vedremo a breve.

Automazione via Cron

Dalla shell di Proxmox, eseguiamo crontab -e e aggiungiamo la seguente riga per schedulare lo script ogni notte alle 03:00:

0 3 * * * root /usr/local/bin/lxc-snap.sh >> /var/log/proxmox_snapshots.log 2>&1

Automazione via Systemd Timer

In alternativa a cron, systemd offre un meccanismo più robusto e integrato basato su due file in formato INI (non YAML): un service unit, che descrive il processo da eseguire, e un timer unit, che ne definisce la schedulazione. Entrambi vanno salvati in /etc/systemd/system/.

Service unit: lxc-snapshot.service

[Unit]
Description=LXC Snapshot automatico via pct
# Se il servizio fallisce (exit code != 0), invia una notifica tramite l'unit di failure
OnFailure=lxc-snapshot-failure@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lxc-snap.sh
# stdout e stderr vengono catturati da journald e scritti anche su file
StandardOutput=append:/var/log/proxmox_snapshots.log
StandardError=append:/var/log/proxmox_snapshots.log

[Install]
WantedBy=multi-user.target

Timer unit: lxc-snapshot.timer

[Unit]
Description=Esegui LXC Snapshot ogni notte alle 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
# Se il sistema era spento all'orario previsto, esegui al prossimo avvio
Persistent=true
Unit=lxc-snapshot.service

[Install]
WantedBy=timers.target

Failure handler: lxc-snapshot-failure@.service

Se lxc-snap.sh termina con exit code diverso da zero, systemd invoca automaticamente questa unit. In questo esempio il fallimento viene registrato su un log dedicato, ma la stessa struttura può essere estesa per inviare una notifica via email o webhook.

[Unit]
Description=Notifica fallimento snapshot LXC (%i)

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo "[$(date \"+%%Y-%%m-%%d %%H:%%M:%%S\")] FAILURE: il servizio %i è terminato con errore." >> /var/log/proxmox_snapshots.log'

Attivazione

Dopo aver salvato i tre file, eseguiamo:

systemctl daemon-reload
systemctl enable --now lxc-snapshot.timer

Per verificare che il timer sia attivo e vedere la prossima esecuzione pianificata:

systemctl list-timers lxc-snapshot.timer

Per consultare i log delle esecuzioni precedenti tramite journald:

journalctl -u lxc-snapshot.service

Nota: Gli snapshot non sostituiscono un backup offsite. Per una strategia di disaster recovery completa, affianca questo sistema a un job vzdump schedulato su storage esterno (NFS, PBS, ecc.).