Un backup non testato non è un backup

Quasi ogni azienda dice di avere i backup. Molte meno saprebbero rispondere a una domanda più scomoda: se domani mattina il server principale non si accende, quanto tempo serve per tornare operativi, e con quali dati?

Tra le due cose c’è la stessa distanza che separa avere un estintore dall’aver mai controllato che sia carico. Il backup è una copia; la capacità di ripartire è un processo. Ed è il secondo che salva un’azienda.

Perché i backup falliscono proprio quando servono

Un sistema di backup può segnalare “completato” per mesi e salvare, nel frattempo, dati inutilizzabili. Le cause sono quasi sempre banali, ed è per questo che restano nascoste:

• Copie incoerenti. Un database copiato a file mentre è in scrittura può risultare corrotto al ripristino. Il backup “c’è”, ma il gestionale non riparte.
• Esclusioni dimenticate. Una nuova cartella condivisa, un secondo disco aggiunto alla macchina virtuale, un servizio spostato su un altro server: il piano di backup è rimasto quello di due anni fa.
• Chiavi e credenziali perse. I backup cifrati sono una buona pratica, a patto che la chiave non stia solo sul server che si è rotto, o nella testa di una persona che nel frattempo ha cambiato lavoro.
• Copie raggiungibili dall’attacco. I ransomware moderni non si limitano a cifrare i dati di produzione: cercano attivamente i backup accessibili in rete e li cancellano o li cifrano prima di farsi notare.
• Tempi di ripristino mai misurati. I dati ci sono, ma scaricarli da un servizio remoto con la connessione dell’ufficio richiede tre giorni. Per l’azienda è come non averli.

In tutti questi casi il problema non si vede finché qualcuno non prova a ripristinare. Per questo l’unico modo serio di giudicare un backup è il ripristino.

Il backup si giudica dal ripristino, non dalla copia.

Due numeri da decidere prima di qualsiasi strumento

Prima di parlare di software, dischi o cloud, servono due decisioni di business. Non tecniche: di business.

Quanti dati posso permettermi di perdere? È il Recovery Point Objective (RPO). Se il backup si fa ogni notte e il guasto arriva alle 17, si perde una giornata di lavoro. Per un archivio documentale può andare bene; per un gestionale ordini forse no.

Quanto tempo posso restare fermo? È il Recovery Time Objective (RTO). Comprende tutto: accorgersi del problema, decidere cosa fare, recuperare le copie, ripristinare, verificare che funzioni. Quasi sempre è più lungo di quanto si immagina, perché si pensa solo al tempo di copia.

Questi due numeri vanno fissati per ogni sistema, non per l’azienda nel suo complesso. Il server di posta, il gestionale, il file server e il sito web hanno criticità diverse, e trattarli allo stesso modo significa spendere troppo su alcuni e troppo poco su altri.

Una tabella semplice è già un grande passo avanti:

Sistema	Dati perdibili (RPO)	Fermo accettabile (RTO)	Chi se ne accorge per primo
Gestionale	1 ora	mezza giornata	amministrazione
File server	1 giorno	1 giorno	tutti
Sito web	1 settimana	2 giorni	clienti

La regola 3-2-1, aggiornata

La regola classica è nota: tre copie dei dati, su due supporti diversi, di cui una fuori sede. È vecchia, ma regge ancora, perché protegge da tre scenari diversi: il guasto di un disco, il guasto di un intero sistema di archiviazione, il disastro fisico (incendio, furto, allagamento).

Oggi la integro con altri due elementi, spesso riassunti come 3-2-1-1-0:

• Una copia non modificabile. Immutabile (cioè protetta dalla cancellazione per un periodo definito) oppure scollegata dalla rete. È la difesa principale contro i ransomware, perché nemmeno un amministratore compromesso può cancellarla.
• Zero errori di verifica. Le copie vengono controllate automaticamente e i ripristini vengono provati. Un backup che non ha mai superato una verifica non conta.

Cosa significa testare davvero

Aprire la console del software di backup e vedere tutto verde non è un test. È un controllo che il processo di copia sia terminato. Un test vero risponde alla domanda: “se dovessi ripartire adesso, ci riuscirei, in quanto tempo e con quali dati?”.

Esistono tre livelli di verifica, e servono tutti.

1. Verifica di integrità. Il sistema di backup controlla che i dati salvati non siano corrotti, confrontando i checksum. Con Proxmox Backup Server, per esempio, si pianificano verify job periodici che rileggono i blocchi salvati. È automatico ed economico: va sempre attivato.

