Backup 3-2-1: perché copiare i file non basta 💾

Finché tutto funziona, il backup è probabilmente una delle attività meno interessanti nella gestione di un server. Non migliora la grafica del sito, non aggiunge nuove funzionalità e non produce risultati particolarmente entusiasmanti da mostrare.

Poi arriva il giorno in cui un aggiornamento va storto, un database si corrompe, un disco smette di funzionare oppure qualcuno elimina accidentalmente una directory importante.

In quel momento il backup diventa improvvisamente la funzionalità più preziosa dell’intera infrastruttura.

Il problema è che avere una copia dei file non significa necessariamente avere un sistema di backup affidabile. Per proteggere davvero un VPS, un sito WordPress o un servizio self-hosted bisogna ragionare su dove vengono conservati i dati, come vengono creati e soprattutto se possono essere ripristinati.

Vediamo come organizzare una strategia sensata senza trasformare una piccola infrastruttura in un datacenter. 🛠️

Che cos’è la regola del backup 3-2-1?

La strategia 3-2-1 è un principio molto conosciuto nella protezione dei dati. Il nome riassume tre indicazioni:

• 3 copie dei dati: la copia utilizzata quotidianamente e almeno due copie aggiuntive.
• 2 tipologie di supporto o sistemi di conservazione differenti: per ridurre la dipendenza da un unico tipo di guasto.
• 1 copia conservata fuori sede: per proteggersi da eventi che coinvolgono l’intera infrastruttura principale.

Per esempio, un piccolo progetto potrebbe avere:

• i dati originali sul VPS;
• una copia su uno storage separato;
• una seconda copia presso un servizio di archiviazione remoto.

La regola non va interpretata come una formula magica. Due copie conservate sullo stesso server, accessibili con le stesse credenziali e soggette allo stesso guasto non offrono la stessa protezione di copie realmente indipendenti.

Inoltre, oggi si parla spesso di strategie 3-2-1-1-0, che aggiungono una copia offline o immutabile e l’obiettivo di verificare i backup senza errori. Sono evoluzioni utili soprattutto quando bisogna proteggersi anche da ransomware e cancellazioni intenzionali.

Perché un backup sullo stesso VPS non è sufficiente

Immagina di avere un sito WordPress e di creare ogni notte un archivio ZIP all’interno della stessa macchina.

Se un aggiornamento danneggia soltanto alcuni file, quella copia potrebbe essere sufficiente per tornare rapidamente indietro.

Ma se il server perde il disco, viene compromesso completamente o il filesystem diventa inutilizzabile, anche il backup rischia di scomparire.

Una copia locale è quindi utile per il ripristino rapido, ma non dovrebbe essere l’unica protezione disponibile.

Il principio da ricordare è semplice: un backup deve poter sopravvivere almeno ad alcuni dei problemi che potrebbero colpire i dati originali.

1. Prima di creare i backup, identifica ciò che devi proteggere

Il primo errore consiste nel copiare una directory senza sapere se contiene davvero tutto ciò che serve per ripristinare il servizio.

Un’applicazione web può dipendere da molti elementi:

• file del sito e codice applicativo;
• database;
• configurazioni del web server;
• configurazioni PHP e variabili di ambiente;
• certificati e chiavi, quando non possono essere rigenerati facilmente;
• file caricati dagli utenti;
• attività pianificate e configurazioni cron;
• permessi e proprietà dei file;
• configurazioni DNS e servizi esterni;
• istruzioni per ricostruire l’ambiente.

Non tutto deve essere copiato nello stesso modo. Il codice versionato in Git, per esempio, può essere recuperabile dal repository, mentre i file caricati dagli utenti potrebbero esistere soltanto sul server.

Un buon inventario distingue i dati ricostruibili da quelli che, se persi, non possono essere recuperati.

2. WordPress: non dimenticare il database

Un sito WordPress non è composto soltanto dai file presenti nella directory pubblica.

Articoli, pagine, utenti, impostazioni e numerosi dati dei plugin vengono conservati nel database. Se copi soltanto wp-content, potresti salvare temi, plugin e immagini, ma non avere tutte le informazioni necessarie per ricostruire il sito.

In generale, un backup WordPress dovrebbe comprendere:

• database completo del sito;
• directory wp-content;
• file di configurazione necessari;
• eventuali file personalizzati esterni alla struttura standard;
• informazioni sulla versione di WordPress, PHP e database.

È importante anche la coerenza temporale: se il database viene esportato mentre il sito continua a ricevere ordini o modifiche, e i file vengono copiati in un momento molto diverso, il ripristino potrebbe contenere dati non perfettamente allineati.

