Prove di ripristino: come programmarle senza bloccare il lavoro

Per fare prove di ripristino senza bloccare il lavoro servono tre cose: un calendario concordato con chi usa i sistemi, un ambiente di prova separato dalla produzione (o almeno un campione di dati non critico) e un verbale che registri esiti, tempi e problemi. La prova non è un'operazione straordinaria: è un appuntamento ricorrente, breve e documentato, che trasforma «il backup c'è» in «sappiamo che torna su».

Perché i backup non testati falliscono al bisogno

Un job di backup che termina «con successo» dice soltanto che dei dati sono stati copiati da qualche parte. Non dice che la copia è completa, che si apre, che l'applicazione riparte una volta ripristinata o che qualcuno sa dove trovare le credenziali necessarie. I problemi tipici emergono proprio al primo ripristino reale: manca una licenza da riattivare, una configurazione non era inclusa nella copia, il tempo di recupero è molto più lungo di quanto previsto.

La guida NIST SP 1339, pubblicata in versione finale a giugno 2026, è dedicata ai backup degli ambienti industriali (OT, operational technology), ma i suoi punti portanti valgono come principi generali: creare le copie con regolarità, integrarle nel processo di gestione dei cambiamenti, testarle e riesaminarle durante le esercitazioni di recupero. Anche la funzione Recover del NIST Cybersecurity Framework 2.0, pensato anche per le piccole imprese, colloca il ripristino tra le attività da preparare e mantenere, non tra quelle da improvvisare durante un incidente. Sono riferimenti volontari, non obblighi di legge: li citiamo perché descrivono bene un problema organizzativo comune.

Frequenza e scenari delle prove

Non esiste una cadenza valida per tutti. La frequenza va concordata in base a quanto cambiano i sistemi, a quanto sono critici e agli eventuali obblighi applicabili alla tua organizzazione. Un criterio pratico è legare le prove agli eventi, più che al solo calendario:

• a cadenza regolare, per esempio ogni trimestre o ogni semestre, per i sistemi che contano di più;
• dopo ogni cambiamento rilevante: nuovo applicativo, migrazione, modifica del sistema di backup o dello storage;
• dopo un ripristino reale, per registrare cosa ha funzionato e cosa no;
• almeno una volta l'anno in forma di esercitazione, con uno scenario più ampio che coinvolga anche chi decide, non solo chi esegue.

Anche gli scenari vanno variati: ripristinare sempre lo stesso file prova poco. Ruota tra un singolo documento, una casella di posta, un database applicativo e un intero server o macchina virtuale. Così nel tempo copri i casi che davvero ti possono capitare, dal file cancellato per errore al sistema che non riparte. Se hai già definito quanti dati puoi perdere e quanto tempo puoi stare fermo (RPO e RTO), le prove servono proprio a verificare che quegli obiettivi reggano nella pratica.

Ambiente di test e impatto sull'operatività

Serve un ambiente separato? Per i ripristini completi, sì, è la scelta più sicura: ripristinare un server sopra il suo gemello in produzione è il modo più rapido per trasformare una prova in un incidente. Le opzioni realistiche, in ordine crescente di impegno:

• ripristino di un campione: pochi file o una casella su un percorso diverso, senza toccare l'originale. Costo quasi nullo, prova limitata;
• ripristino su una macchina virtuale isolata: il server riparte in una rete separata, senza accesso alla produzione. Verifica avvio, applicazioni e dati;
• esercitazione in finestra concordata: per i sistemi più critici, una prova pianificata in un orario di bassa attività, con piano di ritorno alla situazione precedente approvato prima di iniziare.

La regola operativa è semplice: la prova deve avere un orario, un responsabile e un piano di rientro. Se non puoi dire in anticipo quanto dura e cosa fai se qualcosa va storto, la prova non è pronta. Per i sistemi legati alla produzione o agli impianti, la finestra va concordata con chi gestisce l'operatività: il controllo del processo resta ai responsabili dell'impianto.

Esempio illustrativo: il gestionale che «torna su» a metà

Esempio illustrativo. Lo scenario che segue è inventato per mostrare il metodo; non descrive un caso reale.

