Piano di Disaster Recovery per applicazioni PHP: guida pratica per la continuità operativa della tua PMI

La maggior parte delle PMI che gestiscono un'applicazione PHP in produzione confonde due cose molto diverse: avere un backup e avere un piano di disaster recovery. Sono confini distinti. Un backup è un artefatto, un file da qualche parte. Un piano di disaster recovery è una procedura organizzativa e tecnica documentata, che stabilisce in anticipo quanto downtime puoi tollerare, quanti dati puoi permetterti di perdere, chi fa cosa quando il sistema cade, in quale ordine si ripristina e come si verifica che il ripristino sia davvero riuscito. Il backup è un ingrediente del piano, non il piano.

Qualche tempo fa ho seguito il caso di un e-commerce su VPS unmanaged, gestito da un'azienda del settore retail, il cui disco NVMe ha sviluppato settori irrecuperabili nel cuore della notte. Al risveglio, gli operatori trovavano errori di I/O su ogni richiesta, il database non si avviava per corruzione delle tablespace e il pannello del provider non offriva recovery automatico. Esisteva un backup: un dump giornaliero salvato sullo stesso disco guasto, quindi perso insieme al resto. Esisteva uno snapshot manuale fatto settimane prima dal titolare. Non esisteva un piano: nessuno sapeva quanto sarebbe durato il ripristino, in quale ordine procedere, chi avvisare. Il ritorno all'operatività ha richiesto più di mezza giornata, ricostruendo a mano i dati delle ultime settimane da log applicativi ed email di conferma ordine. Il titolare stimava un downtime di "qualche minuto"; la realtà è stata di un ordine di grandezza superiore.

Quella distanza tra il downtime immaginato e quello reale è esattamente il vuoto che un piano di disaster recovery colma. In questo articolo ti mostro come si costruisce per un'applicazione PHP su VPS: non l'ennesima guida al backup, ma il disaster recovery plan e il business continuity plan veri, con i loro componenti, i numeri da definire prima dell'incidente e le procedure da provare quando tutto funziona ancora.

Stai cercando un Consulente Informatico esperto per costruire un piano di disaster recovery e continuità operativa per la tua infrastruttura? Nel mio profilo professionale trovi l'esperienza concreta su backup testati, failover e business continuity per PMI su VPS unmanaged.

Qual è la differenza tra un backup e un piano di disaster recovery?

Un backup è una copia dei dati; un piano di disaster recovery è la procedura che, partendo da quella copia, riporta l'intero servizio all'operatività entro un tempo definito e con una perdita di dati definita. La differenza pratica è che un backup risponde alla domanda "ho i dati?", mentre il piano risponde a "in quanto tempo torno operativo, con quali dati, chi lo fa e come verifico che funzioni davvero?".

È una distinzione che sembra accademica finché non arriva l'incidente, e poi diventa la differenza tra mezz'ora e mezza giornata di fermo. Il backup è uno dei quattro pilastri del piano, ma da solo è inerte: senza un runbook che dica come ricostruire l'ambiente, senza un test che dimostri che il restore funziona, senza ruoli definiti e senza una procedura di failover, quel file è soltanto una speranza. La regola che applico è semplice e brutale: un backup non testato non esiste. Finché non hai ripristinato quel backup su un server pulito e verificato che l'applicazione gira, devi assumere che non funzioni.

Per la parte puramente di backup, immutabilità offsite e deduplica, ho già scritto una guida dedicata sulle strategie di backup avanzate per VPS unmanaged: qui do per acquisita la copia dei dati e mi concentro sul livello superiore, il piano che la trasforma in continuità operativa.

Come definisco RTO e RPO per una PMI (e perché sono decisioni di business)

L'RTO (Recovery Time Objective) è il tempo massimo accettabile tra l'inizio dell'incidente e il ritorno all'operatività. L'RPO (Recovery Point Objective) è la quantità massima di dati che puoi permetterti di perdere, misurata in tempo: un RPO di un'ora significa che, nel peggiore dei casi, accetti di perdere l'ultima ora di dati. Sono i due numeri attorno a cui ruota tutto il piano, e contrariamente a quanto si pensa non sono decisioni tecniche: sono decisioni di business che il tecnico traduce in architettura.

