Backup sicuri: strategia minima per evitare disastri

Perché un backup “fatto” non basta

Nel lavoro quotidiano di un sysadmin o di un webmaster, il backup viene spesso trattato come una formalità: si configura un job, si vede che “parte”, e si presume che il problema sia risolto. È qui che nascono i guai. Un backup non è utile perché esiste; è utile solo se si può ripristinare, in tempi accettabili, con dati integri e con una procedura che non costringa a improvvisare sotto pressione.

La regola più semplice è questa: non proteggere il file, proteggi il ripristino. Se il backup non è testato, non è un backup: è una speranza compressa in un archivio.

Gli errori più comuni

Molti ambienti piccoli e medi falliscono per motivi sempre simili:

• backup salvati solo sullo stesso server;
• assenza di versioning reale;
• assenza di verifica dell’integrità;
• ripristino mai provato;
• spazio disco insufficiente per le retention;
• backup dei file ma non del database, o viceversa;
• credenziali del cloud o dell’FTP lasciate in chiaro;
• nessun alert quando il job fallisce.

Un backup che non segnala errori è pericoloso quanto un backup che non parte. Nei sistemi reali, il fallimento silenzioso è il nemico principale.

La struttura minima che funziona davvero

Per partire con criterio, basta una base semplice e robusta:

1. copia locale per il ripristino veloce;
2. copia esterna per proteggersi da guasti gravi e ransomware;
3. conservazione a rotazione per evitare di tenere sempre lo stesso punto nel tempo;
4. verifica periodica per controllare che gli archivi siano leggibili;
5. test di restore su un ambiente separato.

Questa struttura è più utile di una soluzione “sofisticata” ma opaca. Prima si costruisce la resilienza, poi si aggiungono automazioni avanzate.

Quali dati salvare davvero

Non tutto ha lo stesso valore. In un sito o in un server, le priorità sono queste:

1. database: spesso è il cuore del servizio;
2. file applicativi: temi, plugin, upload, configurazioni;
3. configurazioni di sistema: web server, DNS, mail, cron, certificati, regole di sicurezza;
4. metadati operativi: inventario, versioni, note di restore, credenziali gestite in modo sicuro.

Se gestisci WordPress, ad esempio, non basta copiare `wp-content`. Serve anche il dump del database e, in alcuni casi, il file di configurazione, i certificati e le regole di reverse proxy o cache.

La regola 3-2-1, senza fuffa

La formula più citata è anche quella più facile da tradire. In pratica significa:

• 3 copie dei dati;
• 2 supporti diversi;
• 1 copia fuori sede.

Non è un dogma, è una soglia minima di buon senso. Se tutte le copie stanno nello stesso host, nello stesso datacenter o nello stesso account, non stai davvero riducendo il rischio. Stai solo distribuendo il punto di fallimento.

La copia fuori sede può essere un bucket cloud, un altro server, un NAS in un’altra rete, o un archivio offline. La scelta dipende dal budget e dalla criticità, ma il principio resta identico: se brucia una macchina, non devono bruciarsi anche i backup.

Backup incrementali, completi e differenziali

Per decidere la strategia, conviene distinguere i tre approcci principali:

1. completo: copia tutto; semplice da capire, più pesante;
2. incrementale: salva solo ciò che cambia dall’ultimo backup; più efficiente, ma il restore può essere più articolato;
3. differenziale: salva ciò che cambia dall’ultimo completo; equilibrio spesso valido, ma con crescita dei dati più rapida rispetto all’incrementale.

In ambienti piccoli, un completo giornaliero può essere sufficiente se i dati sono pochi. In ambienti con molti file o database grandi, una combinazione di completo settimanale e incrementali giornalieri è spesso più razionale.

La scelta non va fatta per moda, ma in base a tre metriche: tempo di backup, tempo di restore e spazio disponibile.

Retention: tenere troppo è quasi sempre un errore

Conservare tutto per sempre sembra prudente, ma spesso crea solo costi, confusione e rischio operativo. Una retention sensata deve rispondere a una domanda concreta: quanto indietro devo tornare per recuperare un errore umano, un attacco o un rollback applicativo?

Per molti casi pratici, una politica semplice può essere:

• 7 backup giornalieri;
• 4 backup settimanali;
• 6 backup mensili.

È solo un esempio, non una legge. L’importante è evitare sia la retention troppo corta, che non copre gli incidenti lenti, sia quella infinita, che finisce per saturare lo storage e rendere ingestibile la selezione dei restore point.

Verifica dell’integrità: il punto che quasi tutti saltano

Un archivio compresso può essere presente, ma corrotto. Un dump SQL può esistere, ma essere incompleto. Un backup di file può risultare leggibile ma mancare di directory essenziali. Per questo bisogna introdurre una verifica automatica, almeno su questi livelli:

• controllo della presenza del file creato;
• controllo della dimensione minima attesa;
• checksum o hash;
• test di estrazione dell’archivio;
• import di prova del database in ambiente separato.

Il test più importante resta il ripristino. Tutto il resto è utile, ma secondario.

