Checklist per il backup WordPress: frequenza, retention, offsite e restore test
18 Settembre 2026 · Siti web
Perché usare questa checklist
Questa checklist serve a verificare se un sito WordPress può essere ricostruito entro gli obiettivi attesi, non soltanto se genera copie. La compilazione deve seguire gli scenari di perdita rilevanti e coinvolgere chi gestisce hosting, applicazione, dati, accessi e continuità del servizio.
Definire scenari e criticità
Errore umano, update, compromissione, guasto e perdita del provider richiedono copie e procedure differenti.
Coprire file e database
WordPress separa normalmente file applicativi e database. Entrambi, insieme alle configurazioni necessarie, devono appartenere allo stesso set di ripristino.
Stabilire frequenza e retention
RPO determina quanta perdita è accettabile; la retention protegge da corruzioni scoperte tardi.
Separare copie e accessi
Backup offsite e credenziali di emergenza riducono la dipendenza dallo stesso ambiente. Gli snapshot possono integrare, non sostituire, la strategia.
Provare il restore completo
Homepage, login, media, form, ordini, email, cron, tracking e integrazioni devono essere verificati.
Checklist operativa
| Area | Controllo | Evidenza richiesta | Priorità |
|---|---|---|---|
| Scenari | Sono elencati errori, compromissione, guasto e perdita provider? | Risk register | Alta |
| Ambito | File, database e configurazioni necessarie sono inclusi? | Backup inventory | Alta |
| Consistenza | File e database appartengono allo stesso punto temporale? | Backup set | Alta |
| RPO | È definita la perdita massima accettabile? | Business requirement | Alta |
| RTO | È definito il tempo massimo di ripristino? | Recovery objective | Alta |
| Frequenza | La cadenza è coerente con cambi e transazioni? | Schedule | Alta |
| Retention | Esistono più punti temporali sufficienti? | Retention policy | Alta |
| Offsite | Almeno una copia è indipendente dal provider primario? | Storage map | Alta |
| Cifratura | Copie, trasporto e chiavi sono governati? | Security review | Alta |
| Accessi | Credenziali di emergenza sono disponibili e protette? | Access register | Alta |
| Snapshot | Ruolo e limiti degli snapshot sono documentati? | Recovery matrix | Media |
| Restore test | Il ripristino è provato e verbalizzato? | Test report | Alta |
Come leggere la checklist
Assegna «Conforme» solo quando il controllo è dimostrato da configurazioni, inventari, log o verbali di ripristino aggiornati. Usa «Parziale» se la copertura riguarda soltanto alcuni ambienti o scenari, «Non conforme» se la protezione manca o non è stata provata e «N/A» esclusivamente quando il controllo è estraneo all’architettura documentata.
Una priorità alta segnala che il difetto può compromettere disponibilità o recuperabilità, ma la sequenza degli interventi dipende dal caso. Prima possono venire, per esempio, l’accesso alla copia offsite o la coerenza tra file e database, perché senza questi prerequisiti anche un restore test ben pianificato non sarebbe eseguibile.
| Esito | Significato | Azione |
|---|---|---|
| Conforme | Regola documentata, applicata e controllata. | Mantenere e fissare la revisione. |
| Parziale | Pratica incompleta, incoerente o non misurabile. | Definire lacuna, owner e scadenza. |
| Non conforme | Regola assente o problema osservabile. | Aprire intervento e gestire le dipendenze. |
| N/A | Controllo realmente estraneo al perimetro. | Documentare la motivazione. |
Interpretazione dei controlli più bloccanti
Scenari
Verificare se sono elencati errori, compromissione, guasto e perdita provider?. Evidenza minima: Risk register. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Ambito
Verificare se file, database e configurazioni necessarie sono inclusi?. Evidenza minima: Backup inventory. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Consistenza
Verificare se file e database appartengono allo stesso punto temporale?. Evidenza minima: Backup set. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
RPO
Verificare se è definita la perdita massima accettabile?. Evidenza minima: Business requirement. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
RTO
Verificare se è definito il tempo massimo di ripristino?. Evidenza minima: Recovery objective. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Frequenza
Verificare se la cadenza è coerente con cambi e transazioni?. Evidenza minima: Schedule. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Output obbligatori
- Backup policy
- RPO/RTO matrix
- Storage e access map
- Runbook di ripristino
- Verbale restore test
I risultati devono diventare interventi verificabili sulla strategia di backup: correggere una retention insufficiente, separare una copia, recuperare credenziali di emergenza o ripetere un restore fallito. Per ciascuna correzione vanno indicati lo scenario coperto, l’ambiente interessato, la condizione da provare e la data del controllo successivo.
Scenario applicativo
Il provider conserva snapshot automatici nello stesso account. Un incidente rende indisponibile l’intero ambiente e le copie non sono accessibili.
La nuova strategia mantiene snapshot per rollback rapido e backup offsite di file e database, verificati in un ambiente isolato.
Errori da evitare
- Confondere snapshot e strategia di backup.
- Salvare soltanto i file.
- Conservare una sola copia.
- Dichiarare RTO mai provati.
- Considerare concluso il restore quando il sito si apre.
Domande frequenti
WordPress richiede file e database?
Per ripristinare un sito tipico servono entrambi, come indica la documentazione ufficiale.
Quanto spesso testare?
In funzione della criticità e dei cambi; i servizi commercialmente essenziali richiedono prove più frequenti.
Il backup dell’hosting basta?
Solo se ambito, retention, accessi, separazione e restore sono verificati rispetto agli obiettivi.
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/
Approfondisci il servizio: Hosting gestito.