Backup e Disaster Recovery per Siti PHP: Una Guida Pratica

Ogni sito PHP si basa su una pila di componenti in movimento: un server web, un runtime PHP, un database MySQL o PostgreSQL, file di configurazione, asset caricati e spesso decine di piccoli cron job. Ognuno di questi elementi può fallire — una tabella corrotta, un rm -rf fuori controllo, un ransomware — e se hai solo un backup del database della settimana scorsa, sei nei guai. In DigiForge abbiamo recuperato più siti PHP di quanti ne vogliamo ricordare, e la differenza tra un ripristino di quattro ore e un incubo di quattro giorni si riduce sempre a una cosa: una strategia di backup e disaster recovery ben progettata.

Perché il Backup da Solo Non Basta

Molti team confondono il backup con il disaster recovery. Un backup è una copia periodica dei dati. Il disaster recovery è l'intero processo di riportare online l'applicazione — ripristinare i dati, riconfigurare i servizi, reindirizzare il traffico e verificare che tutto funzioni. Come afferma un report sulla resilienza IT, "proteggere i propri dati con i backup non è più sufficiente per sopravvivere" (fonte). Un backup senza un piano di ripristino testato è solo un'assicurazione che non hai ancora letto.

Nel contesto PHP, la differenza è netta. Il backup del database potrebbe essere perfettamente integro, ma se non sai come puntare Apache o Nginx al database ripristinato, modificare le credenziali nel .env o ricostruire la cache opcache di PHP, rimani comunque offline. E il downtime, come ben sappiamo, costa denaro e fiducia. Un piano completo di disaster recovery (DR) deve coprire ogni livello del tuo stack server, non solo i dati.

Lo Stack di Backup e Ripristino per Siti PHP

Suddividiamo il backup di un'applicazione PHP in cinque livelli distinti. La mancanza di uno solo può rendere inutili gli altri:

1. Codice e controllo versione (repository Git, inclusi tag e branch).
2. Dump del database (MySQL, PostgreSQL o MariaDB).
3. Configurazione del server web (virtual host Nginx/Apache, certificati SSL, pool PHP-FPM).
4. Configurazione dell'applicazione (.env, file di configurazione, credenziali hard-coded).
5. Contenuti caricati dagli utenti (immagini, PDF, qualsiasi file archiviato al di fuori del database).

Esaminiamo ogni livello con raccomandazioni pratiche.

1. Codice e Controllo Versione

Il codice della tua applicazione dovrebbe risiedere in un repository Git, senza eccezioni. Ma un push Git non è un backup. Abbiamo visto team affidarsi a un singolo branch remoto e perdere settimane di lavoro quando un force push o un repository corrotto colpisce. Utilizza un provider di hosting Git (GitHub, GitLab, Bitbucket) e configura mirror automatici verso una seconda posizione. Per i deployment in produzione, tagga ogni release. In questo modo, se devi tornare a uno stato noto e funzionante, non devi indovinare quale commit era in produzione.

2. Backup del Database

I backup del database sono i più critici e i più trascurati. Un mysqldump giornaliero in una directory locale è meglio di niente, ma abbiamo visto quelli riempire un disco e smettere di funzionare silenziosamente. Automatizza i tuoi dump con uno script che ruota i vecchi backup, li comprime e li spedisce fuori sede — su S3, Backblaze o un server separato. Usa mysqldump --single-transaction per le tabelle InnoDB per evitare blocchi in lettura e testa periodicamente il ripristino. Un backup che non può essere ripristinato è inutile.

3. Configurazione del Server e del Web Server

