Usare un VPS come destinazione per backup fuori sede

Che cos’è realmente una destinazione di backup fuori sede

Una destinazione di backup fuori sede è una seconda macchina che contiene una copia dei dati e il cui guasto è indipendente da quello dell’originale. Per la maggior parte dei lettori, l’opzione meno costosa è un VPS presso un altro provider. Sono realistiche tre soluzioni: Proxmox Backup Server in esecuzione sul VPS, un repository restic raggiunto tramite SSH o S3 oppure un mirror rsync che l’host di backup scarica. La scelta dipende dai dati da ripristinare e dal tempo massimo accettabile per renderli nuovamente disponibili. Il resto dipende da chi può eliminare la copia.

Fuori sede significa appartenere a un dominio di guasto diverso. Questo richiede un provider diverso e un account che non condivida alcuna credenziale di accesso con quello che esegue il server. Un secondo server in un’altra regione dello stesso provider può sopravvivere a un incendio in un edificio. Non sopravvive però alla compromissione delle credenziali del pannello di controllo, perché un unico account controlla entrambe le copie.

Uno snapshot presso il provider non è una seconda copia indipendente. Si trova dietro la stessa password del pannello. Chi ottiene quella password può eliminare il server e i relativi snapshot nella stessa sessione. Inoltre, i servizi di snapshot applicano un costo mensile per gigabyte molto superiore a quello del semplice spazio su disco. Mantenerli per novanta giorni diventa quindi costoso. Prima di affidarti a una delle due soluzioni, leggi La differenza tra snapshot e backup dei VPS.

Quale delle tre soluzioni fa al caso tuo

• Proxmox Backup Server (PBS): la sorgente è Proxmox VE (ambiente virtuale) e ciò che ripristini è una macchina virtuale completa. Esegue il backup a livello di immagine disco e i relativi processi di verifica rileggono i dati presenti sulla destinazione.
• Un repository restic: la sorgente è uno o più host Linux e ciò che ripristini è una directory o un dump di database. Esegue la cifratura sul client e supporta SSH e S3, oltre al proprio protocollo REST.
• rsync over SSH, eseguito dal backup host: vuoi che i file siano presenti sulla destinazione come file ordinari, leggibili con ls e cat, senza dover installare software client per recuperarli.

Se non sai quale scegliere, usa restic. Esegue la cifratura prima che i dati lascino la macchina e sulla destinazione richiede soltanto un account SSH e spazio su disco. Configurazione dei backup restic su un VPS descrive più dettagliatamente la configurazione lato client, mentre restic e BorgBackup a confronto illustra la scelta se utilizzi già Borg.

Dimensionare la destinazione: quanto costa un mese di conservazione

La deduplicazione spiega perché i numeri sono inferiori alle aspettative. Sia restic sia PBS suddividono i file in blocchi di dimensione variabile e calcolano l’hash di ogni blocco. Ogni blocco univoco viene memorizzato una sola volta. Il secondo backup di un dataset da 500 GB non aggiunge altri 500 GB. Aggiunge solo i blocchi modificati.

La dimensione del repository dipende quindi dall’età dello snapshot più vecchio, non dal numero di snapshot. Consideriamo 500 GB di dati e 5 GB di nuovi dati univoci al giorno. Il repository conterrà i 500 GB di base, più circa 5 GB per ogni giorno compreso tra oggi e lo snapshot più vecchio conservato dalla policy.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

La colonna in dollari calcola il costo del repository usando 10 dollari statunitensi per TB al mese. È un valore indicativo per eseguire i calcoli, non il prezzo di un provider specifico. Sostituiscilo quindi con il prezzo reale per TB del piano che stai valutando. Una settimana di backup giornalieri occupa circa 535 GB. Un anno intero di cronologia occupa 2,325 GB, pari a $23.25 al mese, rispetto a $5.35 per la settimana. Conservare la cronologia costa poco. Il costo principale è la copia di base.

