Ogni quanto va fatta una prova di ripristino?

Il ripristino di un campione va provato ogni mese, quello di un servizio intero almeno una volta all'anno. Per i soggetti in perimetro DORA il test annuale dei piani di continuità è un obbligo (Regolamento UE 2022/2554); fuori da quel perimetro nessuna norma fissa una frequenza, quindi la cadenza si decide in base a quanto cambia l'infrastruttura, e va aggiunta una prova straordinaria dopo ogni cambiamento che tocca il percorso di recupero: una migrazione, un nuovo gestionale, il passaggio a un altro fornitore di backup.

Un test di ripristino richiede di fermare la produzione?

Nel caso normale no, e dipende dal tipo di prova. Il ripristino di un campione e la ricostruzione di un servizio intero si fanno in un ambiente separato, mentre la produzione continua a lavorare. Fa eccezione la prova di commutazione, in cui il servizio viene spostato davvero sul sito secondario e poi riportato indietro: quella tocca la produzione e si pianifica in una finestra concordata, di solito una volta all'anno. Prima di avviare l'applicativo nell'ambiente di prova controllo quattro cose: che la destinazione del ripristino sia l'ambiente di prova e non il sistema reale, che la rete dell'ambiente di prova non raggiunga i sistemi in produzione, che le integrazioni verso l'esterno siano disattivate o puntate su ambienti di test, e che le attività automatiche che inviano email o documenti ai clienti siano spente. Senza questi controlli un ripristino di prova manda fatture vere a clienti veri. E poiché la copia ripristinata contiene dati personali veri, l'ambiente di prova va protetto come la produzione e cancellato a prova conclusa.

Cos'è una prova di ripristino?

Ripristinare davvero dati e servizi da un backup, per misurare i tempi reali di ripartenza invece di quelli dichiarati.

Una prova di ripristino è l'esercizio di rimettere in funzione dati o servizi partendo dalle copie di backup, in condizioni controllate e con un cronometro. Non è la verifica automatica che il job di backup ha terminato senza errori, che dice soltanto che qualcosa è stato scritto: si arriva fino al dato che qualcuno può usare, quindi si recuperano i supporti, si ricostruisce il sistema, si riapplicano le configurazioni, si riavviano le integrazioni, e alla fine è chi usa quel dato ogni giorno a dire se torna. La distinzione conta perché i due esiti divergono spesso: backup completati per mesi e archivi incompleti, chiavi di cifratura conservate solo nel sistema andato perso, licenze impossibili da riattivare senza il fornitore. La prova è il modo affidabile di scoprire questi difetti in una giornata scelta a calendario, con i colleghi disponibili e senza pressione, invece che durante un incidente.

Leggi anche: Backup 3-2-1 · Tre copie dei dati, su due tipi di supporto, una fuori sede: la soglia minima perché un backup sopravviva all'incidente.

Il risultato è un fatto, non un'opinione

Quasi ogni intervento di sicurezza produce una valutazione discutibile: una configurazione è più o meno robusta, una policy più o meno adeguata, un rischio più o meno accettabile. Una prova di ripristino produce invece due dati binari e due numeri: il servizio è ripartito oppure no, i dati sono coerenti oppure no, ci sono volute sei ore e venti minuti, e si sono persi i venti minuti di lavoro fra l'ultimo punto di ripristino e il guasto. I due numeri sono confrontabili con l'RTO e l'RPO dichiarati, e quando li superano la discussione finisce: non c'è modo di argomentare che il piano funziona. Vale anche il contrario: se rientrano, il piano non è ancora dimostrato, perché la prova parte da un incidente noto e da persone già presenti, mentre l'RTO decorre dal guasto e comprende il tempo di accorgersene e di decidere. È anche la ragione per cui la prova viene rimandata, perché è il solo controllo che può smentire pubblicamente chi lo ha progettato, e va impostata come misura di un sistema, non come esame di una persona.

Come si conduce, in pratica

Il livello minimo utile è il ripristino periodico di un campione: alcuni file, una casella di posta, una tabella, verificati da un utente e non solo dal reparto tecnico. Il livello che dice qualcosa sulla continuità è il ripristino di un servizio intero in un ambiente isolato, con l'applicativo che riparte e le integrazioni ricollegate. In una PMI manifatturiera significa risalire dal backup a un gestionale funzionante su un'infrastruttura pulita, controllando che l'ultimo ordine registrato prima dell'interruzione simulata ci sia davvero. Chi descrive gli ambienti con Infrastructure as Code parte avvantaggiato, perché la ricostruzione è codice già scritto e la prova diventa ripetibile. Di ogni esecuzione restano il tempo misurato, i passaggi manuali emersi e le anomalie da correggere.

Perché conta per chi decide

Una prova di ripristino documentata è l'evidenza che un piano di continuità esiste davvero, ed è quanto chiedono le normative sulla resilienza operativa come il DORA per il settore finanziario e i suoi fornitori, la NIS2 per i settori che ne rientrano, e le verifiche di una polizza cyber, che distinguono tra procedure scritte e procedure testate. Costa tempo pianificato e ne restituisce due cose: un tempo di ripartenza reale su cui basare le decisioni e, quasi sempre, un elenco di dipendenze non censite. Va programmata come un'attività ricorrente, perché un piano validato due anni fa descrive un'infrastruttura che nel frattempo è cambiata, e i suoi risultati vanno letti insieme alla regola del backup 3-2-1, che dice com'è fatta la copia ma non se serve a ripartire.