Per siti dinamici, soprattutto e-commerce, conviene valutare procedure che garantiscano snapshot coerenti o una finestra controllata per il backup.

3. MariaDB: una copia dei file non equivale a un dump consistente

Se utilizzi MariaDB, copiare direttamente i file del database mentre il server è attivo può produrre un risultato non utilizzabile, a seconda del motore di archiviazione e della procedura impiegata.

Per database di dimensioni contenute, una soluzione comune è utilizzare un dump logico tramite gli strumenti ufficiali.

Un esempio:

mariadb-dump \
  --single-transaction \
  --quick \
  --user=backup_user \
  --password \
  nome_database > database.sql

Il comando richiede la password in modo interattivo, evitando di inserirla direttamente nella riga di comando.

L’opzione --single-transaction è particolarmente utile per ottenere uno snapshot consistente delle tabelle transazionali InnoDB, ma non garantisce da sola la consistenza di tabelle non transazionali o di un database modificato con operazioni DDL durante l’esportazione.

Per database grandi o con requisiti più complessi, possono essere più adatti strumenti di backup fisico come MariaDB Backup.

Il metodo va scelto in base al motore delle tabelle, alle dimensioni del database e ai tempi di ripristino accettabili.

4. Automatizzare i backup con cron

Un backup che dipende dalla memoria di qualcuno prima o poi verrà dimenticato.

Su Linux, cron permette di pianificare attività ricorrenti. Per esempio, questa espressione indica un’esecuzione ogni giorno alle 3:00, secondo il fuso orario utilizzato dal servizio cron:

0 3 * * * /percorso/script-backup.sh

È soltanto un esempio di pianificazione, non uno script completo pronto per la produzione.

Uno script di backup affidabile dovrebbe:

• interrompersi quando un comando critico fallisce;
• registrare l’esito dell’operazione;
• verificare che gli archivi siano stati creati;
• trasferire i dati alla destinazione prevista;
• gestire le copie più vecchie secondo una politica di conservazione;
• inviare una notifica in caso di errore.

È importante anche evitare sovrapposizioni: se un backup dura più del previsto, non dovrebbe partire una seconda esecuzione che interferisce con la prima.

5. Rclone: trasferire le copie su uno storage remoto

Uno strumento particolarmente interessante per chi gestisce server Linux è rclone.

Permette di trasferire e sincronizzare file con numerosi servizi di storage remoto, inclusi diversi provider cloud e protocolli di archiviazione.

Una volta configurato un remote, puoi copiare una directory con un comando simile:

rclone copy \
  /backup/ \
  remote:backup-vps/ \
  --progress

Il comando è illustrativo: il remote deve essere già configurato e i percorsi devono essere adattati al tuo ambiente.

Un dettaglio importante è la differenza tra copy e sync.

copy trasferisce i file necessari senza eliminare automaticamente dalla destinazione quelli che non sono più presenti nella sorgente.

sync, invece, rende la destinazione coerente con la sorgente e può eliminare file remoti. Per un sistema di backup, questo comportamento va valutato con particolare attenzione: una cancellazione accidentale potrebbe propagarsi anche alla copia remota.

Per approfondire puoi consultare la documentazione ufficiale dei comandi rclone.

6. Crittografia: proteggere i dati anche quando sono fuori dal server

Un archivio di backup può contenere dati molto delicati: configurazioni, informazioni degli utenti, credenziali e documenti.

Quando i file vengono conservati presso un servizio esterno, è opportuno valutare la cifratura prima del trasferimento o attraverso strumenti che cifrano i dati lato client.

Rclone mette a disposizione il backend crypt, che consente di cifrare nomi e contenuti dei file prima di inviarli a un remote compatibile.

La crittografia introduce però una responsabilità importante: devi conservare in modo sicuro le informazioni necessarie per decifrare il backup.

Se perdi la chiave, potresti perdere anche la possibilità di recuperare i dati. E se la chiave viene conservata soltanto sul server che stai proteggendo, un guasto totale potrebbe impedirti di utilizzarla.

Per questo è utile prevedere una procedura separata e sicura per custodire le informazioni di ripristino.

7. Quanto spesso eseguire i backup?

La frequenza ideale dipende soprattutto da quanti dati puoi permetterti di perdere.

Un blog aggiornato una volta alla settimana ha esigenze diverse da un e-commerce che riceve ordini durante tutta la giornata.

Qui entrano in gioco due concetti:

• RPO (Recovery Point Objective): la quantità massima di dati che sei disposto a perdere, espressa come intervallo temporale.
• RTO (Recovery Time Objective): il tempo massimo accettabile per ripristinare il servizio dopo un incidente.

