Test di ripristino: con che frequenza farli e come

TL;DR

Il DR non testato non funziona. Esistono quattro livelli di test (tabletop, walkthrough, partial failover, full failover) e una buona pratica matura li combina in un calendario annuale. NIST SP 800-34 e ISO 22301 consigliano almeno un test completo all'anno; nei settori soggetti a NIS2 il consiglio diventa obbligo di fatto.

I quattro livelli di test

1. Tabletop drill (annuale)

Una riunione di 2 ore in cui un facilitatore presenta uno scenario ("ransomware ha cifrato il file server alle 14:00") e i partecipanti raccontano cosa farebbero. Niente sistemi toccati. Costo bassissimo, valore enorme: scopre runbook obsoleti e buchi di responsabilità.

2. Walkthrough tecnico (semestrale)

Un sistemista percorre il runbook DR su un singolo workload non in produzione. Verifica che le credenziali siano corrette, che i comandi descritti funzionino, che le dipendenze esterne (DNS, KMS, SaaS) siano raggiungibili.

3. Failover parziale (trimestrale)

Failover vero di un singolo workload (es. file server) verso il sito DR, senza dirottare il traffico produttivo. Misura l'RTO reale di quel sistema e l'integrità dei dati ripristinati. Sefthy include questo livello in tutti i piani.

4. Full failover (annuale)

Failover di tutto lo stack in ambiente di test. È il test che dà il numero RTO reale dell'azienda. Richiede mezza giornata di preparazione + 4-6 ore di esecuzione. Va programmato fuori orario.

Frequenze raccomandate

Standard di riferimento:

• NIST SP 800-34: test annuali completi + drill aggiuntivi quando cambiano sistemi critici.
• ISO 22301:2019: esercitazioni a intervalli pianificati, almeno annuali.
• NIS2 articolo 21: test periodici, senza specificare frequenza.

In pratica, una rotazione efficace è:

• 1 tabletop ogni anno;
• 2 walkthrough all'anno;
• 4 failover parziali all'anno (uno per workload critico in rotazione);
• 1 full failover all'anno.

Cosa misurare in ogni test

Cinque metriche minime:

1. RTO reale per workload (cronometrato);
2. RPO reale (ultimo dato presente nel sistema ricoverato);
3. integrità dei dati (hash, contatori, transazioni di test);
4. comportamento dei client (tempo di riconnessione, eventuali errori);
5. deviazioni dal runbook (passaggi non chiari, dipendenze mancanti).

Documentate in un verbale standard. Diventa l'evidenza che gli auditor cercano.

Errori frequenti

• test in produzione senza fallback: rischio inutile. Usate ambiente di test isolato.
• test sempre alla stessa ora: trovate i problemi della stessa ora. Variate.
• test senza personale di backup: chi conosce solo il senior va in vacanza il giorno del test reale.
• non chiudere le azioni correttive: aprite un ticket per ogni gap rilevato e tracciatelo.

Sefthy DR Simulation

La feature DR Simulation permette di eseguire test di failover senza disturbare la produzione: la VM ricoverata gira in un VLAN isolato, riceve un IP di test e gli amministratori la verificano con strumenti standard. Tempi e log esportabili in PDF per audit.

FAQ

Quanto dura un full failover di un'azienda media?

Per un'azienda da 50-100 dipendenti con 8-15 server: 4-6 ore di esecuzione + 2-3 ore di preparazione e debrief.

Posso testare in produzione?

Solo failover parziali in ambienti veramente isolabili. Mai full failover. Il rischio di prolungare un fermo non vale lo sforzo risparmiato.

Servono fornitori esterni per i test?

Per tabletop e walkthrough, no. Per full failover è utile avere un consulente esterno la prima volta — diventano il riferimento per gli audit successivi.

Per il calcolo dell'RTO post-test, vedi Come calcolare il RTO. Per la differenza fra snapshot e replica continua nei test, leggi Snapshot vs replica continua.