Ripristino: progettalo prima del disastro

Il restore deve essere semplice, documentato e ripetibile. Se per ripristinare un sito servono sei passaggi mentali, tre password sparse e due file che nessuno sa dove siano, il backup è debole.

Una procedura sana dovrebbe indicare almeno:

1. dove si trova il backup;
2. quale versione ripristinare;
3. come verificare il contenuto prima dell’uso;
4. quali servizi fermare o mettere in manutenzione;
5. quale ordine seguire per file, database e configurazioni;
6. come validare il risultato dopo il restore.

Se il sito o il servizio è critico, conviene avere anche un piano di ripristino parziale: prima il database, poi i file essenziali, poi le componenti accessorie.

Automazione sì, ma con controllo

Automatizzare è corretto, purché non significhi perdere visibilità. Un job di backup dovrebbe produrre almeno un log leggibile e una notifica chiara in caso di errore. L’automazione migliore è quella che riduce il lavoro manuale senza nascondere il fallimento.

Nei pannelli hosting, ad esempio, conviene verificare sempre:

• frequenza del job;
• destinazione reale dei file;
• spazio occupato;
• notifiche email attive;
• permessi di accesso al repository esterno.

Su Linux, è utile controllare anche che il processo non venga terminato da OOM, limiti di tempo o saturazione I/O. Un backup lento non è per forza un backup rotto, ma un backup che non finisce mai è comunque un problema.

Backup e sicurezza: due temi inseparabili

Un backup non protetto diventa un bersaglio. Chi ottiene accesso al repository può cancellarlo, cifrarlo o esfiltrarlo. Per questo, la strategia minima deve includere:

• credenziali separate e con privilegi minimi;
• accesso limitato al solo repository necessario;
• autenticazione forte dove possibile;
• cifratura in transito e, se opportuno, a riposo;
• account di backup non usabile per login amministrativi generici;
• log di accesso e allarmi su cancellazioni o anomalie.

Se il contesto è esposto a ransomware, una copia offline o immutabile vale più di molte copie online. In certi scenari, è la differenza tra un recupero rapido e un fermo prolungato.

Un esempio pratico di strategia per un piccolo sito

Per un sito WordPress o per un piccolo progetto web, una configurazione ragionevole può essere questa:

1. backup giornaliero del database;
2. backup giornaliero dei file modificati;
3. backup completo settimanale;
4. copia automatica verso storage esterno;
5. retention di 30 giorni;
6. test di ripristino mensile su una copia di staging.

È un equilibrio abbastanza semplice da mantenere e abbastanza forte da assorbire gli errori più comuni: cancellazioni accidentali, aggiornamenti falliti, corruzioni del database e compromissioni parziali.

Se il sito cambia poco, si può alleggerire la frequenza dei completi. Se invece pubblica molti contenuti o riceve molti upload, la parte file va gestita con più attenzione.

Un esempio pratico di strategia per una VPS

Su una VPS con più servizi, la priorità cambia. Oltre ai file e ai database, bisogna considerare:

• configurazione di web server e proxy;
• zone DNS o configurazioni di naming, se gestite localmente;
• mail server e relative code o configurazioni;
• cron job e script di automazione;
• certificati TLS e catena completa;
• file di configurazione dei servizi di sicurezza.

Qui il rischio principale non è solo la perdita dei dati, ma la perdita della configurazione coerente del sistema. Un server ripristinato senza le sue regole può accendersi e restare comunque inutilizzabile.

Come capire se il backup è davvero affidabile

Ci sono tre domande da farsi sempre:

1. posso trovare rapidamente il backup giusto?
2. posso leggerlo e verificarlo prima di toccare il sistema?
3. posso ripristinarlo in un ambiente di prova con esito positivo?

Se una sola risposta è “no”, il piano va corretto. Un backup affidabile non è quello più complesso, ma quello che si recupera senza incertezze.

Il backup perfetto non esiste. Esiste però il backup che riesci a ripristinare quando serve, senza perdere tempo a capire dove hai sbagliato.

Checklist essenziale da tenere sempre

• hai almeno una copia fuori sede;
• salvi sia file sia database;
• usi una retention definita;
• verifichi integrità e dimensione;
• testi il restore con cadenza regolare;
• hai notifiche quando il job fallisce;
• le credenziali del backup sono separate e protette.

Se vuoi un principio operativo da ricordare, è questo: un backup utile è un backup che qualcuno ha già ripristinato almeno una volta. Tutto il resto viene dopo.

Conclusione pratica

La strategia migliore non è la più costosa né la più elegante. È quella che riduce il rischio reale con il minimo numero di pezzi fragili. Parti da copie multiple, separa i ruoli, verifica l’integrità, automatizza le notifiche e prova il ripristino con regolarità. In ambito hosting e sysadmin, la vera misura della sicurezza non è quante copie hai salvato, ma quanto velocemente riesci a tornare operativo quando qualcosa va storto.

Se il tuo backup è semplice, verificabile e ripristinabile, hai già fatto più della maggior parte degli ambienti che si considerano “protetti”.