Una Strategia Pratica di Backup per VPS (Regola 3-2-1)

Scritto dal team di ApexVPS • Ultimo aggiornamento: luglio 2026 • 7 min di lettura

Una strategia di backup per VPS affidabile è la differenza tra un recupero in cinque minuti e una settimana molto brutta. I server si guastano, i dischi si corrompono, le distribuzioni vanno male e un singolo comando digitato male può cancellare una directory. Il Centro di apprendimento Cloudflare e la maggior parte dei team di infrastruttura indicano la stessa semplice disciplina: la regola 3-2-1. Questa guida mostra come applicarla a un vero server virtuale, quali strumenti usare e come programmare e testare tutto affinché un ripristino funzioni davvero quando ne hai bisogno.

Cosa Significa la Regola 3-2-1

La regola 3-2-1 è un principio di backup vecchio di decenni che rimane valido indipendentemente da dove vive il tuo server:

• 3 copie dei tuoi dati — la copia live più almeno due backup.
• 2 supporti o sistemi di archiviazione diversi — così un singolo guasto non può eliminare entrambe le copie contemporaneamente.
• 1 copia fuori sede — fisicamente o logicamente separata dalla macchina che stai proteggendo.

Su un VPS questo di solito significa il tuo server in esecuzione, un repository locale di backup e una copia crittografata inviata a uno storage remoto in una posizione diversa. Il punto è la ridondanza senza un unico punto di guasto condiviso.

Cosa fare il backup su un VPS

Fare il backup dell'intero disco blocco per blocco è dispendioso e lento. Un buon piano di backup si concentra sulle tre cose che sono davvero difficili da ricreare.

Dati applicativi e file

File caricati, radici dei siti web, volumi dei container e tutto ciò che gli utenti generano. I percorsi tipici includono /var/www, /srv, /home e la directory dei volumi Docker. Se auto-ospiti app come un file server o un wiki, è qui che vive il tuo contenuto insostituibile — consulta la nostra guida su come usare un VPS per l'hosting personale per capire come sono solitamente organizzate queste directory.

Database

Non copiare mai i file del database mentre il servizio è in esecuzione — potresti catturare uno stato corrotto a metà scrittura. Invece esporta un dump consistente. Per MySQL o MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Il flag --single-transaction fornisce uno snapshot consistente delle tabelle InnoDB senza bloccarle. Per PostgreSQL, usa invece pg_dump:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Configurazione di sistema e servizi

I file che rendono il tuo server unico: /etc (nginx, unità systemd, cron, config SSH), elenchi di pacchetti, certificati TLS e regole del firewall. Ricostruirli a memoria dopo un guasto è esattamente il lavoro noioso che i backup servono a evitare.

Scegliere i tuoi strumenti di backup

Tre strumenti coprono quasi tutti i casi VPS. Scegli in base a quanto apprezzi la deduplicazione e la crittografia.

restic — snapshot crittografati e deduplicati

restic è uno strumento di backup moderno a file singolo che crittografa e deduplica per impostazione predefinita. Inizializza un repository una volta, poi esegui i backup su di esso:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — archivi deduplicati

BorgBackup offre una deduplicazione e compressione simile con un flusso di lavoro leggermente diverso:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — mirroring semplice di file

Quando hai solo bisogno di un mirror veloce di file su un altro host, rsync su SSH è difficile da battere:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

I flag -aAX preservano permessi, ACL e attributi estesi; --delete mantiene il mirror sincronizzato con la sorgente. rsync da solo non memorizza la cronologia delle versioni, per questo molti team lo abbinano a restic o borg.

Automatizza la pianificazione con cron

Un backup che devi ricordare di eseguire è un backup che non verrà eseguito. Metti i tuoi passaggi in uno script, rendilo eseguibile e pianificalo con cron. Modifica il tuo crontab con:

crontab -e

Poi aggiungi righe come queste:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Registra l'output e fai sì che lo script esca con un codice diverso da zero in caso di errore, così puoi collegarlo alle funzionalità di monitoraggio e avvisi incluse nel tuo piano. Un errore di backup silenzioso è peggio di nessun backup, perché dà un falso senso di sicurezza.

Mantieni una vera copia fuori sede

