Proxmox Replica: WAN Lenta, RPO Basso

Proxmox VE è una soluzione di virtualizzazione robusta e versatile, ma la gestione della replica tra sedi con collegamenti WAN lenti presenta sfide specifiche. Implementare una strategia di Disaster Recovery (DR) efficace è cruciale per la business continuity. Questo articolo esplora come configurare la replica asincrona in Proxmox, ottimizzando l’uso della banda disponibile e garantendo un Recovery Point Objective (RPO) accettabile, anche con un link da 100 Mbps.

Quando ho dovuto progettare la DR per un cliente con due data center collegati da una fibra da 100 Mbps, ho capito subito che la replica sincrona era fuori discussione. La saturazione del link avrebbe paralizzato le applicazioni critiche. L’obiettivo era replicare oltre 300 VM, alcune delle quali con decine di gigabyte di dati che cambiavano frequentemente, garantendo un RPO massimo di un’ora. La soluzione è stata una configurazione meticolosa della replica asincrona di Proxmox, sfruttando compressione, rate limiting e una schedulazione intelligente per non impattare le operazioni quotidiane.

Testato su: Proxmox VE 8.2 · ZFS · Agosto 2026

Prerequisiti / Ambiente di test

Per configurare la replica asincrona tra due sedi, sono necessari i seguenti prerequisiti:

Due nodi Proxmox VE: Installati e configurati, con accesso SSH reciproco. Idealmente, i nodi dovrebbero essere parte di un cluster Proxmox, ma la replica può funzionare anche tra nodi standalone configurati manualmente.
Storage condiviso o dedicato: Sul nodo di destinazione, è necessario uno storage (ZFS, LVM-Thin, directory) dove verranno salvate le repliche delle VM. Assicurati che lo storage abbia spazio sufficiente.
Connettività di rete: Un collegamento WAN tra i due siti. Per i test, ho simulato una banda di 100 Mbps con una latenza media di 20ms.
Credenziali SSH: L’utente root di Proxmox deve poter accedere via SSH al nodo remoto senza password (tramite chiave SSH) per automatizzare il trasferimento dei dati. Leggi anche: SSH Senza Password Linux: Configurare le Chiavi in 5 Minuti (2026)

1. Configurazione del Target di Replica Remoto

Il primo passo è configurare il nodo Proxmox di destinazione come target per la replica. Questo può essere fatto tramite l’interfaccia web (GUI) o da riga di comando.

Aggiunta del nodo remoto via GUI

Accedi alla GUI del nodo Proxmox sorgente.
Vai su Datacenter -> Storage.
Clicca su Add e seleziona Proxmox Backup Server (anche se non è un PBS, possiamo usarlo per configurare un target remoto generico via SSH) o Directory se stai replicando su una cartella specifica via NFS/CIFS.
L’approccio più comune e flessibile per la replica tra nodi Proxmox è configurare il target direttamente dal pannello di replica per ogni VM, che userà SSH.

Configurazione manuale dell’SSH per la replica

Assicurati che il nodo sorgente possa raggiungere il nodo destinazione via SSH. Se non l’hai già fatto, copia la chiave pubblica SSH del nodo sorgente al nodo destinazione:

ssh-copy-id root@<IP_NODO_DESTINAZIONE>

Verifica la connessione:

ssh root@<IP_NODO_DESTINAZIONE> 'pveversion'

2. Creazione della Replica Asincrona per una VM

Ora configuriamo la replica per una macchina virtuale specifica. Questo può essere fatto sia dalla GUI che dalla CLI. La CLI offre maggiore controllo sui parametri di ottimizzazione.

Via Interfaccia Web (GUI)

Seleziona la VM che vuoi replicare nel pannello di sinistra.
Vai alla sezione Replication.
Clicca su Add.
Nel campo Target, seleziona il nodo Proxmox remoto (se è parte di un cluster) o il Proxmox Backup Server configurato in precedenza (se lo hai usato come workaround per il target remoto).
Schedule: imposta la frequenza di replica (es. every hour).
Bandwidth limit: cruciale per WAN lente. Imposta un valore (es. 10MB/s per 80 Mbps, lasciando un margine sui 100 Mbps disponibili).
Compression: seleziona ZSTD per la migliore efficienza.
Rate Limit: specifica un limite in MB/s o Mbit/s.
Prune: configura la retention delle repliche.
Clicca su Create.

Via Riga di Comando (CLI) – Controllo Ottimale

La CLI permette di specificare tutti i parametri con precisione. Useremo il comando pvesr create.

pvesr create <VMID> --target <nome_storage_remoto> --schedule '*/30 * * * *' --rate 10M --compress zstd --remote <nome_nodo_remoto>

Spiegazione dei parametri:

: ID della macchina virtuale da replicare.
--target : Il nome dello storage sul nodo di destinazione dove la VM sarà replicata (es. local-zfs-remote). Questo storage deve essere raggiungibile e avere spazio.
--schedule '/30 ': La pianificazione in formato cron. Questo esempio replica ogni 30 minuti. Puoi usarne una meno frequente (es. 0 * per ogni ora).
--rate 10M: Limita la banda a 10 Megabyte al secondo (circa 80 Mbps). Questo è fondamentale per non saturare un link da 100 Mbps. Sperimenta con questo valore in base al traffico di produzione e alla banda disponibile. Leggi anche: UFW Firewall Ubuntu: Configurazione Completa dalla A alla Z (2026)
--compress zstd: Abilita la compressione Zstandard. ZSTD offre un ottimo bilanciamento tra velocità di compressione/decompressione e rapporto di compressione, riducendo significativamente la quantità di dati trasmessi.
--remote : Il nome o l’IP del nodo Proxmox di destinazione. Se i nodi sono in un cluster, sarà il nome del nodo. Se standalone, l’IP.