La domanda che faccio sempre al titolare è duplice: quanto ti costa un'ora di fermo, e quanto ti costa perdere i dati dell'ultima ora? Le risposte determinano il budget del disaster recovery, perché ridurre RTO e RPO costa denaro in modo non lineare. Da queste due cifre derivo i target. Sono livelli di servizio interni, SLA verso il business prima ancora che verso un fornitore:

• E-commerce con transazioni continue: RTO 1-2 ore, RPO 1 ora. Ogni ora di downtime è fatturato perso, non recuperabile.
• Gestionale interno usato in orario d'ufficio: RTO 4 ore, RPO 4 ore. Il costo del fermo è produttività persa, raramente fuori dall'orario di lavoro.
• Sito vetrina o blog: RTO 24 ore, RPO 24 ore. Il danno è reputazionale, non operativo.

RTO e RPO non li sceglie il tecnico in autonomia: li propone dopo aver quantificato il costo del downtime, e il titolare li approva accettandone il prezzo. Un piano scritto senza questa conversazione è un piano che nessuno ha mai voluto pagare, e che alla prova dei fatti non regge.

Un e-commerce che fattura 2.000 euro l'ora può giustificare un'infrastruttura di standby da un centinaio di euro al mese; un gestionale interno no. Il mestiere del consulente, qui, è dire al cliente la verità sui costi prima dell'incidente, non dopo.

L'analisi di rischio e di impatto: cosa può rompersi e quanto fa male

Prima dei componenti tecnici viene un passaggio che quasi nessuna PMI fa: la business impact analysis, cioè l'inventario di cosa può andare storto e di quanto costa ciascun scenario. Senza questa mappa, il piano di disaster recovery rischia di blindare lo scenario sbagliato e lasciare scoperto quello probabile.

Per un'applicazione PHP su un singolo VPS, gli scenari realistici che metto in conto sono pochi e ricorrenti:

• Guasto hardware del VPS (disco, RAM, host del provider): il più comune sui server unmanaged, ed è quello che mette in crisi chi ha il backup sullo stesso disco.
• Corruzione dei dati applicativi: una migration sbagliata, un DELETE senza WHERE, un deploy andato male. Qui il backup orario non basta se non hai point-in-time recovery, perché il dato corrotto viene fedelmente replicato anche nel warm standby.
• Compromissione di sicurezza: ransomware o defacement che cifra o cancella i dati, inclusi i backup raggiungibili dal server. È lo scenario che rende non negoziabile l'immutabilità del backup offsite.
• Errore umano sistemistico: il rm -rf sulla directory sbagliata, la rotazione di credenziali che blocca l'accesso, il certificato scaduto.
• Perdita dell'accesso al provider o al fornitore IT: account intestato a un freelance sparito, fattura non pagata che sospende il VPS, datacenter irraggiungibile.

Ogni scenario ha una probabilità e un impatto diversi, e il piano deve coprirli con priorità coerente. La corruzione logica dei dati, per esempio, è subdola proprio perché il failover automatico la propaga: per questo nel piano la mitigazione non è "ho un secondo server", ma "ho una catena di backup con retention che mi permette di tornare a prima dell'errore". È la differenza tra resilienza all'hardware e resilienza al dato, due cose che vanno progettate separatamente.

I quattro componenti del piano di disaster recovery

Un piano operativo per applicazione PHP su VPS poggia su quattro pilastri non negoziabili. I primi due definiscono come si ripristina, il terzo dimostra che il ripristino funziona, il quarto serve solo quando l'RTO è così stretto da non concedere il tempo di un restore completo.

Backup offsite e immutabile: il presupposto, non il piano

