«I backup li facciamo tutte le notti.» È una delle frasi che sento più spesso, e quasi sempre viene detta con sincera tranquillità. La domanda che segue, però, cambia il clima della conversazione: «quando avete provato l'ultima volta a ripristinare qualcosa?». Il silenzio che segue è la ragione di questo articolo. Un backup non testato non è una protezione: è un'ipotesi. E le ipotesi, nel giorno in cui servono, a volte si rivelano sbagliate.
Job completato non significa recupero riuscito
Il report «backup completed» dice una cosa sola: il software ha eseguito il proprio compito senza errori bloccanti. Non dice che i dati copiati siano integri e leggibili, che la copia contenga davvero tutto ciò che serve, che il ripristino funzioni sull'infrastruttura disponibile, né che i tempi di recupero siano compatibili con le esigenze del business. Tra «il job è verde» e «l'azienda sa ripartire» c'è tutta la distanza che un test di ripristino serve a misurare.
I difetti che un test fa emergere sono concreti e ricorrenti: copie che escludono da mesi una cartella o un database aggiunto dopo la configurazione iniziale; file cifrati o corrotti che nessuno ha mai aperto; retention troppo corte per accorgersi in tempo di un problema; copie raggiungibili dallo stesso ambiente che dovrebbero proteggere — quindi cifrabili da un ransomware insieme agli originali; procedure che esistono solo nella testa di una persona.
Le due domande che vengono prima di tutto
Prima ancora di parlare di test, servono due numeri che non sono tecnici e che non spetta all'IT decidere: quanto a lungo l'azienda può stare ferma, e quanto lavoro può permettersi di perdere. Il primo si chiama RTO, il secondo RPO, ma le sigle contano poco: contano le due risposte, perché determinano tutto il resto — quanto spesso si copiano i dati, con quale tecnologia, con quale spesa.
Questi due numeri devono essere decisi dalla direzione, non dedotti dalla configurazione esistente. Il verso corretto è: l'azienda dichiara quanto può sopportare, la tecnologia si adegua. Il verso che trovo più spesso è l'opposto — si guarda com'è configurato il backup e si assume che quel comportamento sia l'obiettivo. È un modo elegante per non scegliere mai.
Cosa si testa, esattamente
«Testare il backup» è un'espressione vaga. Un test serio definisce prima oggetto e scopo:
- ripristino di singoli file o cartelle: lo scenario più frequente nella vita reale (cancellazioni accidentali, versioni precedenti);
- ripristino di un database o di un'applicazione: verifica che dati, configurazioni e dipendenze tornino coerenti e utilizzabili;
- ripristino completo di un sistema: server o macchina virtuale ricostruita da zero, per verificare la capacità di ripartire dopo una perdita totale;
- ripristino di dati SaaS e cloud: posta, file condivisi, gestionali in cloud — dove spesso si scopre che «il fornitore fa il backup» significa meno di quanto si credesse.
Questi quattro casi non hanno lo stesso peso né lo stesso costo: si può salire di livello gradualmente, e ogni gradino risponde a una domanda diversa.
Nessuna azienda testa tutto ogni volta. Si lavora per scenari e campionamento: si parte dai sistemi critici per il business, si varia l'oggetto del test nel tempo — un trimestre un database, il successivo un ripristino completo — e si copre progressivamente il perimetro. L'importante è che la selezione sia una scelta ragionata e documentata, non il caso.
Autorizzazioni e ambiente isolato
Un test di ripristino condotto male può creare danni veri: sovrascrivere dati di produzione, generare conflitti di rete, esporre dati sensibili in ambienti non protetti. Per questo servono regole preliminari:
- il test si esegue in un ambiente isolato dalla produzione — una rete separata, un host dedicato, risorse temporanee — mai «per un attimo» sui sistemi in uso;
- chi esegue il test deve avere autorizzazioni chiare: cosa può ripristinare, dove, con quali dati;
- i dati ripristinati a scopo di test vanno protetti e poi eliminati: contengono le stesse informazioni personali e riservate degli originali, e meritano le stesse tutele. Non è un dettaglio formale: è un obbligo sostanziale, come ricordo nell'articolo su GDPR e obblighi tecnici per le PMI.
Cosa misurare: tempi, integrità, dipendenze
Durante il test, tre famiglie di verifiche danno la sostanza del risultato.
I tempi. Quanto è durato il ripristino, dall'inizio alla piena utilizzabilità? Il dato va confrontato con il tempo di fermo che il business può sostenere. Scoprire che il ripristino completo del gestionale richiede due giorni non è un fallimento del test: è un'informazione preziosa, ottenuta al costo di un'esercitazione invece che di un incidente.
L'integrità. I dati ripristinati sono completi, leggibili e coerenti? Un database che si apre ma ha perso le transazioni dell'ultimo giorno racconta qualcosa di importante sulla frequenza delle copie e su quanto lavoro l'azienda può permettersi di perdere.
Le dipendenze. Il sistema ripristinato funziona davvero nel suo contesto? Applicazioni che ripartono ma non trovano il server di licenze, integrazioni che puntano a indirizzi cambiati, credenziali di servizio scadute: gli incidenti reali falliscono quasi sempre qui, nei collegamenti tra i sistemi più che nei sistemi.
Le evidenze: se non è scritto, non è successo
Ogni test deve lasciare una traccia scritta, anche sintetica: data, oggetto del test, scenario, chi lo ha eseguito, durata, esito, anomalie rilevate. Le evidenze servono a tre scopi: dare alla direzione un indicatore onesto della capacità di recupero; costruire una storia confrontabile nel tempo; e documentare la diligenza dell'azienda, anche in ottica di conformità. Un test riuscito senza verbale vale poco; un test fallito con un buon verbale vale molto, perché produce azioni.
Anomalie e azioni correttive
Il valore del test sta in ciò che accade dopo. Ogni anomalia rilevata — un tempo eccessivo, un dato mancante, una procedura poco chiara — deve trasformarsi in un'azione con un responsabile e una scadenza: correggere la configurazione delle copie, allungare la retention, separare le copie dall'ambiente di produzione, riscrivere la procedura, ripetere il test dopo la correzione. Un registro delle anomalie che si chiudono nel tempo è la prova che il processo funziona; lo stesso errore trovato in due test consecutivi è la prova che non sta funzionando.
È questo che trasforma il test da adempimento a ciclo: si pianifica, si esegue, si misura, si registra, si corregge, e alla prova successiva si verifica che la correzione abbia funzionato.
Ogni quanto, e chi lo fa
Non esiste una frequenza valida per tutti, ma esiste un criterio: si testa più spesso ciò che, fermandosi, ferma l'azienda. Nelle realtà che seguo funziona bene un calendario su tre livelli. Una verifica sintetica mensile sui sistemi critici, che può limitarsi al recupero di qualche file e al controllo che le copie coprano ciò che devono coprire. Un test sostanziale trimestrale, con oggetto a rotazione: un database una volta, un'applicazione un'altra, i dati in cloud un'altra ancora. E almeno una volta l'anno un ripristino completo di un sistema importante in ambiente isolato, cronometrato, con verbale — l'unico che misuri davvero la capacità di ripartire.
A questo si aggiunge una regola che vale più del calendario: si testa dopo ogni cambiamento significativo. Un server nuovo, una migrazione, un cambio di gestionale, un fornitore che subentra. Le configurazioni di backup si rompono soprattutto in quei momenti, ed è lì che passano mesi prima che qualcuno se ne accorga.
Sul chi, la distinzione che conta è tra chi esegue e chi risponde. Il test può eseguirlo il fornitore che gestisce i sistemi — è normale e spesso è il modo più efficiente. Ma il verbale deve arrivare a qualcuno in azienda che lo legge, ne verifica la coerenza con gli obiettivi dichiarati e chiede conto delle anomalie aperte. Se il fornitore esegue, misura, valuta e archivia da solo, l'azienda non ha un controllo: ha una rassicurazione.
Gli errori che vedo più spesso
Alcuni difetti ricorrono con una regolarità sorprendente, e conviene cercarli subito perché sono quelli che fanno danno.
La copia che vive accanto all'originale. Un disco di rete collegato al dominio, raggiungibile con le stesse credenziali dei server: nello scenario ransomware viene cifrato insieme a tutto il resto. Serve almeno una copia separata — credenziali diverse, supporto scollegato, oppure una forma che impedisca la cancellazione per un periodo definito. È la difesa più concreta contro gli scenari peggiori di cui parlo nell'articolo sulle minacce informatiche per le PMI.
Il perimetro fermo al giorno dell'installazione. Il backup copre ciò che esisteva quando è stato configurato. Ogni cartella, database o macchina virtuale aggiunta dopo esiste solo se qualcuno l'ha inserita nel job. Verificare che l'elenco delle cose salvate corrisponda all'elenco delle cose importanti è un controllo di dieci minuti che quasi nessuno fa.
I dati in cloud dati per scontati. Posta, file condivisi e gestionali in SaaS spesso non hanno backup nel senso in cui lo intende l'azienda: il fornitore garantisce la continuità del servizio, non il recupero di ciò che l'utente cancella o che un attacco compromette, e i tempi di conservazione predefiniti sono più corti di quanto si immagini. È lo stesso equivoco sulle responsabilità che affronto nell'articolo su cloud e on-premise.
La procedura in testa a una persona. Finché il ripristino lo sa fare solo il tecnico che ha configurato tutto, la capacità di recupero dell'azienda coincide con la sua reperibilità. Il test serve anche a questo: a scoprire se la procedura scritta è sufficiente perché la esegua qualcun altro.
Il collegamento con la continuità operativa
I test hanno un contesto più ampio: gli obiettivi di continuità. RTO e RPO sono decisioni del business, non parametri tecnici: spetta alla direzione stabilirli, e spetta ai test verificare che siano realistici. Quando il test dice che il ripristino richiede più tempo dell'RTO dichiarato, le strade sono due: investire per accelerare il recupero, o rivedere l'obiettivo con onestà. Entrambe sono decisioni legittime; quella illegittima è non scegliere.
Questo è il punto in cui il backup smette di essere un tema tecnico e diventa gestione: obiettivi approvati, test pianificati, evidenze registrate, anomalie corrette, riesame periodico. È il perimetro che presidio nel servizio di backup e capacità di ripristino, in collegamento con la business continuity e il disaster recovery.
Da dove partire
Se nella tua azienda non è mai stato eseguito un test di ripristino documentato, il primo passo non richiede progetti: scegliere un sistema critico, definire uno scenario, eseguire il test in ambiente isolato e scrivere che cosa è emerso. Qualunque sia l'esito, l'azienda ne uscirà sapendo qualcosa di vero sulla propria capacità di ripartire. Se vuoi un supporto per impostare il processo — obiettivi, calendario, evidenze e responsabilità — contattami: è uno degli interventi con il miglior rapporto tra semplicità e riduzione del rischio.