Esempio pratico per la VM 101, replicata ogni ora, con limite di 10MB/s e compressione ZSTD su un nodo remoto chiamato pve-remote e storage zfs-pool-backup:

pvesr create 101 --target zfs-pool-backup --schedule '0 * * * *' --rate 10M --compress zstd --remote pve-remote

Per visualizzare lo stato delle repliche configurate:

pvesr list

3. Monitoraggio e Tuning

Dopo aver configurato la replica, è essenziale monitorarne le prestazioni e il consumo di banda.

Log di Proxmox: Controlla i log di sistema (journalctl -f o /var/log/syslog) per verificare l’avanzamento delle repliche e rilevare eventuali errori.
Monitoraggio Rete: Utilizza strumenti come iftop, nload o il monitoraggio integrato del router/firewall per verificare l’effettivo consumo di banda durante i periodi di replica. Verifica che il rate impostato venga rispettato e che non ci siano picchi inattesi.
RPO: Calcola il Recovery Point Objective effettivo. Se la replica impiega più tempo del previsto per completarsi, potresti dover ridurre la frequenza di replica o aumentare leggermente il rate se la banda lo consente.
Dimensionamento: Assicurati che lo storage di destinazione sia sufficientemente dimensionato per contenere le repliche e gli eventuali snapshot che Proxmox crea durante il processo. Leggi anche: LVM Snapshot: Rollback Sicuro per Aggiornamenti Critici

Errori comuni e troubleshooting

SSH Connection Refused/Permission Denied: Assicurati che le chiavi SSH siano state copiate correttamente e che l’utente root possa accedere senza password al nodo remoto. Controlla il firewall (ufw status o firewall-cmd --list-all) per assicurarti che la porta 22 sia aperta.
Storage Not Found/Full: Verifica che il nome dello storage di destinazione sia corretto e che ci sia spazio disponibile. Controlla i permessi dello storage sul nodo remoto.
Replica lenta o non completa: Aumenta il rate o diminuisci la frequenza dello schedule. Verifica la latenza e la perdita di pacchetti sulla WAN (ping, mtr). La compressione ZSTD aiuta molto, ma dati già compressi (es. immagini JPG, video) non beneficeranno molto di ulteriore compressione.
VM bloccata durante la replica: Questo è raro con la replica asincrona, ma se accade, verifica lo stato dello storage sorgente e destinazione. Potrebbe indicare problemi di I/O o snapshot che non vengono rilasciati correttamente. Assicurati che il qemu-guest-agent sia installato e funzionante all’interno delle VM per snapshot consistenti.

FAQ — Domande Frequenti

La replica asincrona impatta le performance delle VM sorgente?

Sì, ma in modo minimo. La creazione dello snapshot (che è il punto di partenza per la replica) può causare un breve picco di I/O. Il trasferimento dei dati avviene in background e l’impatto sul disco è principalmente sul nodo di destinazione. Con ZFS e LVM-Thin, gli snapshot sono molto efficienti e l’overhead è trascurabile nella maggior parte dei casi.

Posso replicare VM tra versioni diverse di Proxmox VE?

È generalmente raccomandato mantenere le stesse versioni di Proxmox VE tra i nodi di replica. Piccole differenze (es. 8.1 e 8.2) di solito funzionano, ma differenze maggiori (es. 7.x e 8.x) possono causare problemi di compatibilità, specialmente con le versioni di QEMU e i formati dei dischi virtuali.

Come funziona il failover in caso di disastro?

La replica asincrona prepara una copia della VM sul nodo secondario. In caso di disastro sul nodo primario, dovrai avviare manualmente la VM replicata sul nodo secondario. Proxmox non offre failover automatico integrato per la replica asincrona tra nodi standalone. Per un failover automatico, è necessario un cluster HA con storage condiviso o soluzioni esterne.

È possibile replicare solo alcune parti di una VM (es. solo un disco)?

No, la replica di Proxmox funziona a livello di VM completa. Replica tutti i dischi virtuali associati alla VM. Se hai bisogno di replicare solo dati specifici, dovresti considerare soluzioni a livello di sistema operativo (es. rsync, backup incrementali specifici per i dati).

Conclusioni con takeaway operativi

La replica asincrona di Proxmox VE è una soluzione potente ed economica per garantire la resilienza e la Disaster Recovery, anche in ambienti con limitazioni di banda significative. La chiave del successo risiede in una configurazione attenta dei parametri di ottimizzazione. Ricorda di:

Usare sempre ZSTD: La compressione è il tuo migliore alleato su WAN lente.
Impostare un rate adeguato: Limita la banda per non degradare le performance delle applicazioni critiche.
Pianificare intelligentemente: Sfrutta le finestre di basso traffico per le repliche più consistenti.
Monitorare costantemente: Verifica RPO, RTO e consumo di banda per aggiustare il tiro.

Con questi accorgimenti, è possibile ottenere un RPO di 30-60 minuti anche su un collegamento da 100 Mbps, proteggendo le tue infrastrutture virtualizzate.

Fonti

Proxmox VE Replication

Aggiornato: Agosto 2026