Disaster Recovery Testing: simulare un guasto e misurare i tempi di ripristino

Il Disaster Recovery Testing non è un esercizio teorico: è il momento in cui scopri se il tuo piano di ripristino funziona davvero, quanto tempo serve per tornare online e quali punti si rompono prima del resto. In un ambiente hosting, VPS, server web o piattaforma applicativa, il valore non sta nel “fare il backup”, ma nel sapere con precisione quanto ci metti a ripartire e quanti dati perdi in uno scenario realistico.

La regola più utile è semplice: se non hai misurato il ripristino in condizioni simili alla produzione, non hai ancora un piano di Disaster Recovery, hai solo una speranza documentata. Il test serve a trasformare quella speranza in numeri: RTO, RPO, tempi di failover, tempi DNS, tempi di avvio servizi, tempi di verifica applicativa e tempi di rollback.

Questa guida mostra come simulare un guasto in modo controllato, come preparare il test, come misurare i tempi, come leggere i risultati e come correggere i punti deboli senza fare danni inutili.

Obiettivo del test

Lo scopo non è “rompere tutto”, ma verificare tre cose essenziali:

• RTO: il tempo massimo accettabile per tornare operativi.
• RPO: la quantità massima di dati che puoi perdere in caso di incidente.
• Affidabilità della procedura: backup, restore, DNS, servizi, dipendenze e controlli finali devono funzionare in sequenza.

Un test serio risponde a domande pratiche: il backup è leggibile? Il database si ripristina senza corruzioni? Il sito parte ma resta in errore per cache, permessi o configurazione? Il DNS impiega 5 minuti o 24 ore a propagarsi? Il team sa chi fa cosa e in che ordine?

Prima di iniziare: definisci lo scenario

Non esiste un solo tipo di disastro. Scegli lo scenario da simulare in base al rischio reale. I casi più utili sono questi:

• Guasto del server: macchina non avviabile, disco corrotto, kernel panic, VPS indisponibile.
• Guasto applicativo: PHP rotto, WordPress non carica, servizio web in 5xx, errore di configurazione.
• Guasto database: MariaDB/MySQL non parte, database corrotto, restore incompleto.
• Guasto DNS: record errato, nameserver irraggiungibile, propagazione lenta.
• Guasto operativo: credenziali mancanti, backup non accessibile, procedura non documentata.

Per un primo test conviene partire dallo scenario più frequente e meno distruttivo: ripristino di un sito o di un servizio su ambiente separato, usando un backup reale ma senza coinvolgere produzione. È il modo più sicuro per scoprire se il processo regge.

Preparazione del test

Un test fatto male produce numeri falsi. Prima di simulare il guasto, prepara questi elementi:

1. Ambiente di prova: VPS secondaria, server di staging o istanza temporanea con risorse sufficienti.
2. Backup verificabile: file, database, configurazioni, DNS zone, cron, certificati, variabili applicative e, se necessario, posta.
3. Lista delle dipendenze: PHP version, estensioni, versione MariaDB/MySQL, Redis, cache, web server, pannello di controllo.
4. Metriche da misurare: ora di inizio, ora di fine, punto di failover, tempo di restore, tempo di avvio servizi, tempo di validazione.
5. Ruoli: chi esegue il restore, chi verifica il sito, chi approva il ritorno online.

Se hai un pannello come cPanel, Plesk o FastPanel, verifica anche dove si trovano backup, snapshot, DNS, log e gestione servizi. Se lavori da terminale, prepara in anticipo credenziali e percorsi. Il test deve essere eseguibile senza improvvisazione.

Come simulare un guasto in modo sicuro

La simulazione deve essere reversibile e controllata. Evita di testare direttamente in produzione se non hai un piano di rollback chiaro. Le simulazioni più sicure sono queste:

1. Simulazione di restore su ambiente isolato

È la più consigliata. Prendi un backup recente e ripristinalo in un ambiente separato. In questo modo puoi misurare il tempo totale di ripristino senza interrompere i servizi reali. Il test deve includere file, database e configurazioni minime necessarie al funzionamento.