2. Ripristino tecnico. Si ripristina una macchina virtuale o un database in un ambiente isolato, senza toccare la produzione, e si controlla che si avvii. Questo scopre i problemi di coerenza, i dischi mancanti, le configurazioni dimenticate.

3. Ripristino funzionale. Qualcuno che usa davvero il sistema apre l’applicazione ripristinata e controlla che i dati siano quelli attesi: gli ordini dell’ultimo giorno, gli ultimi documenti caricati, le anagrafiche aggiornate. È l’unico test che garantisce che l’azienda possa lavorare.

Una procedura di test in sei passi

1. Scegli il sistema da testare, a rotazione, partendo dal più critico.
2. Ripristina l’ultima copia in un ambiente separato (una rete isolata, un host di test).
3. Cronometra ogni fase: recupero della copia, ripristino, avvio, verifica.
4. Verifica i dati con chi usa il sistema ogni giorno, su controlli concreti e ripetibili.
5. Confronta i tempi misurati con l’RTO deciso. Se sono più lunghi, il piano va rivisto: non la tabella.
6. Aggiorna la procedura scritta con tutto quello che non era documentato e che hai dovuto scoprire durante il test.

Il sesto punto è il più sottovalutato. La prima volta che si fa un test emergono sempre passaggi “ovvi” che nessuno aveva scritto: una password, un ordine di avvio dei servizi, una regola del firewall. È esattamente l’informazione che manca il giorno di un’emergenza vera.

La coerenza delle copie: un dettaglio che non è un dettaglio

Copiare una macchina virtuale mentre lavora è possibile, ma bisogna farlo nel modo giusto. Due accorgimenti evitano la maggior parte dei problemi:

• Agente nel sistema ospite. In ambiente Proxmox, il QEMU guest agent permette di “congelare” per un istante il file system della macchina durante lo snapshot, ottenendo una copia coerente. Su Windows lavora insieme ai servizi di snapshot del sistema. Va installato e abilitato su ogni macchina, e controllato quando se ne aggiungono di nuove.
• Backup applicativo per i database. Per i database importanti affianco sempre alla copia della macchina un’esportazione nativa (un dump) pianificata. Occupa poco e si ripristina in modo indipendente, anche su un server diverso.

E i servizi in cloud?

Posta elettronica, documenti condivisi e CRM in abbonamento sono spesso considerati “già al sicuro”. Non è così. I fornitori garantiscono che il servizio sia disponibile; non garantiscono di poter recuperare quello che un utente, un’integrazione difettosa o un attacco hanno cancellato o sovrascritto. I cestini e le versioni precedenti hanno durate limitate e non sono pensati come backup.

Se un dato è importante per l’azienda, la domanda “dove sta la copia che controllo io?” vale anche per il cloud. Esistono strumenti dedicati per salvare caselle di posta e archivi documentali su un’infrastruttura propria o su un secondo fornitore.

Quanto spesso testare

Non esiste una frequenza giusta per tutti, ma un’indicazione ragionevole per una piccola o media impresa è questa:

• verifica di integrità: automatica, almeno settimanale;
• ripristino tecnico: mensile, a rotazione sui sistemi;
• ripristino funzionale dei sistemi critici: almeno due volte l’anno, e sempre dopo un cambiamento importante (migrazione, nuovo gestionale, nuovo server).

Più importante della frequenza è la regolarità: un test fatto ogni sei mesi da anni vale più di una prova approfondita fatta una volta sola.

Checklist: il tuo backup è un backup?

Se rispondi “no” o “non so” a una di queste domande, c’è del lavoro da fare.

• Per ogni sistema importante è definito quanti dati si possono perdere e quanto si può restare fermi?
• Esiste almeno una copia fuori sede?
• Esiste almeno una copia che un attaccante con accesso alla rete non può cancellare?
• Le verifiche di integrità sono automatiche e qualcuno legge gli avvisi?
• Negli ultimi sei mesi è stato ripristinato con successo almeno il sistema più critico?
• Il tempo di ripristino misurato è compatibile con quello accettabile?
• Esiste una procedura scritta, che possa seguire anche una persona diversa da chi l’ha preparata?
• Chiavi di cifratura e credenziali del backup sono custodite in un luogo diverso dai server che proteggono?

Un backup che supera questa lista non è solo una copia: è la garanzia che l’azienda, dopo un guasto, riparte. Ed è l’unico tipo di backup per cui valga la pena pagare.