La deduplicazione non offre vantaggi per i dati che arrivano già compressi o cifrati. Un dump di database compresso con gzip cambia completamente a ogni esecuzione. Ogni dump viene quindi memorizzato come nuovi blocchi e il repository cresce di un dump completo ogni notte. Scrivi il dump senza comprimerlo e lascia che sia lo strumento di backup a comprimerlo. restic supporta i repository compressi dalla versione 0.14 e la versione 0.19 ha aggiunto le modalità zstd fastest e better. Anche le librerie di foto e video vengono deduplicate poco per lo stesso motivo. Dimensionale quindi in base al loro tasso di crescita effettivo, non ai valori riportati sopra.

In questo caso acquisti spazio disco inutilizzato, non capacità della CPU. È esattamente lo scenario in cui un VPS di storage è più conveniente di un VPS normale.

Perché la larghezza di banda e il tempo di ripristino determinano il piano

Il disco è la parte meno costosa. Il primo upload e l'eventuale ripristino sono le operazioni più costose. 500 GB corrispondono a 4 trilioni di bit, quindi dividendo per la velocità del collegamento si ottiene il tempo minimo necessario per un ripristino completo.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Questi valori considerano la velocità nominale del collegamento e non includono l'overhead dei protocolli, quindi rappresentano lo scenario migliore. A 100 Mbit/s, un ripristino completo richiede 11.1 ore prima ancora di poter accedere ai dati. Con una velocità di upload domestica di 40 Mbit/s servono 27.8 ore. Su una porta da 1 Gbit/s, lo stesso ripristino richiede 1.1 ore. Molti file di piccole dimensioni rallentano ulteriormente l'operazione rispetto al calcolo teorico, perché l'overhead per file diventa predominante quando i file sono inferiori a poche centinaia di kilobyte.

Da questo derivano due considerazioni. Se il tuo obiettivo di tempo di ripristino (RTO), cioè l'interruzione che puoi tollerare, è di quattro ore, un ripristino di 500 GB su un collegamento da 100 Mbit/s non può già rispettarlo; un disco più economico non cambia il risultato. Inoltre, la maggior parte dei piani VPS conteggia il traffico in uscita, quindi un singolo ripristino completo consuma 0.5 TB del traffico mensile disponibile sull'host dei backup. Verifica questo limite e controlla cosa fa il provider quando lo superi, prima di aver bisogno dei dati.

Il primo backup comprende l'intero dataset ed è l'esecuzione più lenta che dovrai effettuare. Avvialo di venerdì e limita la velocità per evitare di saturare l'uplink del sistema sorgente: restic usa --limit-upload in KiB al secondo, mentre rsync usa --bwlimit.

Forma 1: Proxmox Backup Server come datastore remoto

PBS è adatto quando l'origine è Proxmox VE e l'unità di ripristino è una macchina virtuale. Un VPS non può avviare l'ISO di Proxmox, quindi installa PBS sopra Debian. La versione 4.2 è quella corrente ad agosto 2026 ed è basata su Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Confronta questo checksum con il valore pubblicato nella pagina dei repository dei pacchetti Proxmox. Un repository apt è affidabile solo quanto la chiave che hai verificato. Quindi scrivi /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Assegna al datastore un filesystem dedicato o un volume dedicato. Un datastore pieno interrompe i backup; se condivide il filesystem root, quando si riempie può rendere indisponibile l'intero server.

Crea quindi l'account che l'origine utilizzerà e assegnagli un token invece di una password.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Il secret del token viene mostrato una sola volta e non può essere letto nuovamente, quindi salvalo quando viene visualizzato. Il ruolo è importante quanto il token. DatastoreBackup può creare e ripristinare i propri backup, ma non dispone del privilegio Datastore.Prune; quindi quel token non può eliminare uno snapshot che ha già scritto.

