Backup automatico di 2 VPS via LAN con Duplicati su Ubuntu 22

Backup via LAN: perché Duplicati ha senso tra due VPS Ubuntu 22

Se hai due VPS nella stessa LAN privata, o collegate da una rete di servizio con latenza bassa e traffico non esposto su Internet, Duplicati è una scelta pratica per automatizzare backup incrementali, compressi e cifrati verso un secondo nodo. L’idea non è fare un archivio “per sempre”, ma costruire una copia recuperabile con un costo operativo accettabile: poco traffico, retention chiara, restore testabile.

Su Ubuntu 22 il punto non è tanto installare il software, quanto evitare gli errori tipici: destinazione montata male, porta web lasciata aperta, password di backup non gestita bene, snapshot senza test di ripristino, retention troppo aggressiva. Se il backup non si può ripristinare in tempi ragionevoli, è solo un consumo di disco con interfaccia grafica.

Architettura consigliata: una VPS come sorgente, una come destinazione

Lo schema più semplice è questo: VPS A produce i dati da proteggere, VPS B ospita il repository Duplicati. La connessione passa su LAN privata, idealmente con IP statici o DHCP reservation. Se la rete è davvero interna, puoi usare una porta TCP dedicata e limitare l’accesso con firewall host-based; se la LAN non è affidabile, aggiungi cifratura applicativa e non fidarti della sola segregazione di rete.

Per carichi piccoli e medi, la destinazione su filesystem locale della VPS B è la soluzione più lineare. Se vuoi maggiore robustezza, appoggi il repository a un disco separato o a un volume dedicato. Evita invece di mettere il repository nel medesimo filesystem dei dati critici senza almeno una quota o una separazione logica: quando il disco si riempie, il backup fallisce insieme al resto.

Prerequisiti minimi da verificare prima di installare

Prima di toccare Duplicati, verifica tre cose: connettività, spazio e identità della macchina di destinazione. Sono controlli banali, ma sono quelli che evitano metà dei ticket “backup non parte”.

1. Connettività IP tra le VPS:

ping -c 3 10.10.10.20
ss -tn state established

Atteso: risposta ICMP o, se ICMP è filtrato, almeno raggiungibilità TCP verso la porta prevista. Se il ping fallisce, non partire con Duplicati: prima risolvi routing, VLAN, security group o firewall locale.

2. Spazio libero sulla destinazione:

df -h /srv/backup
lsblk -f

Atteso: margine reale, non “spazio nominale”. Per backup incrementali con retention di più versioni, considera almeno il doppio del volume dei dati iniziali come base prudente, poi correggi in base al tasso di change.

3. Ora di sistema sincronizzata:

timedatectl status
systemctl status systemd-timesyncd

Atteso: clock coerente tra sorgente e destinazione. Con orari sballati, i log di job e retention diventano meno leggibili e il troubleshooting peggiora molto più di quanto sembri.

Installazione di Duplicati su Ubuntu 22

Duplicati può essere installato in vari modi, ma su Ubuntu 22 la via più pulita per un server dedicato è usare il pacchetto ufficiale o il servizio predisposto dal vendor, quando disponibile per la release in uso. In alternativa, puoi usare il pacchetto .deb, sempre verificando che il repository sia aggiornato e mantenuto. Qui il punto operativo è uno: il servizio deve avviarsi come demone, non come applicazione lanciata a mano in una shell dimenticata.

Dopo l’installazione, controlla subito il servizio:

systemctl status duplicati
journalctl -u duplicati -b --no-pager

Se il nome del servizio differisce, cerca l’unit corretta con:

systemctl list-unit-files | grep -i duplicati
systemctl list-units | grep -i duplicati

Atteso: stato active (running) e nessun errore di binding sulla porta web. Se il demone non parte, la causa più frequente è una directory dati non scrivibile o una porta già occupata.

Esposizione della console web: solo su rete interna, non su Internet

Duplicati ha una console web comoda, ma proprio per questo va trattata come superficie d’attacco. Non esporla pubblicamente senza motivo. La soluzione migliore è bindare il servizio solo sull’IP LAN della VPS o, in mancanza, filtrarlo a livello firewall in ingresso.

Se usi UFW sulla VPS destinazione, limita l’accesso solo dalla sorgente autorizzata:

sudo ufw allow from 10.10.10.10 to any port 8200 proto tcp
sudo ufw status numbered

Adatta la porta a quella effettiva del servizio. Se vuoi una verifica rapida, usa:

curl -I http://10.10.10.20:8200/

Atteso: risposta HTTP coerente con la web UI o un redirect previsto. Se ottieni timeout, controlla service binding, firewall locale e eventuale reverse proxy davanti alla UI.

Repository backup: struttura e permessi corretti

Prima di creare il job, prepara una directory dedicata sulla VPS B. Non usare cartelle generiche tipo /backup se poi ospitano altro. Una struttura chiara riduce gli errori di manutenzione e rende più semplice capire chi sta consumando spazio.

sudo mkdir -p /srv/duplicati/vps-a
sudo chown -R root:root /srv/duplicati
sudo chmod -R 750 /srv/duplicati

Se Duplicati scrive con un utente dedicato, sostituisci ownership e permessi con quelli del servizio. L’obiettivo è semplice: il processo deve poter scrivere solo dove serve, non nel resto del filesystem. Dopo la creazione, verifica:

namei -l /srv/duplicati/vps-a

Atteso: tutti i segmenti del path hanno permessi coerenti. Se un parent directory è troppo restrittivo o troppo aperto, il backup fallisce oppure espone più del necessario.

Configurazione del job: cosa includere e cosa escludere

Il punto più delicato non è il repository, ma la selezione dei dati. Un backup buono copia ciò che serve a ricostruire il servizio, non tutto il disco. Su una VPS Linux tipica, in genere vuoi includere configurazioni, virtual host, file applicativi, crontab, dati persistenti e dump del database; vuoi escludere cache, file temporanei, log troppo verbosi e directory rigenerate al boot.

Esempio di set ragionevole per un nodo LAMP/LEMP:

• /etc con esclusioni mirate per materiale sensibile non necessario al restore automatico.
• /var/www o path applicativi equivalenti.
• /home solo se contiene dati operativi rilevanti.
• Dump SQL esportati in una directory temporanea dedicata.
• File di servizio in /etc/systemd/system se hai unit custom.

Esempio di esclusioni pratiche:

--exclude=/var/cache
--exclude=/tmp
--exclude=/var/tmp
--exclude=/var/log/journal
--exclude=/var/lib/mysql/*.ib_logfile*

Non copiare a caso file di database live senza capire il motore. Per MySQL/MariaDB è molto più sensato fare un dump consistente e versionarlo come file, invece di prendere i file del datadir a caldo. Per PostgreSQL vale lo stesso principio: dump logico o snapshot coerente, non improvvisazione.

Dump del database prima del backup file-level

Se la VPS A ospita un database, il metodo più robusto è creare un dump prima dell’esecuzione di Duplicati. In questo modo separi la consistenza del DB dal backup dei file applicativi. Il job di backup non deve inventarsi la coerenza: gliela prepari tu.

Per MariaDB/MySQL puoi usare una procedura del genere:

mkdir -p /var/backups/mysql
mysqldump --single-transaction --routines --events --all-databases | gzip > /var/backups/mysql/all-databases.sql.gz

Per PostgreSQL, usa il comando adatto al tuo schema di autenticazione e salva il dump in una directory che poi includi nel job. L’importante è che il file risultante sia verificabile e abbia timestamp chiari.

Verifica minima dopo il dump:

ls -lh /var/backups/mysql/all-databases.sql.gz
gzip -t /var/backups/mysql/all-databases.sql.gz

Atteso: file presente, dimensione plausibile, compressione valida. Se il dump fallisce, il backup file-level non risolve il problema a monte.

Programmazione del job e retention: meglio semplice che “furbo”

Per una coppia di VPS, una schedulazione giornaliera è spesso sufficiente. Se il rate di modifica è alto, valuta esecuzioni più frequenti per i dati applicativi e una cadenza diversa per i dump DB. L’errore classico è allineare tutto sullo stesso orario senza pensare al carico: così, a mezzanotte, fai partire backup, logrotate, cron di manutenzione e magari anche le query di report.

La retention deve riflettere il tempo reale di recupero che vuoi coprire. Una configurazione tipo può essere: backup giornalieri per 7 giorni, settimanali per 4 settimane, mensili per 3 mesi. È una base sensata per ambienti piccoli; poi la correggi in funzione dello spazio e del change rate.

In Duplicati, controlla che la retention non elimini versioni prima che tu abbia avuto modo di testare un restore. In pratica: prima validi il ripristino, poi stringi la conservazione. Fare il contrario è un modo elegante per scoprire il problema quando serve davvero.

Cifratura, password e gestione dei segreti

Anche se il traffico viaggia su LAN, cifra il repository. La cifratura applicativa protegge da accessi accidentali, backup storage compromessi e copie esportate altrove. La password di backup non va messa in chiaro in documentazione, script condivisi o ticket. Se devi automatizzare, usa un meccanismo di secret handling del sistema, oppure almeno un file con permessi stretti e ownership dedicata.

Controllo minimo lato filesystem:

sudo install -m 600 -o root -g root /dev/null /root/.duplicati-passphrase
sudo ls -l /root/.duplicati-passphrase

Se un segreto è già finito in un file condiviso, la correzione non è “sistemarlo dopo”: va ruotato. Per un repository già in uso, valuta la rotazione della passphrase e verifica che il restore con la nuova chiave funzioni davvero. Senza test di decrittazione, hai solo cambiato una stringa.

Backup automatico della configurazione Duplicati stessa

Un dettaglio spesso trascurato: la configurazione di Duplicati è parte integrante del sistema. Se perdi il job, perdi anche la logica di backup. Conviene esportare o salvare con regolarità la configurazione del servizio e conservare una copia del file di configurazione, dove previsto, in un percorso protetto e incluso nel backup della macchina.

Se la tua installazione usa file locali o un database interno per la configurazione, individua il path reale con:

systemctl cat duplicati
find /var/lib -maxdepth 3 -iname '*duplicati*' 2>/dev/null

Atteso: percorso chiaro del servizio e dei dati applicativi. Se non sai dove risiede la configurazione, non puoi fare un restore serio della piattaforma di backup.

Verifica del primo backup: cosa guardare davvero

Il primo run non si giudica solo dal colore verde della UI. Devi controllare almeno quattro cose: durata, volume trasferito, errori di accesso e presenza del set di versioni nel repository. In un ambiente piccolo, un primo backup completo può richiedere più tempo del previsto: è normale. Non è normale vedere errori ripetuti su file bloccati, permessi mancanti o repository non raggiungibile.

Controlli utili:

journalctl -u duplicati -f
ls -lah /srv/duplicati/vps-a

Se la UI mostra successo ma la directory resta vuota, hai probabilmente un problema di path, permessi o destinazione errata. Se invece il repository cresce ma i log riportano warning continui, fermati prima di aumentare la retention: il warning di oggi diventa il restore rotto di domani.

Restore test: l’unico vero criterio di qualità

Ogni backup serio deve avere almeno un restore testato. Il test minimo non consiste nel ripristinare tutto il server, ma un sottoinsieme rappresentativo: una directory applicativa, un file di configurazione e un dump database. Se il ripristino selettivo funziona, hai già validato repository, cifratura, integrità e accesso.

Procedura essenziale:

1. Apri la console Duplicati dalla rete interna autorizzata.
2. Seleziona una versione precedente del backup.
3. Ripristina in una directory temporanea, non in produzione.
4. Confronta file e checksum se necessario.

Verifica post-restore:

diff -ruN /tmp/restore-test /path/originale
sha256sum /tmp/restore-test/file.importante

Se devi ripristinare un database, importa il dump in un’istanza di test o in uno schema separato. Il punto non è solo leggere il file, ma dimostrare che il contenuto è utilizzabile. Un file corrotto può esistere perfettamente fino al giorno del disastro.

Hardening della VPS destinazione

La VPS B non è un semplice disco remoto. È un nodo che conserva copie dei tuoi dati, quindi merita hardening minimo: aggiornamenti regolari, servizi esposti ridotti, accesso SSH con chiavi, firewall attivo e monitoraggio dello spazio. Se la macchina si riempie o si compromette, il backup smette di essere un vantaggio e diventa un singolo punto di fallimento ben nascosto.

Controlli minimi:

sudo apt update
sudo apt list --upgradable
sudo ss -tulpn
sudo ufw status verbose

Atteso: solo i servizi necessari in ascolto, niente porte inutili esposte sulla LAN se non strettamente richieste. Se la console Duplicati deve essere raggiungibile, restringi l’origine e non affidarti a password deboli o riutilizzate.

Monitoraggio: alert utili e non rumorosi

Un backup automatico senza monitoraggio è una scommessa. Gli alert utili sono pochi: job fallito, repository non raggiungibile, spazio sotto soglia, durata anomala rispetto alla media. Evita notifiche troppo verbose, perché finiscono ignorate. Meglio un allarme che segnala un errore reale che dieci mail per ogni warning innocuo.

Se hai un sistema di monitoring, osserva almeno:

• stato del servizio Duplicati;
• occupazione filesystem del repository;
• ultimi esiti dei job;
• trend della durata backup nel tempo.

Una metrica semplice ma utile è il rapporto tra dimensione del backup incrementale e spazio libero residuo. Se il delta cresce e lo spazio cala, non aspettare il failure: pianifica l’espansione del volume o rivedi retention ed esclusioni.

Problemi tipici e come leggerli in fretta

Se il job non parte, guarda prima i log del servizio e poi la UI. Se la UI è raggiungibile ma il repository non scrive, il problema è quasi sempre permessi, path o spazio. Se il backup parte ma cresce in modo anomalo, probabilmente stai includendo directory che cambiano troppo spesso o file temporanei che non dovrebbero stare nel set.

Tre segnali da riconoscere subito:

1. Timeout verso la destinazione: rete, firewall o servizio non in ascolto.
2. Errore di accesso negato: permessi sul path o credenziali errate.
3. Backup enorme e lento: scope troppo largo, esclusioni insufficienti, delta alto.

Quando trovi il primo indizio, non cambiare tre cose insieme. Correggi una sola variabile, riesegui il job e osserva l’effetto. È il modo più rapido per non perdere il nesso causa-effetto.

Conclusione operativa: cosa rende questo schema davvero affidabile

Un backup automatico tra due VPS via LAN funziona bene quando è semplice da spiegare e da ripristinare: una sorgente, una destinazione, un repository cifrato, esclusioni sensate, dump DB separati, retention ragionata e almeno un restore testato. Il resto sono ottimizzazioni, utili ma secondarie.

Se vuoi un criterio pratico per capire se hai fatto un buon lavoro, basta questo: in caso di guasto della VPS A, devi sapere in anticipo dove recuperare i file, quanto tempo serve per il restore e quale versione del backup è affidabile. Se queste tre risposte sono immediate, il sistema è maturo. Se devi cercarle durante l’incidente, il backup esiste ma non ti aiuta ancora abbastanza.