Come fare il backup delle macchine virtuali Proxmox VE

Cosa configurerete

BackupZit esegue il backup delle macchine virtuali (QEMU) e dei container (LXC) di Proxmox VE senza installare nulla nei guest. Un piccolo agente gira su ogni nodo Proxmox, crea uno snapshot temporaneo di ogni guest, ne legge i dischi e li salva sullo storage scelto. Una console web pianifica i job, conserva lo storico e avvia i ripristini.

• Cosa serve
• 1. Console
• 2. Archiviazione
• 3. Agente sul nodo
• 4. Job di backup
• 5. Backup coerenti
• 6. Copia esterna
• 7. Test di ripristino
• Ripristino
• Configurazione dell'host
• Limiti

Cosa serve

• Uno o più nodi con Proxmox VE 7, 8 o 9 (basati su Debian, quindi va bene il pacchetto Debian dell'agente).
• Un posto per la console BackupZit: una piccola VM Linux con 2 vCPU, 2–4 GB di RAM e un disco da 16–20 GB. La console non memorizza dati di backup, quindi può girare come VM nello stesso cluster.
• Storage per i backup fuori dal nodo Proxmox — per esempio un server Linux o NAS via SFTP, una condivisione SMB, un bucket compatibile S3 o un repository protetto BackupZit (hardened repository). Gli agenti vi scrivono direttamente.
• Rete: gli agenti raggiungono la console sulla porta TCP 8443.

Passo 1 — Installare la console

Su Proxmox il modo più rapido è l'immagine appliance pronta backupzit-appliance.qcow2 dalla pagina di download (Debian, PostgreSQL e la console, già configurati):

1. Create una VM senza disco: 2 vCPU, 2–4 GB di RAM, rete VirtIO.
2. Copiate backupzit-appliance.qcow2 sul nodo e importatelo come disco della VM (sostituite <vmid>):

   qm importdisk <vmid> backupzit-appliance.qcow2 local-lvm

3. Collegate il disco importato come SCSI, impostatelo come disco di avvio e attivate il QEMU guest agent nelle opzioni della VM.
4. Avviate la VM. Il suo schermo mostra l'indirizzo della console web e la password iniziale dell'utente admin. Aprite https://<indirizzo>:8443, accedete e cambiate la password.

Sullo schermo della VM potete accedere come bzadmin per impostare un indirizzo statico, il nome del server e il fuso orario (l'appliance parte in UTC e le pianificazioni seguono il fuso orario della console). Preferite un server Debian, Ubuntu, AlmaLinux o Rocky Linux esistente? Lo script di installazione in una riga della pagina di download fa lo stesso lì.

Passo 2 — Aggiungere una destinazione

Nella console aprite Archiviazione e aggiungete una destinazione. Scelte tipiche per i backup Proxmox:

Lasciate attivo Cifra i backup (AES-256) (predefinito): tutto viene cifrato con AES-256-GCM sul nodo prima di lasciarlo. La console mostra poi una chiave di recupero — stampate il foglio di recupero o salvate la chiave in un password manager, lontano dai backup. Con la chiave, la posizione dello storage e le sue credenziali potete ripristinare anche se perdete la console; senza la chiave nessuno può leggere i backup.

Passo 3 — Installare l'agente su ogni nodo

1. Nella console aprite Agenti e fate clic su Crea token di registrazione. Ottenete un codice di registrazione (BZ1-…) valido 7 giorni e per un numero qualsiasi di macchine.
2. Scaricate il pacchetto Agente Linux — Debian / Ubuntu dalla pagina Agenti sul nodo ed eseguite:

   apt install ./backupzit-agent_*.deb
   backupzit-agent enroll --code "BZ1-..."
   systemctl enable --now backupzit-agent

3. Entro un minuto il nodo compare nella pagina Agenti con l'etichetta Proxmox VE · N guests.

L'agente usa gli strumenti del nodo stesso (qm, pct, pvesm, LVM, ZFS, Ceph). Nella console non vengono memorizzati token API di Proxmox né password di root. In un cluster installate l'agente su ogni nodo.

Passo 4 — Creare il job di backup

1. Aprite Job di backup, create un job e selezionate l'agente del nodo.
2. Scegliete Macchine virtuali (Proxmox VE, Hyper-V, VMware), poi Tutte le VM (e i container) dell’host — i guest creati in seguito vengono inclusi automaticamente — oppure spuntate singoli guest.
3. Scegliete la destinazione del passo 2.
4. Impostate una pianificazione, per esempio ogni giorno lavorativo alle 22:00. I job possono anche ripetersi ogni 15 minuti fino a 12 ore, girare una volta al mese o partire dopo un altro job.
5. Impostate la conservazione. Esempio: 3 più recenti, 7 giornalieri, 4 settimanali, 6 mensili mantengono circa sei mesi di storico con una ventina di punti di ripristino.

Cosa succede a ogni esecuzione:

1. Viene creato uno snapshot Proxmox temporaneo (backupzit_…); il guest continua a girare.
2. Ogni disco viene letto dallo snapshot in blocchi da 1 MiB. I blocchi vuoti non vengono salvati e quelli già presenti nel repository non vengono ricaricati — dopo il primo backup viaggiano in rete solo i dati modificati. Ogni backup resta comunque un punto di ripristino completo.
3. Lo snapshot viene rimosso. La configurazione del guest (CPU, memoria, rete, dischi) viene salvata con il backup.

Poiché i dati invariati vengono salvati una sola volta, una lunga conservazione costa poco spazio in più.

Quali dischi si possono salvare con il guest acceso

I guest spenti possono essere salvati su tutti questi storage. I dischi con Backup: no (backup=0), i dischi fisici in passthrough e i bind mount vengono saltati e segnalati con un avviso.

Passo 5 — Backup coerenti a livello applicativo

Se il QEMU guest agent gira nella VM ed è attivo nelle sue opzioni, Proxmox congela i file system della VM per lo snapshot, così database e applicazioni vengono catturati in uno stato pulito. Senza di esso il backup è coerente come dopo un crash — come dopo un'interruzione di corrente.

In una VM Debian o Ubuntu:

apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Nelle VM Windows installate i VirtIO guest tools. Poi attivate l'agente per la VM sul nodo (effettivo dopo il successivo spegnimento e avvio completi della VM):

qm set <vmid> --agent enabled=1

La pagina di ogni esecuzione mostra, per ogni guest, quali dischi sono stati letti e come è stato catturato.

Passo 6 — Una copia esterna (3-2-1)

La regola 3-2-1: tre copie dei dati, su due supporti diversi, una delle quali fuori sede. Aggiungete un secondo job di tipo Copia di backup, con il job Proxmox come sorgente e una destinazione esterna, come un bucket S3 con Object Lock o un repository protetto in un altro edificio.

• L'agente copia i backup esistenti; le VM non vengono rilette.
• Vengono inviati solo i dati non ancora presenti a destinazione, cifrati con la chiave della destinazione.
• Per impostazione predefinita la copia parte dopo ogni backup del job sorgente; va bene qualsiasi pianificazione, per esempio una volta per notte su una linea lenta.
• La copia ha la propria conservazione, per esempio 7 giornalieri sul NAS e 12 mensili nel cloud.

Le VM si ripristinano dalla copia come dall'originale — VM intere, singoli file e ripristino istantaneo. Altre informazioni sulle copie immutabili nella protezione dal ransomware.

Passo 7 — Dimostrare che i backup si avviano

Blocchi leggibili non dimostrano che una VM si avvii ancora. In Impostazioni → Test di ripristino attivate il Test di avvio per i backup delle VM Proxmox. Il test di ripristino avvia allora ogni VM del backup più recente, una dopo l'altra, sul nodo del job, direttamente dal backup, con un nuovo ID e le schede di rete scollegate per non entrare in conflitto con l'originale — e poi la elimina.

• Una VM supera il test quando il suo QEMU guest agent risponde in tempo, cioè il sistema operativo si è avviato. Le VM senza guest agent lo superano se restano accese per un minuto e vengono mostrate come in esecuzione anziché avviate.
• Durante il test il nodo deve avere memoria libera per una VM in più.
• Inoltre un controllo dei dati (mensile per impostazione predefinita) legge tutti i dati memorizzati e li verifica rispetto al loro checksum, per trovare danni sullo storage stesso prima che il backup serva.

Ripristino

Aprite un'esecuzione di backup (dalla pagina del job o da Attività) e scegliete Ripristina una VM o un container.

VM o container intero

• Ripristino su qualsiasi nodo con l'agente — anche su un nodo di un altro cluster.
• Come nuovo guest con il primo ID libero (predefinito) mentre l'originale continua a girare; la copia riceve nuovi indirizzi MAC. Oppure con l'ID originale dopo l'eliminazione del guest, eventualmente sostituendone uno esistente.
• Scegliete il nome e lo storage dei dischi e se avviare il guest dopo il ripristino.
• Ogni ripristino assegna alle VM un nuovo generation ID (vmgenid), così i domain controller Windows rilevano il ritorno indietro in modo sicuro.

Ripristino istantaneo: la VM gira in pochi secondi

Un ripristino normale dura quanto la copia dei dischi. Con Subito, in esecuzione dal backup l'agente serve i dischi in sola lettura dal backup e avvia una nuova VM le cui scritture vanno in overlay locali. Quando siete soddisfatti, Completa sposta i dischi sullo storage scelto mentre la VM continua a girare (qm disk move); Scarta VM elimina la VM e le sue modifiche. La VM è veloce quanto lo storage di backup, quindi è ideale un repository su disco locale o su una condivisione di rete veloce. Il ripristino istantaneo vale per le VM, non per i container.

Singoli file

Fate clic su Sfoglia file nella tabella dei guest di un'esecuzione. La console legge il disco direttamente dal backup — senza ripristinare nulla prima — e permette di sfogliare NTFS, ext2/3/4 e XFS, anche dentro LVM. Scaricate i file (più file come ZIP) o ripristinateli in una cartella su qualsiasi agente. La navigazione nella console richiede un backup su storage di rete (SFTP, S3, SMB, Azure o repository protetto).

Repliche per i guest più importanti

In Avanzate nel job, Mantieni repliche delle VM aggiorna dopo ogni backup una copia spenta di ogni guest su un altro nodo o cluster. Vengono scritti solo i blocchi modificati — di solito pochi secondi per backup. Se un guest va perso, Avvia replica lo avvia con i dati dell'ultimo backup, senza ripristino.

Dalla riga di comando

Tutto funziona anche senza console, per esempio per ricostruire un nodo dopo un disastro:

backupzit-agent pve list
backupzit-agent pve show    --repo ... latest
backupzit-agent pve restore --repo ... --vmid 100 --new-vmid -1 --storage local-lvm --start latest

Backup dell'host Proxmox stesso

I guest sono solo metà di un nodo: definizioni di storage, rete, utenti, firewall, certificati e impostazioni di ogni VM e container stanno nella sua configurazione. Salvala con un normale job File e cartelle sull'agente del nodo, ad esempio ogni giorno, con i percorsi /etc (include /etc/pve, la rete e /etc/hosts) e /var/lib/pve-cluster (il database di configurazione config.db). Per una copia del database del tutto coerente mentre il nodo è in uso, aggiungi questo come Comando prima del backup e includi anche /root/pve-config.db:

# one-time: apt install sqlite3
sqlite3 /var/lib/pve-cluster/config.db ".backup /root/pve-config.db"

Per ricostruire un nodo guasto: installa la stessa versione di Proxmox VE con lo stesso nome host e indirizzo, installa l'agente, ripristina /etc/network/interfaces e /etc/hosts, ferma il servizio del cluster (systemctl stop pve-cluster), ripristina config.db in /var/lib/pve-cluster, riavvia il servizio e poi ripristina i guest. In un cluster, riunisci al cluster il nodo reinstallato invece di ripristinare config.db.

Limiti da conoscere

• Sono supportati Proxmox VE 7, 8 e 9. XCP-ng non è supportato.
• I dischi dei container su subvolume ZFS non sono ancora supportati.
• I dischi raw su storage directory, NFS o CIFS e i dischi su LVM thick si possono salvare solo con il guest spento.
• In un cluster un job salva i guest del proprio nodo. Un guest migrato su un altro nodo viene segnalato con un avviso — usate Tutte le VM (e i container) dell’host su ogni nodo perché i guest migrati restino coperti.
• Le unità cloud-init non vengono salvate; vengono ricreate dalla configurazione al ripristino.

Prossimi passi

BackupZit è gratuito e open source (AGPLv3), senza limiti di VM o nodi. Scaricatelo, guardate tutte le funzioni per Proxmox o leggete il capitolo completo su Proxmox VE nella guida integrata nella console. Le domande sono benvenute nelle GitHub Discussions. Le aziende possono ottenere supporto commerciale da MaxZit (solo in inglese).