2. Simulazione di indisponibilità servizio

Puoi fermare temporaneamente un servizio non critico su un ambiente di test, ad esempio web server o database, per verificare monitoraggio, alert e procedura di riavvio. L’obiettivo è capire se il team riconosce il problema e applica il fix corretto.

3. Simulazione DNS o cambio endpoint

Puoi testare il passaggio da un server all’altro modificando record in un dominio di prova o in un sottodominio dedicato. Questo serve a misurare la propagazione DNS e il comportamento dell’applicazione dopo il cambio.

4. Simulazione di corruzione logica

In ambiente di staging puoi verificare il ripristino di un database alterando dati non critici o sostituendo una tabella di prova. È utile per scoprire se il processo di restore include anche controlli di consistenza.

La scelta migliore, nella maggior parte dei casi, è partire dal restore completo su staging: è realistico, poco rischioso e produce dati utili.

Misurare i tempi: cosa annotare davvero

Il test è inutile se alla fine scrivi solo “ripristino riuscito”. Devi misurare ogni fase. Le variabili minime sono queste:

• T0: inizio incidente o inizio test.
• T1: rilevazione del problema.
• T2: decisione di avvio procedura DR.
• T3: avvio ripristino.
• T4: fine restore dati.
• T5: servizi online.
• T6: validazione applicativa completata.
• T7: ritorno operativo confermato.

Da questi dati ricavi i tempi reali. Ad esempio, se il backup si ripristina in 14 minuti, ma l’applicazione torna utile solo dopo 38 minuti per problemi di permessi, cache e DNS, il tuo RTO reale non è 14 minuti ma 38. È un errore comune confondere il restore del dato con il ripristino del servizio.

Annota anche i colli di bottiglia: compressione lenta, storage remoto, rete satura, database grande, verifica checksum troppo lunga, cache da ricostruire, certificati da reinstallare, cron da riattivare.

Checklist operativa del test

Una sequenza semplice evita errori e rende il test ripetibile.

1. Congela lo scenario: definisci esattamente cosa stai testando e cosa non stai toccando.
2. Registra i punti di partenza: versione sistema, spazio disco, stato servizi, timestamp, backup usato.
3. Avvia la simulazione: restore, failover o stop del servizio in ambiente controllato.
4. Misura ogni fase: restore, start servizi, login, query DB, caricamento pagina, invio mail, upload file.
5. Valida il risultato: funzionalità critiche, integrità dati, log puliti, assenza di errori ripetuti.
6. Documenta gli scarti: cosa ha rallentato, cosa è fallito, cosa manca nella procedura.

Se il tuo ambiente include WordPress, CMS o e-commerce, la validazione deve includere almeno homepage, login admin, salvataggio contenuti, query al database, checkout o form di contatto, se presenti.

Come leggere i risultati

Un test DR non è superato solo perché il sito si apre. I risultati vanno interpretati con criterio.

• RTO rispettato: bene, ma verifica se è stato ottenuto in condizioni ideali o realistiche.
• RTO superato di poco: spesso il problema non è il backup, ma la procedura o il colli di bottiglia operativo.
• RPO troppo alto: il backup è troppo raro, il log shipping non funziona o la replica è troppo lenta.
• Restore riuscito ma servizio rotto: mancano configurazioni, permessi, virtual host, variabili o cache.
• Restore fallito: backup incompleto, archivi corrotti, dipendenze non compatibili, spazio insufficiente.

In pratica, il successo va definito dal risultato finale: servizio funzionante, dati coerenti, utenti serviti e tempi accettabili. Se uno di questi punti manca, il test segnala un problema reale, non un dettaglio.

Errori comuni da evitare

Molti test falliscono per motivi banali, non per un vero disastro. Ecco gli errori più frequenti:

• Backup non testato: il file esiste ma non si apre o manca il database.
• Ambiente diverso: staging troppo diverso dalla produzione e risultati falsati.
• Dipendenze dimenticate: PHP extension, Redis, cron, mail, socket, permessi.
• Nessun timestamp: senza tempi precisi non puoi misurare nulla.
• Nessun rollback: se il test tocca produzione, devi sapere come tornare indietro subito.
• DNS sottovalutato: il servizio è pronto ma il traffico non arriva ancora sul nuovo endpoint.

Un altro errore tipico è considerare il backup come prova sufficiente. In realtà il backup è solo il materiale grezzo; il DR è la capacità di usarlo nel tempo richiesto.

Esempio pratico di test su sito web

Immagina un sito WordPress con database MariaDB, file su storage locale e DNS gestito da provider esterno. Un test utile può essere questo:

1. Preparazione: crei un ambiente di staging con stesso stack PHP e database compatibile.
2. Backup: esporti file e database da produzione in un orario noto.
3. Restore: ripristini i file, importi il DB, correggi `wp-config.php` o variabili equivalenti.
4. Controlli: homepage, login, media, permalink, invio form, log errori, performance base.
5. Misura: annoti quanto tempo serve dal momento del backup al sito funzionante.

Se il test fallisce perché il sito non carica immagini o non salva contenuti, il problema non è solo “WordPress”: può essere permessi file, ownership, cache, differenze di versione PHP, rewrite rules o configurazione del web server.

Esempio pratico di test su VPS o server

Se gestisci una VPS con servizi multipli, il test deve coprire almeno sistema, web, database e monitoraggio. Una sequenza sensata è:

1. Snapshot o backup completo: sistema, configurazioni, dati applicativi e DNS se gestiti localmente.
2. Ripristino su istanza nuova: stessa distribuzione o versione compatibile.
3. Verifica servizi: SSH, web server, database, mail se presente, cron, firewall, certificati.
4. Verifica applicativa: endpoint HTTP, pagine critiche, query DB, upload, sessioni.
5. Confronto tempi: tempo teorico previsto contro tempo reale.

Questo tipo di test ti dice se il guasto più grave non è il server in sé, ma la dipendenza da configurazioni manuali che nessuno ha mai documentato.

Come migliorare il piano dopo il test

Dopo il primo test, il lavoro vero inizia qui. Ogni punto debole trovato va tradotto in una correzione concreta.

• Se il restore è lento, riduci il peso del backup, ottimizza compressione e storage, separa dati e file statici.
• Se il database è il collo di bottiglia, valuta replica, dump incrementali o snapshot più frequenti.
• Se il DNS rallenta il ritorno online, abbassa il TTL prima di eventi critici e documenta il cambio record.
• Se mancano configurazioni, crea un runbook con tutti i file e le dipendenze da ripristinare.
• Se il team sbaglia sequenza, semplifica la procedura e assegna responsabilità chiare.

Il test migliore è quello che produce una lista di miglioramenti pratici, non una relazione da archiviare. Ogni anomalia va risolta e poi ritestata.

Frequenza consigliata

La frequenza dipende dalla criticità del servizio, ma una regola utile è questa:

• Mensile: controllo rapido di backup e restore parziale.
• Trimestrale: test completo su staging con misurazione tempi.
• Semestrale: simulazione più ampia con coinvolgimento del team e documentazione aggiornata.
• Dopo ogni modifica importante: nuovo test se cambi stack, hosting, DNS, storage, pannello o strategia backup.

Se il servizio genera fatturato, lead o supporto critico, la cadenza deve essere più stretta. Il rischio non è il test in sé: è scoprire il problema solo durante un incidente reale.

Conclusione operativa

Il Disaster Recovery Testing serve a misurare la distanza tra il piano scritto e il ripristino reale. Più il test è concreto, più il risultato è utile. Simula un guasto realistico, misura ogni passaggio, valida il servizio finale e correggi subito i punti deboli. Il valore vero non è dire “abbiamo i backup”, ma poter dire “sappiamo ripartire in 27 minuti con perdita massima di 10 minuti di dati”.

Un ambiente ben progettato non elimina il disastro, ma riduce l’incertezza. E nell’operatività quotidiana, l’incertezza è spesso il problema più costoso.