La retention su PBS ha due componenti, e la seconda viene spesso ignorata. Prune rimuove gli snapshot. Garbage collection rimuove i chunk a cui non fa riferimento alcuno snapshot ancora conservato. Lo spazio libero diventa disponibile dopo garbage collection, non dopo prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Rimuovi --dry-run quando l'elenco degli snapshot che prevede di eliminare è corretto. Garbage collection viene eseguito in due fasi: aggiorna l'ora di accesso di ogni chunk ancora referenziato, quindi elimina i chunk la cui ora di accesso è precedente al limite, fissato a 24 ore e 5 minuti prima dell'inizio dell'esecuzione. Questo periodo di tolleranza evita che un chunk scritto da un backup ancora in corso venga eliminato durante la scrittura. Pianifica prune ogni giorno e garbage collection ogni settimana sul datastore. Aggiungi inoltre un job di verifica, in modo che la destinazione rilegga i propri chunk e segnali la corruzione sul disco prima che si verifichi durante un ripristino.

Se l'origine è a sua volta un'istanza PBS, il server fuori sede può eseguire il pull invece di ricevere i dati tramite push.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Esegui quel job di sincronizzazione sul VPS, usando la direzione pull predefinita. Il VPS accede al datastore locale, quindi il server locale non conserva alcuna credenziale che possa modificare la copia fuori sede.

Forma 2: un repository restic su SSH o S3

Debian e Ubuntu includono entrambi restic nei rispettivi pacchetti, ma le versioni disponibili sono precedenti a quelle upstream. Ad agosto 2026, la versione corrente è la 0.19.1. Installa il binario ufficiale sull'host sorgente.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version stampa la versione e il compilatore Go con cui è stato compilato. Gli aggiornamenti successivi si eseguono con sudo restic self-update, che funziona sui binari ufficiali, ma non su una copia installata tramite apt.

Sul VPS di backup, crea un account che non possieda altri dati, quindi copia la chiave pubblica dell'host sorgente in /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Inizializza il repository dalla sorgente tramite SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Conserva questa password in una posizione che non sia né questo server né la destinazione del backup. Se la perdi, il repository non sarà più leggibile e non esisterà alcun metodo di recupero. Questo è il compromesso della cifratura lato client.

La conservazione si configura con un solo comando. La seconda parte del comando è quella che libera spazio su disco.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget elimina gli snapshot. prune elimina i file pack referenziati esclusivamente da quegli snapshot e --prune lo esegue automaticamente quando è stato effettivamente rimosso qualcosa. Senza questo passaggio, il repository non si riduce mai. restic check verifica la struttura del repository, mentre --read-data-subset=10% rilegge e ricalcola l'hash di un decimo dei file pack. In questo modo rileva la corruzione sulla destinazione senza il costo di leggere tutto. L'altra forma, --read-data-subset=1/10, controlla sempre lo stesso decimo. Incrementando il primo numero ogni settimana, puoi coprire l'intero repository in dieci settimane.

Se un'esecuzione viene terminata forzatamente, quella successiva si interrompe con repository is already locked exclusively by PID. Verifica che non sia in corso alcun backup, quindi rimuovi il blocco con restic unlock.

Per l'object storage, la stringa del repository diventa s3:https://s3.example.net/web1, con le credenziali in AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Tutto il resto rimane identico. È così che restic comunica con un object store MinIO self-hosted in esecuzione sullo stesso VPS.

Forma 3: rsync su SSH con una chiave in sola lettura

La proprietà di sicurezza di questa forma è la direzionalità. Il VPS di backup si connette alla sorgente ed esegue la lettura. La sorgente non contiene alcuna chiave e non dispone di un percorso verso l'host di backup, quindi la compromissione della sorgente non può raggiungere in alcun modo i backup.

Generare una coppia di chiavi sul VPS di backup, quindi installare la parte pubblica sulla sorgente con un comando forzato.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync è incluso nel pacchetto rsync in /usr/bin/rrsync su Debian 13 e Ubuntu 24.04. -ro consente soltanto la lettura e implica -no-del, quindi questa chiave non può scrivere sulla sorgente né eliminare elementi al suo interno. restrict disattiva le funzionalità SSH non necessarie in questo caso, incluso il port forwarding e il pty, quindi la chiave non può essere usata per un accesso interattivo. I percorsi sono quindi relativi alla directory specificata; il percorso remoto / indica /srv sulla sorgente.

