«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.
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.
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.
Il collegamento con RTO, RPO e continuità
I test hanno un contesto più ampio: gli obiettivi di continuità. RTO (quanto può durare un fermo) e RPO (quanto lavoro si può perdere) 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. Ed è una delle difese più concrete contro gli scenari peggiori, ransomware incluso, di cui parlo nell'articolo sulle minacce informatiche per le PMI.
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.