Esempio di test di disaster recovery per server
Pubblicato il 31 ottobre 2026
Un backup che non è mai stato ripristinato non è ancora un piano di ripristino. È solo un file pieno di speranze, conservato da qualche altra parte. Questo esempio di test di disaster recovery mostra come un piccolo team di hosting, un'agenzia o un proprietario di server possa testare un guasto realistico senza trasformare un'esercitazione di routine in un incidente in produzione.
L'obiettivo è semplice: dimostrare di poter ripristinare i servizi effettivamente utilizzati dagli utenti entro tempi accettabili per l'azienda. Questo significa siti web, database, record DNS, la posta se è ospitata sullo stesso server e gli accessi necessari per gestire tutto dopo il ripristino.
Cosa dovrebbe dimostrare un test di disaster recovery
Un test utile fa più che confermare il completamento di un processo di backup. Risponde a domande pratiche: riesci a trovare il backup corretto? Riesci a ripristinarlo su un server pulito? Il sito web si carica correttamente? Il database è sufficientemente aggiornato? Un membro autorizzato del team può accedere e subentrare?
È qui che entrano in gioco due obiettivi di ripristino. L'obiettivo del punto di ripristino, o RPO, definisce quanti dati puoi permetterti di perdere. Se i backup vengono eseguiti ogni notte, potresti perdere fino a un giorno di modifiche. L'obiettivo del tempo di ripristino, o RTO, definisce per quanto tempo un servizio può rimanere non disponibile. Un portfolio personale può tollerare diverse ore. Probabilmente non può farlo un negozio online che riceve ordini.
Definisci questi obiettivi prima dell'esercitazione. Altrimenti, un ripristino può sembrare riuscito semplicemente perché alla fine è andato a buon fine, anche se ha richiesto sei ore quando l'attività doveva ripartire entro una.
Esempio di test di disaster recovery: un server web guasto
Immagina un'agenzia che ospita 25 siti web di clienti su un unico server Linux. Il server dispone di backup completi giornalieri, backup dei database ogni quattro ore e uno spazio di archiviazione dei backup esterno al server di produzione. Un lunedì mattina, un guasto del disco rende il server non disponibile.
Per il test, non scollegare il server di produzione. Crea una simulazione controllata su un server di ripristino separato o su una macchina virtuale isolata. Per la prima esercitazione, scegli un sito web rappresentativo invece di tutti e 25. Scegli un sito con un database, caricamenti di contenuti multimediali, SSL, attività pianificate e un accesso reale per l'amministratore. Una semplice pagina statica è troppo facile per dimostrare granché.
Lo scenario del test può essere scritto così:
Incidente: il server di produzione è definitivamente non disponibile a causa di un guasto del disco.
Obiettivo di ripristino: ripristinare il sito web selezionato e il relativo database su un server sostitutivo entro 90 minuti, con una perdita di dati non superiore a quattro ore.
Criteri di successo: il sito web è raggiungibile tramite un hostname temporaneo o un test con il file hosts, le pagine si caricano tramite HTTPS, l'area di amministrazione consente l'accesso, sono presenti contenuti recenti, i caricamenti vengono visualizzati, i moduli funzionano correttamente, le attività pianificate vengono eseguite e i log del server non mostrano errori critici dell'applicazione.
È un test mirato, ma mette in luce gli elementi che di solito causano ritardi: credenziali mancanti, backup incompleti, supposizioni sul DNS, incompatibilità tra versioni e responsabilità poco chiare.
Prima del test, rendi chiara la procedura di ripristino
Un test di ripristino non dovrebbe dipendere dal fatto che una persona si ricordi una serie di comandi di due anni fa. Annota dove si trovano i backup, come accedervi, chi può approvare le modifiche DNS e quali servizi devono essere ripristinati per primi.
Verifica che lo spazio di archiviazione dei backup sia separato dal server di produzione. I backup archiviati solo sullo stesso disco dei siti web sono utili in caso di eliminazione accidentale di file, ma non aiutano molto in caso di perdita del server. Verifica inoltre che le credenziali di ripristino siano disponibili senza dover fare affidamento sul server guasto. Questo include l'accesso allo spazio di archiviazione dei backup, al registrar del dominio e al provider DNS, le chiavi SSH, i dettagli delle licenze e tutti i segreti necessari per le applicazioni.
Se usi un pannello server, documenta sia i passaggi da eseguire sia le impostazioni tecniche. Non è una scorciatoia. È un modo per rendere ripetibile il ripristino per la persona disponibile al momento dell'incidente. FASTPANEL può aiutare a gestire siti web, database, backup e impostazioni del server da un unico luogo facile da gestire, ma il test richiede comunque responsabilità chiare e prove documentate.
Esegui l'esercitazione seguendo un ordine sicuro
Avvia un timer quando il team riceve la notifica dell'incidente simulato. Registra l'ora, la persona che esegue ogni operazione e qualsiasi decisione che impedisca di proseguire. Queste note fanno parte dei risultati del test, non sono semplice burocrazia.
Per prima cosa, prepara l'ambiente di ripristino. Per quanto possibile, usa le stesse versioni del sistema operativo e dei runtime richiesti. Non è sempre necessario duplicare tutto esattamente, ma modificare contemporaneamente il sistema operativo, la versione di PHP, quella del database e la configurazione del server web rende più difficile risolvere i problemi. Se l'ambiente di ripristino è diverso, documenta la differenza.
Poi recupera il backup selezionato e verificane la data. Ripristina i file del sito web e il database, quindi aggiungi i valori di configurazione necessari all'applicazione per connettersi. Non dare per scontato che i file di configurazione contengano tutto. Molte applicazioni dipendono da variabili d'ambiente, chiavi API, impostazioni della posta, processi cron o autorizzazioni che si trovano al di fuori della directory del sito web.
Rendi accessibile il sito ripristinato tramite un URL temporaneo, un dominio di staging o una voce locale nel file hosts. Evita di indirizzare il DNS pubblico al server di ripristino finché non hai verificato che il sito funzioni. Controlla la homepage, diverse pagine interne, le immagini, i moduli, l'accesso agli account e l'area di amministrazione. Per un sito WordPress, controlla anche i permalink, i plugin, i caricamenti e la pubblicazione pianificata.
Poi controlla i servizi collegati al sito. Verifica che il certificato SSL possa essere installato o rinnovato, che la posta in uscita sia configurata come previsto, che le attività pianificate siano presenti e che gli utenti del database dispongano solo degli accessi necessari. Il caricamento corretto della homepage è un buon inizio, non il traguardo.
Testa anche la procedura di failover
Il ripristino tecnico è solo metà del disaster recovery. L'altra metà consiste nel decidere quando e come indirizzare il traffico verso il server sostitutivo.
Per questa esercitazione, simula una modifica DNS dopo che il sito ripristinato ha superato i controlli. Misura quanto tempo serve per preparare e comunicare la modifica, non solo quanto impiega la propagazione DNS su Internet. Valori TTL DNS più bassi possono ridurre i tempi di attesa, ma vanno pianificati prima di un'interruzione. Modificare il TTL durante l'incidente raramente aiuta nell'immediato, perché i resolver potrebbero avere già in cache il valore precedente.
Se la configurazione utilizza un bilanciatore del carico, un proxy inverso o un servizio di failover cloud, testa quel meccanismo invece di affidarti solo al DNS. L'approccio giusto dipende dalla tua architettura. Un singolo server con alcuni siti aziendali può essere ripristinato senza problemi tramite DNS. Un provider di hosting o un negozio con un volume elevato di transazioni potrebbe aver bisogno di una soluzione di failover più rapida e di un ambiente secondario già pronto all'uso.
Registra risultati utili per agire
Al termine dell'esercitazione, non limitarti a scrivere «ripristino riuscito». Registra il tempo effettivo di ripristino, l'età del backup, i controlli non superati e i passaggi manuali necessari. Confronta i valori con il tuo RTO e il tuo RPO.
Ad esempio, il team potrebbe ripristinare il sito web in 52 minuti, ma scoprire che l'ultimo backup del database risale a sei ore prima. Il ripristino del server ha rispettato l'RTO di 90 minuti, mentre quello dei dati non ha rispettato l'RPO di quattro ore. È comunque un risultato utile perché indica una soluzione specifica: aumentare la frequenza dei backup del database o aggiungere, ove opportuno, una protezione a livello di transazione.
Tra i problemi più comuni figurano la mancata conservazione dei backup, credenziali non testate, backup che escludono i file caricati, versioni software incompatibili e accesso al DNS legato all'account di un solo dipendente. Risolvi prima il problema più rischioso, assegna un responsabile e fissa una scadenza. Un test senza azioni successive è solo una prova generale dello stesso problema.
Con quale frequenza dovresti eseguire i test?
Per la maggior parte delle piccole imprese, un test di ripristino trimestrale è un punto di partenza pratico. Esegui test più frequenti dopo cambiamenti importanti, come una migrazione del server, un nuovo provider di backup, un aggiornamento del database, una riprogettazione dell'applicazione o un cambiamento dei responsabili dell'infrastruttura.
Alterna l'ambito dei test. Un trimestre, ripristina un singolo sito web critico e il relativo database. Il trimestre successivo, testa la ricostruzione completa di un server. In seguito, testa un problema di accesso all'account o uno scenario di eliminazione accidentale. Guasti diversi rivelano punti deboli diversi e non serve creare il massimo caos ogni volta per imparare qualcosa di utile.
Il miglior piano di disaster recovery è quello che il tuo team può eseguire con calma, utilizzando le informazioni che ha già a disposizione. Pianifica il prossimo test prima che questo svanisca dalla memoria, poi rendi la procedura di ripristino un po' più breve e chiara ogni volta.