Una società di logistica con trenta dipendenti fa backup del gestionale ogni notte da anni, senza mai provare un ripristino. Il responsabile IT inserisce in calendario una prova trimestrale: un sabato mattina, ripristino del database su una macchina virtuale isolata. Alla prima prova il database torna su, ma l'applicazione non si apre: il servizio richiede una licenza legata all'hardware originale e una chiave conservata solo nel computer di un ex dipendente. La prova dura due ore in più del previsto, ma l'esito è prezioso: la licenza viene documentata, la chiave archiviata in modo controllato e la procedura di ripristino aggiornata. Alla prova successiva, il ripristino completo si chiude nei tempi previsti. Nessun incidente reale era nel frattempo avvenuto: meglio scoprire la lacuna un sabato di prova che un lunedì di emergenza.

Il verbale della prova e le evidenze da conservare

Dopo ogni test, documenta. Non serve un modulo complesso: serve che fra sei mesi chiunque possa ricostruire cosa è successo. Un verbale utile contiene:

• data, durata e sistema oggetto della prova;
• scenario testato (file, database, server intero) e ambiente usato;
• esito: ripristino riuscito, parziale o fallito, con i tempi misurati;
• problemi emersi e azioni correttive assegnate, con un responsabile e una scadenza;
• confronto con gli obiettivi attesi, se li hai definiti.

Queste evidenze valgono doppio: migliorano la procedura e dimostrano la diligenza dell'organizzazione. Per le aziende nel perimetro di NIS2, la capacità di documentare misure e verifiche sul ripristino è parte del dossier che un audit può richiedere: ne parliamo nell'articolo sulle evidenze di ripristino richieste da NIS2. Se le prove fanno parte di un runbook di ripristino condiviso, ogni verbale aggiorna anche la conoscenza di chi dovrà usarlo.

Il contributo di OverZeus: sorveglianza, non un motore di backup

OverZeus non esegue i backup né i ripristini: per quelli restano gli strumenti che già usi. Il contributo è di sorveglianza e coordinamento, tramite le integrazioni concordate con le piattaforme esistenti. In questo ambito lavora Penelope, l'agente dedicato a backup e continuità: osserva lo stato dei job sulle piattaforme collegate, tiene evidenza del calendario delle prove concordato e segnala quando una prova prevista non risulta eseguita o quando un job smette di completarsi. Le segnalazioni arrivano ai responsabili con il contesto necessario per decidere; la scelta su come e quando intervenire resta alle persone, e un intervento attivo richiede sempre l'approvazione prevista dal piano.

Come descritto nella pagina dedicata alla continuità operativa, quando un ripristino richiede un intervento coordinato, la proposta presentata ai responsabili indica in anticipo durata prevista dell'interruzione, servizi coinvolti e procedura di ritorno alla situazione precedente: gli stessi elementi che rendono una prova sicura anziché rischiosa.

Domande frequenti sulle prove di ripristino

Ogni quanto conviene provare un ripristino?

Dipende da criticità e ritmo dei cambiamenti: una cadenza regolare per i sistemi importanti (per esempio trimestrale o semestrale), più una prova dopo ogni modifica rilevante e un'esercitazione annuale più ampia è una combinazione ragionevole da adattare alla tua realtà. Non è una regola universale: concorda la frequenza con chi gestisce i sistemi e riesaminala nel tempo.

Serve per forza un ambiente separato?

Per i ripristini completi sì, è la via più sicura; per prove leggere basta un ripristino di un campione su un percorso diverso dall'originale. Ciò che non va fatto è sovrascrivere la produzione «per vedere se funziona».

Cosa documentare dopo ogni test?

Data, scenario, ambiente, esito con i tempi misurati, problemi trovati e correzioni assegnate con responsabile e scadenza. Il verbale è la prova che la verifica è avvenuta e la base per migliorare la volta successiva.

Un appuntamento ricorrente, non un'emergenza

Le prove di ripristino funzionano quando smettono di essere straordinarie: calendario condiviso, scenari che ruotano, ambiente che non mette a rischio la produzione e un verbale che conserva esiti e correzioni. Se i tuoi backup non sono mai stati testati, la prima prova è il miglior investimento possibile, perché trasforma un'incognita in un dato misurato. E se il problema è che le copie stesse potrebbero non resistere a un attacco, il passo successivo è capire perché con il ransomware il backup da solo non basta.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus