Disaster recovery WordPress: backup, RTO, RPO e prove di ripristino
15 Agosto 2026 · Siti web
Prima di iniziare
Il perimetro di «Disaster recovery WordPress» deve essere approvato prima di raccogliere dati. Le prime due condizioni da rendere esplicite sono «Scenari e funzioni critiche» e «RPO e RTO approvati». Senza queste fondamenta il team rischia di produrre un’analisi corretta dal punto di vista tecnico ma incapace di modificare il processo reale.
Prima di fissare RPO e RTO, direzione, fornitore e referenti tecnici devono elencare funzioni da ripristinare, dipendenze esterne e scenari coperti: database, media, DNS, email, pagamenti, API e credenziali non hanno sempre lo stesso recupero. Va registrato anche lo stato iniziale di backup, retention, accessi di emergenza e vincoli contrattuali dei servizi coinvolti.
Criteri di completamento
| Condizione | Evidenza richiesta | Governance |
|---|---|---|
| Scenari e funzioni critiche | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| RPO e RTO approvati | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Copie indipendenti | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Accessi d’emergenza | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Runbook completo | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Restore test documentato | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
La tabella è soddisfatta solo dopo un ripristino in ambiente isolato eseguito dalla copia prevista dal piano. Il verbale deve riportare punto di recupero ottenuto, durata delle fasi, accessi mancanti e controlli su form, ordini, email, cron e integrazioni; ogni anomalia che impedisce la riapertura resta una correzione bloccante.
Quando il metodo non è sufficiente
Una compromissione, una perdita di dati personali o l’indisponibilità di fornitori critici non si risolvono con il solo runbook WordPress. In questi scenari occorrono analisi forense, gestione dell’incidente, valutazioni privacy e comunicazioni definite dalle competenze responsabili, evitando di ripristinare copie potenzialmente contaminate senza verifica.
Backup riusciti e prove periodiche riducono l’incertezza, ma non assicurano che ogni incidente rispetti gli obiettivi dichiarati. RTO e RPO osservati dipendono da scenario, volume dei dati, disponibilità degli accessi e servizi esterni; ogni test deve quindi aggiornare stime, dipendenze e priorità senza confondere l’esito simulato con continuità garantita.
Definire scenari e priorità
Errore umano, aggiornamento, compromissione, guasto, cancellazione, problema DNS e perdita del provider hanno impatti diversi. Il piano deve indicare ordine di ripristino: sito, form, e-commerce, tracking, integrazioni.
Stabilire RPO e RTO
RPO indica quanta perdita di dati è accettabile; RTO quanto tempo è disponibile per ripristinare. Un blog e un e-commerce non hanno gli stessi valori. Le scelte determinano frequenza, replica e costi.
Progettare copie indipendenti
File, database, configurazioni, credenziali, DNS, certificati e chiavi possono essere necessari. Retention e copie offsite proteggono da corruzioni e perdita dell’infrastruttura primaria.
Preparare una runbook di ripristino
La procedura indica chi dichiara l’incidente, quale copia usare, dove ripristinare, come validare e quando riaprire il traffico. Accessi e contatti devono essere disponibili anche se il sito è offline.
Testare oltre la homepage
Login, contenuti, media, form, ordini, pagamenti, email, cron, tracking, integrazioni e sicurezza devono essere verificati. Un sito che si apre non è necessariamente ripristinato.
Gestire comunicazione e miglioramento
Stato, clienti, fornitori e autorità possono richiedere comunicazioni diverse. Dopo l’incidente si aggiorna il piano e si chiudono le cause.
Matrice operativa
| Scenario | RPO | RTO | Test critico |
|---|---|---|---|
| Errore editoriale | Ore/giorno | Breve | Versioni e media |
| Update fallito | Ultimo backup | Ore | Plugin, tema, form |
| Compromissione | Prima dell’incidente | Variabile | Pulizia e credenziali |
| Guasto provider | Replica disponibile | Ore/giorni | DNS e ambiente |
| E-commerce | Minuti/ore | Molto breve | Ordini e pagamenti |
Applicazione operativa
Il business impact workshop identifica funzioni critiche: form, ordini, pagamento, catalogo, contenuti, API e tracking. Per ciascuna si definiscono dipendenze e conseguenze dell’indisponibilità.
RPO e RTO vengono tradotti in tecnologia: frequenza, replica, retention, ambiente alternativo, accessi e persone. Obiettivi non supportati dall’infrastruttura devono essere corretti o finanziati.
Il restore test utilizza una copia in ambiente isolato e una checklist di funzionalità. Il verbale registra durata, errori, credenziali mancanti e azioni. Un test non documentato non migliora il piano.
Come misurare il risultato
Si misurano successo dei backup, età dell’ultima copia, tempo di restore, errori, copertura delle dipendenze e chiusura delle anomalie. La disponibilità del sito non dimostra recupero dei dati.
RTO e RPO effettivi del test vengono confrontati con gli obiettivi. Lo scarto guida investimenti e procedure.
Esempio ragionato
Un aggiornamento compromette il database di un e-commerce. Il provider dispone di una copia giornaliera, ma ripristinarla farebbe perdere ordini. Il piano precedente non aveva RPO esplicito.
Il nuovo sistema usa backup incrementali, esportazione ordini, copie offsite e runbook. Il test dimostra un RTO reale più alto del previsto e porta a correggere SLA e responsabilità.
Checklist di esecuzione
- Scenari e funzioni critiche
- RPO e RTO approvati
- Copie indipendenti
- Accessi d’emergenza
- Runbook completo
- Restore test documentato
Errori da evitare
- Confondere backup e disaster recovery.
- Conservare copie solo sullo stesso server.
- Definire frequenza senza RPO.
- Non provare gli accessi d’emergenza.
- Considerare concluso il restore dopo il caricamento dei file.
Domande frequenti
WordPress raccomanda backup di file e database?
Sì. La documentazione ufficiale tratta entrambi e raccomanda di verificare che le copie siano disponibili e utilizzabili.
Quanto spesso testare?
In base alla criticità e ai cambi. Un e-commerce o sito lead-critical richiede prove più frequenti di un sito stabile.
RTO e RPO devono essere contrattuali?
Devono almeno essere concordati e compatibili con SLA e capacità del fornitore; nei servizi critici è opportuno formalizzarli.
Fonti e riferimenti
- NIST SP 800-34 — Contingency Planning Guide — https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- WordPress Developer Resources — Backups — https://developer.wordpress.org/advanced-administration/security/backup/
- WordPress Developer Resources — Hardening WordPress — https://developer.wordpress.org/advanced-administration/security/hardening/
Come trasformare la guida in un’attività concreta
Definire scenari, RPO, RTO, inventario delle dipendenze e runbook e completare un restore test in ambiente isolato con verbale delle anomalie.
Approfondisci il servizio: Hosting gestito.