Il pull conserva la cronologia usando gli hardlink. I file invariati nel nuovo albero sono hardlink all'albero precedente, quindi occupano una voce di directory invece di una seconda copia.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

La ridenominazione finale rende affidabile una directory datata: il nome compare soltanto dopo che rsync è terminato con codice 0, quindi un trasferimento interrotto non viene mai interpretato come uno snapshot completato. Eliminare i vecchi alberi con una sola riga, mantenendone trenta.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

È importante considerare anche i costi di questa forma. Gli hardlink deduplicano soltanto file interi, quindi la modifica di un solo byte all'interno di un'immagine disco da 4 GB copia tutti i 4 GB; restic e PBS memorizzerebbero invece pochi chunk modificati. Inoltre, la destinazione conserva i file in chiaro, quindi chiunque disponga dell'account root sul VPS di backup può leggerli.

Crittografia lato client: il target non vede mai i dati in chiaro

Considera il VPS di backup come una macchina che non controlli completamente. È gestito da un provider, che dispone di personale e di dischi guasti che vengono rimossi dalla struttura.

restic crittografa ogni blocco sul sistema di origine prima di inviarlo. Il repository contiene quindi dati cifrati e metadati relativi a dimensioni e temporizzazione. PBS rende la crittografia facoltativa: crea una chiave, quindi passala a ogni backup.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Stampa la chiave cartacea e conservala in un luogo fisico sicuro. La documentazione di Proxmox è chiara sulle conseguenze: senza la relativa chiave, i file sottoposti a backup non sono accessibili. Conserva la chiave lontano dal target di backup, perché una chiave archiviata accanto ai dati cifrati non protegge nulla.

I mirror rsync non offrono un meccanismo equivalente. I file vengono copiati come file. Se i dati sono sensibili, devi accettare che il target possa leggerli oppure usare una delle altre due modalità.

Impedire a una sorgente compromessa di cancellare i propri backup

Un attaccante che compromette la sorgente cerca subito i backup, e la credenziale che li carica si trova già su quella macchina. Se la stessa credenziale può anche cancellare i backup, l'attaccante la utilizza.

PBS risolve il problema con i ruoli. Un token che dispone soltanto di DatastoreBackup può scrivere nuovi snapshot e ripristinare i propri, ma non può eseguire il pruning, perché per cancellare uno snapshot è necessario il privilegio separato Datastore.Prune. Esegui la retention dal lato PBS: la sorgente non possiede mai una credenziale in grado di rimuovere dati.

restic su SFTP non offre questa separazione, perché la chiave SSH che scrive nel repository può anche cancellarvi i dati. La soluzione è il backend REST. Esegui rest-server sul VPS dei backup con --append-only. Questa opzione consente di creare nuovi backup, ma impedisce la cancellazione e la modifica di quelli esistenti. Quindi configura il client per usare rest:https://backup.example.net:8000/web1 tramite RESTIC_REST_USERNAME e RESTIC_REST_PASSWORD. Un restic forget --prune eseguito dalla sorgente fallisce, come previsto. La retention viene quindi eseguita da una seconda macchina con una propria credenziale. Il manuale di restic raccomanda inoltre --keep-within al posto delle policy basate sul numero di snapshot nei repository append-only. In caso contrario, un attaccante che riempie il repository con snapshot inutili potrebbe espellere quelli reali dalla finestra --keep-last.

rsync risolve lo stesso problema strutturalmente eseguendo il pull, perché la sorgente non possiede alcuna credenziale per la destinazione.

Una regola vale per tutti e tre i modelli: la credenziale che può cancellare i backup deve risiedere su una macchina diversa da quella di cui viene eseguito il backup.

Pianifica il test di ripristino

Un backup che non hai mai ripristinato è solo un'ipotesi. Dedica un'ora ogni trimestre e testalo.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r che non restituisce alcun output significa che l'albero ripristinato corrisponde a quello in produzione. Su PBS, lo stesso test si esegue con proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, oltre a un job di verifica pianificato che rilegge i chunk sul target e segnala gli errori di checksum.

Il test deve dimostrare più della semplice integrità dei dati.

