Un backup corretto, da solo, non dimostra che un’applicazione possa tornare a erogare il servizio. Potrebbe mancare una chiave, una dipendenza esterna, i file associati al database o una procedura che indichi in quale ordine ripristinarli. I test di disaster recovery per applicazioni PHP consentono di verificare l’intero processo prima che una perdita o una corruzione dei dati costringa a eseguirlo sotto pressione.
L’obiettivo non è assicurare che non si verifichino mai interruzioni, ma raccogliere evidenze su ciò che è possibile recuperare, quanto tempo occorre e quali ostacoli restano da affrontare. Perché l’esercizio sia utile, occorre definirne l’ambito, isolare l’ambiente, convalidare sia l’infrastruttura sia il comportamento dell’applicazione e assegnare i responsabili dei miglioramenti necessari.
Verificare un backup non equivale a ripristinare il servizio
Un controllo del backup può confermare che un file esiste, che le sue dimensioni sembrano ragionevoli o che uno strumento è in grado di leggerlo. È un controllo utile, ma diverso dal ripristinare i componenti necessari e dimostrare che l’applicazione funziona con essi.
Il ripristino completo può includere un database, i file caricati dagli utenti, il codice e la configurazione, oltre a servizi come code di lavoro, object storage, cache o processi pianificati. Può inoltre dipendere da DNS, certificati, permessi, estensioni PHP e servizi esterni. Se uno di questi elementi manca o non è coerente con gli altri, il backup può essere valido e, tuttavia, il servizio può non essere stato ripristinato.
È opportuno definire che cosa significhi «ripristinato» per ciascuna applicazione. Può significare che il processo PHP si avvia, che gli utenti autorizzati riescono ad accedere e a completare un flusso critico, oppure che i processi in background riprendono a essere eseguiti. Una pagina iniziale visibile non è un criterio sufficiente da sola.
Definire ambito e criteri di successo prima di iniziare
Documenta lo scenario da testare: per esempio, la perdita di un database, la corruzione di file o l’indisponibilità di un intero ambiente. Non è necessario simulare tutti gli incidenti in un’unica sessione. Delimitare lo scenario consente di individuare i componenti da ripristinare e ciò che resta esplicitamente fuori dall’esercizio.
Concorda criteri verificabili con le aree business, tecnologia e operations. Tra le domande pratiche:
- Quali funzioni devono tornare disponibili e quali possono attendere?
- Fino a quale momento si accetterebbe di recuperare i dati e quale perdita di modifiche sarebbe tollerabile?
- Per quanto tempo il servizio può restare interrotto prima che l’impatto diventi inaccettabile?
- Quali dipendenze fanno parte del ripristino e quali saranno rappresentate da sostituti sicuri?
- Chi autorizza l’esecuzione, convalida il risultato e comunica i problemi?
Gli obiettivi di punto di ripristino (RPO) e di tempo di ripristino (RTO) possono essere utili per esprimere le tolleranze relative alla perdita di dati e all’interruzione del servizio. Devono essere concordati in base alle esigenze e alle capacità di ciascun servizio: non esiste un valore universale. Il test consente di confrontare i tempi e lo stato dei dati osservati con tali obiettivi, senza trasformare un singolo risultato in una garanzia futura.
Preparare un ambiente isolato e sicuro
Esegui il ripristino in un ambiente separato dalla produzione, con controlli che impediscano all’esercitazione di modificare dati reali o inviare messaggi ai clienti. Isola le reti quando possibile e blocca o sostituisci le integrazioni che potrebbero eseguire addebiti, inviare email, pubblicare eventi o modificare sistemi esterni. Informa i partecipanti che si tratta di un test.
I dati ripristinati possono contenere informazioni sensibili. Applica le relative policy di accesso, conservazione e protezione dei dati; limita chi può accedere all’ambiente e per quanto tempo. Evita di riutilizzare le credenziali di produzione. Gestisci in modo controllato i segreti di test e verifica che i file ripristinati non li espongano in log, repository o directory accessibili pubblicamente.
Registra le condizioni iniziali: data e punto del backup, versioni del codice e configurazione necessarie, risorse disponibili e differenze tra l’ambiente di test e quello di produzione. Una versione diversa di PHP, estensioni mancanti o permessi differenti possono influire sul risultato. Queste discrepanze devono essere annotate, non scambiate per un successo o un fallimento del backup.
Eseguire il ripristino di tutti i componenti necessari
Segui la procedura documentata, anche se conosci un modo più rapido. Si sta verificando proprio se le istruzioni sono sufficienti a consentire a un’altra persona di ripristinare il servizio. Annota l’ordine e la durata di ogni passaggio, i comandi manuali, le decisioni prese e ogni intervento non previsto.
Una possibile sequenza, da adattare a ogni architettura, consiste nel ripristinare l’infrastruttura e la configurazione, recuperare il database e i file, distribuire la versione compatibile del codice e collegare le dipendenze necessarie. In PHP, verifica, se pertinente, la configurazione del web server e di PHP-FPM, le estensioni richieste, le variabili d’ambiente, i permessi di scrittura e i processi pianificati. Controlla anche le code, l’object storage e i processi worker, se l’applicazione ne dipende.
Non eseguire migrazioni o processi di ricostruzione dei dati automaticamente senza conoscerne gli effetti su una copia ripristinata. Verifica che le credenziali puntino esclusivamente a servizi di test e che i processi cron non producano effetti esterni. Se il ripristino richiede un intervento manuale, registralo come parte del tempo effettivo e come possibile area di miglioramento.
Convalidare integrità e comportamento, non solo l’avvio
I controlli devono coprire dati e flussi funzionali. Inizia con verifiche tecniche: connettività al database, stato dei processi, spazio disponibile, log degli errori e risposta dei servizi interni. Poi convalida che i file e i riferimenti archiviati siano coerenti tra loro e che le relazioni o i vincoli importanti del database siano ancora consistenti.
Scegli query e flussi rappresentativi, coerenti con l’utilizzo reale dell’applicazione. Per esempio, verifica che sia possibile individuare un’entità nota, accedere con un account di test e completare un’operazione priva di effetti esterni. Se sono presenti file caricati, verifica che sia possibile recuperarli e associarli ai relativi record. Se esistono code, controlla che i job in sospeso seguano il comportamento previsto e non vengano elaborati due volte per errore.
Conserva evidenze sufficienti per ripetere la valutazione: risultati delle query, passaggi eseguiti, errori osservati e orari di inizio e fine. Non basta annotare «funziona». Definisci in anticipo quali controlli determinano il superamento dell’esercizio e quali sono bloccanti. Un’applicazione che risponde, ma mostra dati incompleti o non elabora operazioni critiche, non deve essere considerata ripristinata secondo criteri più rigorosi.
Misurare, correggere e ripetere con una cadenza utile
Misura il tempo dall’inizio concordato fino al soddisfacimento dei criteri di ripristino, non solo il tempo necessario a ripristinare un database. Se utile per l’analisi, distingui l’attesa, il lavoro automatizzato, i passaggi manuali e la convalida. Confronta il risultato con gli obiettivi concordati e individua le ipotesi non rispettate, come permessi non disponibili o documentazione non aggiornata.
Il report deve includere ambito, punto ripristinato, risultato di ogni controllo, tempi osservati, incidenti, decisioni e responsabili delle azioni correttive. Dai priorità alle misure che riducono i blocchi: automatizzare i passaggi ripetibili, aggiornare le istruzioni, correggere i permessi, rivedere le dipendenze o migliorare la strategia di backup. Assegna date per il follow-up e ripeti la parte interessata per verificare se la correzione ha risolto il problema.
La cadenza dipende dal rischio, dai cambiamenti dell’architettura e dalla capacità operativa. È possibile combinare un ripristino parziale frequente — per esempio, di un database o di file — con esercitazioni di ripristino completo e scenari diversi. È inoltre opportuno ripetere il test dopo modifiche rilevanti al sistema di backup, all’infrastruttura o alle dipendenze. Un test riuscito fornisce evidenze relative a uno scenario e a condizioni specifici: non garantisce il risultato di tutti i futuri incidenti.