Se esegui un backup completo ogni 24 ore, potresti perdere fino a circa un giorno di modifiche, a seconda del momento in cui si verifica il problema e della riuscita dell’ultimo backup.

Se il servizio non può permetterselo, devi valutare backup più frequenti, backup incrementali o altre strategie compatibili con il database e con l’infrastruttura.

La frequenza non deve essere scelta soltanto in base alla comodità: deve riflettere il valore dei dati e le esigenze del servizio.

8. Conservazione: quanti backup mantenere?

Conservare soltanto l’ultima copia può essere rischioso. Se un problema viene scoperto dopo alcuni giorni, l’ultimo backup potrebbe già contenere dati danneggiati o modifiche indesiderate.

Una politica di conservazione può prevedere, per esempio:

• copie giornaliere per un periodo breve;
• copie settimanali per un periodo intermedio;
• copie mensili per uno storico più lungo.

Non esiste una durata valida per ogni attività. Bisogna considerare spazio disponibile, obblighi applicabili, frequenza di modifica e necessità di recuperare versioni precedenti.

È inoltre importante che la rotazione dei backup non elimini automaticamente tutte le copie sane dopo un incidente rimasto inosservato.

9. Backup immutabili e protezione dai ransomware

Una strategia moderna dovrebbe considerare anche gli attacchi informatici.

Se un aggressore ottiene accesso al server e alle credenziali utilizzate per i backup, potrebbe tentare di cancellare o cifrare anche le copie remote.

Per ridurre questo rischio, valuta:

• credenziali dedicate con permessi minimi;
• separazione tra accesso al server e amministrazione dello storage;
• versioning e conservazione protetta sul provider remoto;
• copie offline o immutabili, quando disponibili;
• autenticazione multifattore sugli account amministrativi.

Un backup immutabile è una copia che, per un periodo definito e secondo le garanzie del sistema utilizzato, non può essere modificata o cancellata attraverso le normali operazioni autorizzate.

Non è necessario adottare subito una soluzione enterprise, ma è importante evitare che un unico account compromesso possa distruggere contemporaneamente produzione e backup.

10. La prova più importante: il ripristino

Arriviamo al punto che spesso viene trascurato.

Un file di backup esistente non garantisce che il ripristino funzioni.

Un archivio potrebbe essere incompleto, un dump potrebbe contenere errori oppure potrebbero mancare configurazioni fondamentali per far ripartire l’applicazione.

La verifica più utile consiste nel ripristinare periodicamente una copia in un ambiente isolato, senza modificare il sistema di produzione.

Per un sito WordPress, per esempio, una prova può comprendere:

1. preparazione di un ambiente di test separato;
2. ripristino dei file;
3. importazione del database;
4. adattamento delle configurazioni necessarie;
5. verifica delle pagine principali e delle funzionalità;
6. controllo dei file caricati e dei dati applicativi;
7. registrazione dei problemi incontrati e del tempo necessario.

Per evitare effetti indesiderati, l’ambiente di test non dovrebbe inviare email reali, eseguire pagamenti o comunicare con integrazioni di produzione senza controlli adeguati.

Una prova di ripristino permette anche di capire se la documentazione è sufficiente per ricostruire il servizio quando il server originale non è più disponibile.

Checklist per una strategia di backup affidabile

• ☐ Ho identificato tutti i dati e le configurazioni indispensabili?
• ☐ Conservo copie indipendenti dal server principale?
• ☐ Esiste almeno una copia fuori sede?
• ☐ I backup sono automatizzati?
• ☐ Ricevo notifiche in caso di errore?
• ☐ Ho definito una politica di conservazione?
• ☐ Le copie contenenti dati sensibili sono adeguatamente protette?
• ☐ Un account compromesso non può cancellare facilmente tutte le copie?
• ☐ Ho documentato la procedura di ripristino?
• ☐ Ho eseguito almeno una prova reale in un ambiente isolato?

Conclusione: il backup migliore è quello che riesci a ripristinare

Una strategia di backup efficace non deve essere necessariamente complicata. Anche una piccola infrastruttura può essere protetta bene con strumenti accessibili, automazione e qualche regola chiara.

La differenza non la fa il numero di archivi ZIP conservati sul disco, ma la capacità di recuperare dati e servizi quando qualcosa va storto.

Il principio 3-2-1 offre una buona base di partenza, ma va accompagnato da controlli sugli esiti, protezione delle copie e prove periodiche di ripristino.

Perché il momento peggiore per scoprire che un backup non funziona è proprio quello in cui ne hai bisogno. 🔐