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.
Vanno inoltre definiti proprietario della decisione, persone da coinvolgere, sistemi accessibili, periodo analizzato ed eccezioni note. Le fonti devono essere datate e la terminologia condivisa prima di confrontare report o configurazioni appartenenti a reparti diversi.
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 |
Una condizione è chiusa soltanto quando l’evidenza è accessibile, comprensibile e ripetibile. La riunione di approvazione o la pubblicazione non bastano se il risultato non può essere verificato da chi dovrà mantenerlo.
Quando il metodo non è sufficiente
Questa guida non sostituisce test specialistici, verifica legale, analisi di sicurezza o decisioni commerciali che richiedono dati riservati. Quando emergono rischi elevati, grandi volumi di URL o dati, integrazioni critiche o affermazioni tecniche non documentate, il progetto deve coinvolgere la competenza responsabile prima di procedere.
Il metodo serve a rendere visibili decisioni e lacune. Non garantisce ranking, citazioni, lead, ricavi o continuità assoluta. I risultati dipendono dalla qualità dell’esecuzione, dal mercato e da sistemi esterni; le conclusioni devono quindi separare fatti, inferenze e ipotesi.
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
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.