• Esegui il ripristino da una terza macchina, non dalla sorgente, perché la sorgente è esattamente ciò che stai presumendo sia andato perso. La password del repository o la chiave PBS devono quindi essere raggiungibili senza la macchina sorgente.
• Misura la durata del ripristino e annotala, quindi confrontala con l'RTO dichiarato. Il grafico precedente mostra il limite minimo del trasferimento. Il valore reale include anche la decrittografia e la scrittura su disco, oltre al tempo necessario per individuare lo snapshot corretto.
• Ripristina dati con stato, ad esempio un dump del database da caricare successivamente in un'istanza di test. Un file tar che viene estratto non dimostra che l'applicazione si avvii.

Il disco più economico del mondo non vale nulla finché non hai eseguito almeno un ripristino da quel disco.

FAQ

Uno snapshot presso il provider VPS è un backup off-site?

No. Uno snapshot del provider risiede nello stesso account, dietro lo stesso accesso al pannello e sulla stessa fattura del server di cui è la copia. Chiunque ottenga quelle credenziali può eliminare il server e tutti i suoi snapshot nella stessa sessione. Gli snapshot sono utili per un rollback rapido prima di un aggiornamento rischioso, ma non costituiscono una seconda posizione. Una copia off-site risiede in un account diverso, idealmente presso un provider diverso, con credenziali che la macchina sorgente non possiede.

Quanto spazio su disco serve per conservare i backup per un mese?

Dimensiona lo spazio in base all'età dello snapshot più vecchio, non al numero di snapshot. Uno strumento con deduplicazione memorizza ogni blocco univoco una sola volta. Il repository ha quindi, in modo approssimativo, le dimensioni dei dati sorgente più i nuovi dati univoci generati ogni giorno, moltiplicati per il numero di giorni di conservazione. Per 500 GB di dati che cambiano di 5 GB al giorno, una settimana di backup giornalieri occupa circa 535 GB e un anno intero di cronologia occupa 2,325 GB. Prevedi spazio aggiuntivo, perché un disco pieno impedisce il backup successivo e restic prune richiede spazio libero per ricompattare i file pack prima di poterlo restituire.

Un server compromesso può eliminare i propri backup off-site?

Sì, a meno che tu non abbia progettato il sistema per impedirlo. In un repository SSH o SFTP semplice, la chiave che consente di scrivere può anche eliminare i dati. Assegna alla sorgente una credenziale che non possa rimuovere dati: un token API PBS con il solo ruolo DatastoreBackup, che non include il privilegio Datastore.Prune, oppure restic collegato a rest-server avviato con --append-only, che rifiuta l'eliminazione e la modifica dei backup esistenti. Un'architettura pull offre una protezione ulteriore, perché la sorgente non possiede alcuna credenziale per l'host di backup. Esegui la conservazione dal lato che non è la sorgente.

Devo eseguire Proxmox Backup Server o restic sul VPS di backup?

Scegli lo strumento in base all'unità che devi ripristinare. Se la sorgente è Proxmox VE e vuoi ripristinare un'intera macchina virtuale, usa PBS, perché esegue il backup a livello di immagine disco e ripristina una VM in un solo passaggio. Se la sorgente è un host Linux e vuoi ripristinare file e dump di database, usa restic, che richiede solo un account SSH sulla destinazione e cifra i dati prima di inviarli. Eseguire entrambi è normale: PBS per l'hypervisor e restic per i server che non risiedono sull'hypervisor.

Quanto dura il ripristino da un backup VPS?

Dividi la dimensione dei dati per la velocità del collegamento per ottenere il tempo minimo teorico, quindi aggiungi il tempo necessario per la decifratura e la scrittura. 500 GB su un collegamento da 100 Mbit/s richiedono 11.1 ore alla velocità nominale della linea, mentre lo stesso ripristino su una porta da 1 Gbit/s richiede 1.1 ore. Molti file di piccole dimensioni rallentano il trasferimento rispetto a questo calcolo a causa dell'overhead per file. Misura il tempo di un ripristino reale e usa quel valore, perché è l'unico su cui il tuo piano di ripristino può fare affidamento.