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

Il 7 marzo 2025, alle 3:42 di notte, il disco NVMe di un VPS Contabo da 8 vCPU su cui girava un e-commerce Laravel di un cliente trentino ha sviluppato settori irrecuperabili. Al risveglio degli operatori alle 8:00, il sito restituiva errori I/O su ogni richiesta, MySQL non si avviava per corruzione delle tablespace InnoDB, e il pannello Contabo non mostrava opzioni di recovery automatico. Il backup esistente era un mysqldump giornaliero salvato sullo stesso disco - inutile. Il secondo "backup" era uno snapshot del VPS fatto manualmente dal titolare tre settimane prima - con tre settimane di ordini, fatture e modifiche ai listini mancanti.

Il ripristino ha richiesto 14 ore: provisioning di un nuovo VPS, reinstallazione dello stack, ricostruzione manuale del database da log applicativi e email di conferma ordine, e test di ogni funzionalità. Il costo - tra mancato fatturato (il sito era il canale di vendita principale), lavoro di ricostruzione e penali per consegne ritardate - ha superato i 18.000 euro. L'RTO (Recovery Time Objective) che il titolare pensava di avere era "qualche minuto"; quello reale è stato 14 ore. L'RPO (Recovery Point Objective) che pensava di avere era "un giorno"; quello reale è stato tre settimane.

Dopo quell'incidente ho costruito il piano di disaster recovery che oggi installo su ogni VPS con applicazioni PHP in produzione. In questo articolo ti racconto i componenti del piano e come dimensionare RTO e RPO per il tuo caso specifico.

Stai cercando un Consulente Informatico esperto per costruire un piano di disaster recovery per la tua infrastruttura? Nel mio profilo professionale trovi l'esperienza concreta su backup, failover e continuità operativa per PMI. Contattami per una consulenza diretta.

Cosa significano RTO e RPO e come li dimensiono per una PMI?

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 - se il tuo RPO è 1 ora, significa che accetti di perdere al massimo l'ultima ora di dati.

Per una PMI con applicazione PHP su VPS, i target realistici sono:

• E-commerce con transazioni continue: RTO 1-2 ore, RPO 1 ora. Ogni ora di downtime costa fatturato diretto.
• Gestionale interno usato in orario d'ufficio: RTO 4 ore, RPO 4 ore. Il costo del downtime è produttività persa, non fatturato diretto.
• Sito vetrina/blog: RTO 24 ore, RPO 24 ore. Il costo del downtime è reputazionale, non operativo.

La regola è: quanto costa un'ora di downtime? Quanto costano i dati dell'ultima ora? Le risposte a queste domande determinano il budget del disaster recovery. Un e-commerce che fattura 2.000 euro l'ora può giustificare un'infrastruttura di failover da 100 euro al mese. Un gestionale interno no.

Il piano: quattro componenti non negoziabili

Componente 1: backup offsite con BorgBackup

Il backup è il fondamento del disaster recovery, come ribadisce la regola 3-2-1-1-0 documentata da Barracuda Networks: tre copie, due supporti, una offsite, una immutabile, zero errori verificati. Ma un backup sullo stesso disco del server non è un backup - è un'illusione, come ha dimostrato il caso trentino. Il backup deve essere offsite (su un'infrastruttura diversa) e immutabile (non cancellabile dal server di produzione). Ho descritto la configurazione completa di BorgBackup con append-only repo su Hetzner Storage Box in un articolo dedicato - è la soluzione che uso come standard per ogni VPS che gestisco.

La configurazione minima per un RPO di 1 ora:

# Cron: backup orario dei dati critici
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

La retention: 24 backup orari (ultime 24 ore con granularità oraria), 7 giornalieri, 4 settimanali, 6 mensili. Con la deduplicazione di BorgBackup, lo spazio occupato è una frazione della somma dei backup.

Componente 2: il runbook di ripristino documentato

Un backup senza una procedura di ripristino documentata e testata è una scommessa. Il runbook che scrivo per ogni progetto contiene:

1. Provisioning del nuovo server: tipo di VPS, sistema operativo, stack software (Nginx, PHP-FPM, MySQL, Redis), con comandi esatti per l'installazione
2. Ripristino dei dati: comandi BorgBackup per l'estrazione, import del database, ripristino dei file applicativi
3. Configurazione DNS: istruzioni per aggiornare il record A al nuovo IP, con nota sul TTL
4. Verifiche post-ripristino: test degli endpoint critici, verifica integrità database, test funzionale dell'applicazione

Il runbook deve essere accessibile offline - se il server è giù, non puoi leggere il runbook che sta sul server. Lo salvo come PDF nel repository Git, nel password manager del cliente, e in copia cartacea nell'ufficio del titolare.

Componente 3: il test di ripristino trimestrale

Un backup non testato è una speranza, non un piano. Il test trimestrale che eseguo per ogni cliente:

1. Provisioning di un VPS temporaneo (Hetzner CX21, costo: pochi centesimi per le ore di test)
2. Ripristino completo da BorgBackup: filesystem + database
3. Avvio dei servizi e verifica funzionale
4. Misura dell'RTO reale (dal provisioning all'applicazione funzionante)
5. Documentazione: data, RTO misurato, eventuali problemi riscontrati

Sul cliente trentino, il primo test post-implementazione ha misurato un RTO di 47 minuti - dal provisioning del VPS alla verifica di tutte le funzionalità critiche dell'e-commerce. Quel numero - 47 minuti contro le 14 ore dell'incidente reale - è la differenza che un piano di disaster recovery fa.

Componente 4: il warm standby per RTO sotto i 15 minuti

Per clienti con RTO sotto i 30 minuti - tipicamente e-commerce con fatturato significativo - il backup non basta: servono dati di restore a portata di mano e bisogna poter attivare il servizio dal warm standby, su un secondo VPS già configurato con lo stack completo. Il secondo VPS riceve i backup BorgBackup e la replica MySQL in near-realtime. In caso di incidente, il failover è:

1. Fermare la replica MySQL sul warm standby e promuoverlo a primary
2. Aggiornare il record DNS (se il TTL è a 300 secondi, propagazione in 5 minuti)
3. Verificare che il sito risponda

Con un warm standby pre-configurato e TTL DNS basso, il failover reale è sotto i 10 minuti. Il costo del warm standby è il costo del secondo VPS - tipicamente 10-30 euro al mese, un investimento trascurabile rispetto al costo di un'ora di downtime.

Per nuovi clienti Hetzner, puoi ottenere €20.00 di credito gratuito utilizzando questo link con codice sconto - una scelta ideale per i VPS di warm standby grazie ai data center tedeschi conformi GDPR.

Cosa ho imparato sui disaster recovery nelle PMI

Il pattern è sempre lo stesso: il titolare pensa di avere un piano di disaster recovery, ma in realtà ha solo un backup non testato sullo stesso disco del server. Quando l'incidente arriva - e arriva sempre - scopre che l'RTO reale è ordini di grandezza peggiore di quello che immaginava. La checklist di emergenza per VPS Debian e Ubuntu copre la risposta immediata all'incidente, ma il piano di disaster recovery è ciò che determina se il ripristino richiede minuti o settimane.

Un piano di disaster recovery serio per un'applicazione PHP su VPS costa meno di quanto pensi: BorgBackup + Storage Box offsite = circa 5 euro al mese. Il warm standby aggiunge 15-30 euro al mese. Il test trimestrale richiede 2-3 ore di lavoro. Il costo totale annuo è nell'ordine di 300-600 euro - meno del fatturato di un'ora di molti e-commerce, e incomparabilmente meno dei 18.000 euro che il cliente trentino ha perso in un singolo incidente.

Se la tua applicazione PHP è in produzione senza un piano di disaster recovery testato - o se il tuo "piano" è un backup sullo stesso disco che non hai mai provato a ripristinare - il rischio che stai correndo è quantificabile e prevenibile. Contattami e costruiamo insieme il piano che protegge il tuo business.