Il "1" nel 3-2-1 è la parte che molti saltano. Un backup sullo stesso server che protegge scompare con quel server. Invia una copia crittografata da qualche parte di indipendente — storage a oggetti, un box SFTP remoto o un altro provider. restic e borg scrivono entrambi direttamente su repository remoti, ad esempio su SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Poiché restic e borg crittografano prima che i dati lascino il tuo VPS, l'host remoto non vede mai il tuo testo in chiaro. Elimina i vecchi snapshot con una politica per evitare che lo storage cresca all'infinito:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Testa i tuoi ripristini — ogni volta

Un backup non testato è una voce. Pianifica un ripristino periodico in una posizione usa e getta e verifica che file e database tornino intatti:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Se il ripristino riesce e i dati corrispondono, hai una strategia. Se non riesce, hai imparato la lezione un martedì pomeriggio invece che durante un'interruzione reale.

Gli snapshot sono un livello, non l'intera strategia

Ogni piano ApexVPS include backup automatici — snapshot giornalieri su Starter Pro e snapshot orari su Business — e sono davvero utili per rollback rapidi dopo un deploy sbagliato o una cancellazione accidentale. Ma sii onesto su cosa sono: un comodo primo livello che risiede sulla nostra piattaforma. Non sostituiscono la copia offsite, verificata in modo indipendente, richiesta dalla regola 3-2-1. Tratta gli snapshot di piattaforma come il tuo punto di ripristino locale rapido, e esegui il tuo job restic o borg per soddisfare le parti offsite e di ripristino testato della regola. Questo approccio a strati è ciò che distingue una configurazione piena di speranza da una resiliente, sia che tu ospiti app come Nextcloud o gestisca un database di produzione.

Lista di controllo per la strategia di backup del tuo VPS

Mettendo tutto insieme, una strategia di backup completa per un server virtuale si presenta così. Seguila una volta, automatizzala con script e lascia che cron la porti avanti:

• Identifica ciò che conta — file dell'applicazione, dump del database e la configurazione sotto /etc.
• Scegli uno strumento — restic o BorgBackup per backup crittografati, deduplicati e versionati; rsync per mirror semplici.
• Esegui dump dei database in modo coerente — mysqldump --single-transaction o pg_dump, mai una copia grezza di file live.
• Automatizza — pianifica lo script con cron e avvisa su qualsiasi uscita non zero.
• Invia una copia offsite — crittografata, su storage indipendente, con una politica di conservazione sensata.
• Testa i ripristini regolarmente — ripristina in una posizione temporanea e conferma che i dati siano intatti.

Fai queste sei cose e la regola 3-2-1 smette di essere teoria e diventa un'abitudine su cui la tua infrastruttura può contare. L'ora di setup iniziale è trascurabile rispetto al costo di scoprire, durante un incidente, che la tua unica copia era sul disco che è appena morto.

Domande Frequenti

Gli snapshot del provider contano come strategia di backup?

Gli snapshot sono un livello utile, ma non una strategia completa. I nostri snapshot giornalieri e orari proteggono dalla maggior parte degli errori a breve termine, ma vivono sulla stessa piattaforma del tuo server. Una strategia di backup 3-2-1 completa richiede ancora una copia indipendente e offsite che controlli tu, e ripristini che hai effettivamente testato.

Con quale frequenza dovrei fare backup di un VPS?

Abbina la frequenza alla quantità di dati che puoi permetterti di perdere. File statici e configurazioni possono essere backuppati quotidianamente, mentre database attivi spesso giustificano dump orari. Usa cron per automatizzare il programma così i backup non dipendono mai dalla memoria.

Qual è il miglior strumento per i backup VPS?

restic e BorgBackup sono entrambi eccellenti: deduplicano, comprimono e crittografano i backup, e supportano repository offsite. rsync va bene per mirroring semplice di file, e mysqldump o pg_dump gestiscono gli export dei database. Molte configurazioni combinano un dump del database con una esecuzione di restic o borg.

Come faccio a sapere che i miei backup funzionano davvero?

Testa i ripristini con regolarità. Ripristina in una directory temporanea, verifica i contenuti dei file e i checksum, e importa un dump del database in un database di prova. Un backup che non hai mai ripristinato è solo una congettura piena di speranza, non un piano di recupero.