Il backup è il presupposto di tutto, e lo do per acquisito perché l'ho trattato altrove, ma un punto va ribadito qui perché è il primo a saltare nelle PMI: il backup deve stare fuori dal server di produzione e deve essere non cancellabile dal server stesso. Un dump sullo stesso disco non è un backup, è un'illusione che svanisce con il disco. La regola di riferimento è la classica 3-2-1 descritta dalla US-CERT/CISA: tre copie dei dati, su due tipi di supporto diversi, di cui una offsite.

In pratica uso uno strumento con deduplica e modalità append-only, tipicamente BorgBackup verso uno storage offsite separato. La modalità append-only è ciò che rende il backup resistente a un attacco: come documenta il manuale ufficiale di Borg, con --append-only lato server il repository "consente solo l'aggiunta ai segment file", così un client compromesso non può troncare lo storico delle copie. Lo schedulo con un backup orario per gli RPO bassi e uno giornaliero completo, con retention scalare:

# Cron: backup orario dei dati critici (RPO basso)
0 * * * * /usr/bin/flock -n /tmp/borg-hourly.lock /root/scripts/borg-backup.sh hourly

# Cron: backup giornaliero completo
0 2 * * * /usr/bin/flock -n /tmp/borg-daily.lock /root/scripts/borg-backup.sh daily

Retention tipica: 24 orari, 7 giornalieri, 4 settimanali, 6 mensili. Con la deduplica lo spazio occupato è una frazione della somma nominale. Questo è il pavimento del piano: tutto il resto ci si appoggia sopra.

Il runbook di ripristino: il piano che si legge a server spento

Qui inizia il disaster recovery vero. Un backup senza una procedura di ripristino documentata e testata è una scommessa che fai sotto stress, alle tre di notte, con il titolare al telefono. Il runbook elimina l'improvvisazione: è il documento che chiunque, anche un sistemista subentrante, deve poter eseguire passo passo. Il mio contiene sempre quattro blocchi:

1. Provisioning del nuovo server: taglio del VPS, sistema operativo, stack software (Nginx, PHP-FPM, database, Redis), con i comandi esatti di installazione e le versioni pinnate. Niente "installa l'ultima versione": l'ultima versione di domani potrebbe non essere compatibile con la codebase.
2. Ripristino dei dati: comandi di estrazione dal repository di backup, import del database, ripristino dei file applicativi e dei secret. L'ordine conta: prima i dati, poi la configurazione, poi il traffico.
3. Riassegnazione del traffico: aggiornamento del record DNS verso il nuovo IP, con nota esplicita sul TTL e sul tempo di propagazione atteso.
4. Verifiche post-ripristino: check degli endpoint critici, integrità referenziale del database, smoke test funzionale dei flussi che generano fatturato (per un e-commerce: login, carrello, checkout, conferma ordine).

Il dettaglio che fa la differenza è banale e quasi sempre dimenticato: il runbook deve essere accessibile a server spento. Se la procedura sta solo sul server che è giù, non hai una procedura. Lo conservo in almeno tre luoghi indipendenti, come PDF nel repository Git, nel password manager del cliente e in copia cartacea in ufficio. Lo stesso vale per i secret di ripristino e le credenziali del provider: se l'unico posto in cui vivono è il server caduto, il runbook è inutilizzabile proprio nel momento in cui serve.

Il test del runbook non è "ho letto il documento e mi sembra giusto". È "ho dato il documento a una persona diversa da chi l'ha scritto, le ho detto di seguirlo alla lettera senza chiedermi nulla, e l'applicazione è tornata su". Tutto il resto è autoinganno.

Il test di ripristino periodico: ciò che separa il piano dalla speranza

Il componente che distingue un piano serio da un documento da cassetto è il test di ripristino programmato. Un backup mai ripristinato e un runbook mai eseguito hanno lo stesso valore di nessuno dei due. Il test trimestrale che eseguo per ogni cliente è una prova in bianco dell'incidente:

1. Provisioning di un VPS temporaneo isolato (un taglio entry di un qualunque provider, costo nell'ordine dei centesimi per le ore di test).
2. Ripristino completo dal backup: filesystem e database, seguendo il runbook senza scorciatoie.
3. Avvio dei servizi e smoke test funzionale dei flussi critici.
4. Misura dell'RTO reale, cronometrando dal provisioning all'applicazione pienamente operativa.
5. Documentazione: data, RTO misurato, eventuali intoppi e correzioni da riportare nel runbook.

Il valore del test è duplice. Primo, verifica il numero: l'RTO che hai scritto nel piano è un'ipotesi finché un cronometro non lo conferma, e quasi sempre la prima misura è peggiore della stima. Secondo, e più importante, scopre i bug del piano quando non costano nulla: un pacchetto che non esiste più nel repository, un secret non incluso nel backup, un passaggio del runbook ambiguo. Meglio scoprirli durante un test su un VPS usa-e-getta che durante l'incidente vero, con il fatturato che si ferma. Sul caso retail di cui sopra, il primo test post-implementazione ha misurato un RTO di poche decine di minuti, contro le ore dell'incidente reale: quella distanza è esattamente ciò che un piano testato compra.

Il warm standby: per gli RTO che un restore non riesce a rispettare

Quando l'RTO concordato scende sotto la mezz'ora, tipicamente per e-commerce con fatturato significativo, il restore da backup non basta: anche un runbook rodato richiede più tempo di quanto il business può tollerare. Qui serve un warm standby, un secondo VPS già provisionato con lo stack completo, che riceve i backup e una replica del database in near-realtime. In caso di incidente, il failover è una procedura breve e prevedibile:

1. Fermare la replica sul warm standby e promuoverlo a nodo primario.
2. Aggiornare il record DNS verso il suo IP (con TTL basso, la propagazione è di pochi minuti).
3. Verificare che il servizio risponda e i flussi critici funzionino.

Con uno standby preconfigurato e TTL DNS basso, il failover reale scende sotto i dieci minuti. Il costo è quello del secondo VPS, tipicamente qualche decina di euro al mese: trascurabile rispetto a un'ora di fermo per chi fattura online. Attenzione però alla trappola che ho citato nell'analisi di rischio: il warm standby protegge dal guasto hardware, non dalla corruzione logica del dato, perché la replica propaga fedelmente anche un DELETE sbagliato. Per quello serve sempre la catena di backup con retention, che ti permette di tornare a un punto precedente all'errore. Sono due difese complementari, non alternative.

Chi fa cosa: ruoli, comunicazione e il lato umano del piano

Un piano di disaster recovery tecnicamente perfetto fallisce se nessuno sa chi deve eseguirlo. La business continuity non è solo infrastruttura: è la catena di decisioni e comunicazioni che si attiva quando il sistema cade. Per una PMI non servono organigrammi da multinazionale, ma tre cose vanno scritte nel piano in anticipo:

• Chi dichiara l'incidente e chi attiva la procedura. Deve essere chiaro chi ha l'autorità di dire "siamo in disaster recovery, eseguo il runbook", per evitare la mezz'ora persa a capire se è davvero il caso o no.
• La catena di escalation. Chi è il primo contatto tecnico, chi il backup se è irraggiungibile, chi avvisa il titolare. Un piano con un solo nome è un piano che fallisce quando quella persona è in ferie.
• La comunicazione esterna. Cosa si dice ai clienti durante il fermo, su quale canale (una pagina di stato statica ospitata altrove vale molto più di un sito che restituisce 500), e chi la gestisce. Il silenzio durante un'interruzione fa più danno reputazionale del fermo stesso.

Questo livello organizzativo è ciò che trasforma il disaster recovery (rimettere su il sistema) in business continuity (tenere in piedi l'azienda mentre lo rimetti su). La gran parte delle PMI con cui lavoro arriva con zero documentazione su questo fronte: spesso è il primo deliverable che produciamo, prima ancora di toccare lo stack.

Se stai impostando il piano da zero o vuoi che riveda quello che hai, contattami per una consulenza diretta: di solito tra la prima chiamata e un piano testato passano giorni, non mesi, e il test di ripristino te lo lascio documentato perché tu possa rieseguirlo in autonomia.

Quanto costa un piano di disaster recovery, e quanto costa non averlo

Il malinteso più diffuso è che la continuità operativa sia un lusso da grande impresa. Per un'applicazione PHP su VPS i numeri raccontano il contrario. Un backup offsite immutabile con deduplica costa pochi euro al mese di storage; il warm standby aggiunge il costo di un secondo VPS, qualche decina di euro mensili; il test trimestrale richiede un paio d'ore di lavoro tecnico. Anche con il setup completo, il costo annuo di un piano serio resta nell'ordine di poche centinaia di euro, spesso inferiore a un'ora del fatturato che protegge.

Dall'altra parte della bilancia c'è il costo del non averlo, ed è quantificabile esattamente come l'RTO e l'RPO che hai scelto di non definire. È il fatturato perso durante un fermo che dura un ordine di grandezza più del previsto, il lavoro di ricostruzione manuale dei dati mancanti, le penali per le consegne saltate, il danno reputazionale del silenzio. Nel caso retail da cui sono partito, la somma di queste voci ha superato di decine di volte il costo annuo del piano che è stato installato dopo. Il disaster recovery, come la sicurezza, non è un costo ma un'assicurazione di cui conosci il premio e la copertura prima di sottoscriverla.

C'è un ultimo tassello che lega questo articolo al resto del lavoro su VPS unmanaged. Il piano di disaster recovery presidia il caso in cui il server è perso e va ricostruito; ma molti incidenti non distruggono il server, lo lasciano in piedi e danneggiato. Per quegli scenari la risposta è chirurgica, non un restore completo: ne ho scritto nella guida al ripristino di file system corrotti su VPS Debian e Ubuntu, che copre fsck, recupero di tablespace e diagnosi a freddo. E quando l'evento non è un guasto ma un cambio pianificato di infrastruttura, lo stesso impianto di runbook, test e cutover DNS si riusa per una migrazione di VPS a zero downtime: le procedure di failover di un piano DR ben fatto sono le stesse che usi per spostare il servizio senza che il cliente se ne accorga.

Per quale infrastruttura conviene un piano di disaster recovery?

Per qualunque applicazione PHP il cui fermo costa più di quanto costa il piano, cioè quasi tutte quelle che generano fatturato o supportano operazioni quotidiane. La domanda corretta non è "se" costruire il piano, ma a quale RTO e RPO, perché è quello a determinarne il prezzo.

Sul fronte infrastruttura, la scelta del provider entra nel piano perché lo standby e il backup offsite vivono lì. Per un'infrastruttura cloud europea self-managed con buon rapporto prezzo/prestazioni e conformità GDPR, Hetzner resta un riferimento solido per il primario, lo standby e lo storage offsite separato (datacenter in Germania e Finlandia, ISO/IEC 27001). Per le PMI italiane che preferiscono delegare la gestione sistemistica e tenere il dato in Italia, la prima scelta è RHX, provider con datacenter a Milano e Padova e gestione inclusa: in quel caso il piano di disaster recovery si costruisce con il fornitore che amministra i nodi, anziché in autonomia.

In oltre vent'anni di lavoro su infrastrutture PHP per PMI, il pattern che ho visto ripetersi è sempre lo stesso: il titolare crede di avere un piano e ha solo un backup non testato, finché un incidente non gli mostra la differenza nel modo più caro possibile. Costruire il disaster recovery plan prima è un lavoro di poche giornate e poche centinaia di euro l'anno; scoprire di non averlo durante l'incidente costa il fatturato, i dati e talvolta i clienti. Se la tua applicazione è in produzione e l'unica cosa che chiami "piano" è un file di backup che non hai mai provato a ripristinare, il rischio che stai correndo è preciso, misurabile e prevenibile: il primo passo è definire i tuoi RTO e RPO, e da lì il piano si scrive quasi da solo.