Il tuo sito PHP funziona su più di codice e dati. I file di configurazione di Nginx o Apache, le impostazioni del pool PHP-FPM, i certificati SSL e le definizioni dei cron job sono tutti unici per il tuo server. Conservali in un repository Git separato (o come parte del repository dell'applicazione sotto una directory deploy/) e esegui il backup insieme al resto. Servizi come Certbot rinnovano automaticamente i certificati Let's Encrypt, ma se il tuo server muore, quei certificati sono persi. Esegui il backup di /etc/letsencrypt/ o passa alla convalida basata su DNS che sopravvive a una ricostruzione.

4. Configurazione dell'Ambiente e dell'Applicazione

Le applicazioni PHP spesso hanno un file .env con credenziali del database, chiavi API e segreti. Questi non devono mai finire nel version control. Per la produzione utilizziamo un gestore di segreti (come HashiCorp Vault o envkey), ma come minimo crittografa e conserva una copia del file .env nel tuo sistema di backup. Se perdi questo file, non stai ripristinando il sito — lo stai ricostruendo.

5. Upload di utenti e media

Immagini, PDF e altri upload sono spesso salvati in una directory public/uploads. Crescono rapidamente e possono appesantire i backup del database se memorizzati come BLOB. Buona pratica: tieni gli upload su un volume separato o su un object store (S3, DigitalOcean Spaces). Se sono sul filesystem del server, includi quella directory nel backup offsite. Usa rsync o rclone per sincronizzare con lo storage cloud ogni giorno.

Automatizzare e testare il piano di ripristino

Una strategia di backup vale quanto il suo ripristino. Abbiamo partecipato a troppe riunioni post-mortem in cui il cliente diceva: “Abbiamo i backup”, ma non aveva mai provato a usarli. Il disaster recovery è un processo, non un prodotto. Devi scrivere — e, cosa più importante, provare — come riporterai in vita il tuo sito PHP.

• Scrivi un runbook. Documenta ogni passaggio: dove sono conservati i backup, come ripristinare il database, quali comandi ricostruiscono il server web, come aggiornare il DNS se il tuo IP cambia.
• Automatizza i ripristini. Usa script o strumenti di orchestrazione (Ansible, Puppet o anche un semplice script Bash) per provisioningare un nuovo server e ripristinare l'applicazione dai backup. Se non riesci a creare un clone in meno di un'ora, il tuo piano di DR è troppo lento.
• Testa trimestralmente. Ripristina l'intero stack PHP su un server nuovo (un nuovo VPS o una VM locale) e verifica che il sito funzioni. Testa la propagazione DNS, SSL, le connessioni al database, i cron job e ogni flusso utente. Risolvi tutto ciò che si rompe.

Nella nostra esperienza, i fallimenti più comuni durante un drill di ripristino sono discrepanze nelle credenziali (password del database hardcoded che non corrispondono al .env ripristinato), estensioni PHP mancanti e upload incompleti. Ogni fallimento è un dono — rivela una lacuna che puoi correggere prima di un vero disastro.

“Un backup senza un piano di ripristino testato è solo una speranza.” — Principio ingegneristico di DigiForge

Scelta delle posizioni e dei formati di archiviazione

La vecchia regola 3-2-1 è ancora valida: tre copie dei tuoi dati, su due supporti diversi, con una copia fuori sede. Per i siti PHP, una configurazione comune è: (1) lo script di backup locale del server live, (2) un bucket cloud fuori sede e (3) un archivio a freddo (es. Glacier) per snapshot mensili. Crittografa i backup con GPG o crittografia lato client prima di caricarli su terze parti.

I backup incrementali risparmiano larghezza di banda e spazio di archiviazione, ma aumentano la complessità del ripristino. Per un sito PHP a medio traffico, un dump completo giornaliero del database più i log binari orari (se necessario) rappresenta un buon equilibrio. I backup del filesystem possono essere incrementali tramite rsync — assicurati solo che i tuoi strumenti possano ricostruire uno stato consistente dagli incrementali.

Quando il disastro colpisce: il runbook di ripristino

Simuliamo il caso peggiore: un attacco ransomware crittografa la root web PHP e il database. Ecco il flusso di ripristino di alto livello che utilizziamo in DigiForge:

1. Isolare il server infetto — bloccare tutti gli accessi esterni, fare uno snapshot per eventuali analisi forensi.
2. Provisionare un server pulito — un VPS nuovo con lo stesso sistema operativo e versione PHP.
3. Ripristinare il codice da Git — clonare la release taggata che era in esecuzione prima dell'attacco.
4. Ripristinare la configurazione — copiare .env, le configurazioni del web server, i certificati SSL (o riemetterli).
5. Ripristinare il database — importare l'ultimo dump pulito, quindi riprodurre i binlog fino al punto dell'infezione (se disponibili).
6. Ripristinare gli upload — rsync dallo storage di backup alla directory upload del nuovo server.
7. Testare tutto — eseguire controlli di integrità, verificare le connessioni al database, assicurarsi che i cron job vengano eseguiti.
8. Cambiare il DNS — puntare il dominio al nuovo IP del server (abbassare il TTL in anticipo).
9. Monitorare — osservare i log e l'uptime per 24 ore. Dichiarare il ripristino solo dopo un periodo verde sostenuto.

L'intero processo può richiedere 2–4 ore se i backup sono ben organizzati e hai fatto pratica. Senza pratica, può estendersi a giorni.

Costruire una cultura del ripristino

Il disaster recovery non è un progetto una tantum, ma una pratica continua. Ogni volta che aggiorni la versione di PHP, aggiungi un nuovo cron job o modifichi una direttiva del server web, aggiorna il tuo runbook e ripeti i test. Abbiamo visto troppi team trattare i backup come una semplice casella da spuntare. Una vera strategia di DR è integrata nella pipeline di deployment, nel monitoraggio e nella memoria muscolare del tuo team.

Se sei responsabile di un sito web PHP, inizia oggi. Rivedi la copertura dei backup per tutti e cinque i livelli, automatizza ciò che puoi e programma il primo test di ripristino. E se desideri un secondo parere sulla tua strategia, contatta DigiForge. Abbiamo costruito e ripristinato abbastanza siti PHP per sapere cosa funziona — e cosa no.