Backup WordPress: come progettare copie realmente ripristinabili

31 Luglio 2026 · Siti web

Un backup non è riuscito perché il pannello mostra una spunta verde. È riuscito quando permette di riportare il sito a uno stato coerente entro tempi compatibili con il business. File incompleti, database non sincronizzato, credenziali mancanti o copie conservate sullo stesso server possono rendere inutile un sistema apparentemente attivo.

Progettare backup WordPress significa decidere che cosa salvare, quanto si può perdere, dove conservare le copie e come provarne il ripristino.

Capire che cosa compone realmente il sito

WordPress separa contenuti e configurazioni tra database e file. Un set di backup completo può includere:

• database WordPress;
• core, anche se reinstallabile;
• wp-content con temi, plugin e upload;
• file di configurazione;
• regole server come .htaccess o configurazioni Nginx;
• mu-plugin e codice personalizzato;
• media conservati su storage esterno;
• configurazione CDN e DNS;
• certificati o segreti, con protezione adeguata;
• cron e processi esterni;
• integrazioni, webhook e impostazioni non presenti nel database;
• documentazione di versioni e dipendenze.

La documentazione ufficiale WordPress ricorda che database e file sono componenti distinti. Salvare soltanto gli upload non conserva articoli, utenti e impostazioni; salvare soltanto il database non recupera media, plugin e codice.

Definire RPO e RTO in termini comprensibili

Due concetti aiutano a scegliere la strategia.

• RPO, Recovery Point Objective: quanta informazione l’azienda può accettare di perdere. Se l’ultimo backup è di 24 ore fa, ordini e modifiche successive possono andare persi.
• RTO, Recovery Time Objective: entro quanto tempo il servizio deve tornare disponibile.

Non sono valori tecnici astratti. Devono derivare dal sito.

“Backup giornaliero” non è sempre sufficiente e “backup ogni cinque minuti” non è sempre necessario.

Usare più livelli di copia

Una strategia robusta evita un unico punto di fallimento. Può combinare:

• snapshot dell’hosting per recuperi rapidi;
• backup applicativi o infrastrutturali indipendenti;
• copia offsite su un provider separato;
• versioni con retention differente;
• backup manuale prima di aggiornamenti e migrazioni;
• repository del codice personalizzato.

La regola 3-2-1 — più copie, su supporti o sistemi differenti, con almeno una offsite — è un riferimento utile, ma va adattata. Se pannello, credenziali e storage dipendono dallo stesso account compromesso, le copie non sono davvero indipendenti.

Progettare la retention contro gli errori scoperti tardi

Conservare soltanto l’ultima copia protegge poco da corruzioni, malware o errori rimasti invisibili per settimane. Una retention può prevedere:

• copie frequenti per pochi giorni;
• giornaliere per alcune settimane;
• settimanali o mensili per periodi più lunghi;
• copie speciali prima di release importanti;
• conservazione estesa per obblighi o progetti specifici.

La durata deve considerare spazio, rischio, dati personali e politiche di cancellazione. Conservare tutto per sempre non è automaticamente corretto.

Garantire coerenza tra file e database

Su siti dinamici, file e database cambiano durante il backup. Una copia effettuata mentre arrivano ordini o vengono caricati media può produrre uno stato incoerente.

Il sistema deve chiarire:

• se usa snapshot consistenti;
• se mette temporaneamente il sito in manutenzione;
• come gestisce tabelle molto grandi;
• se database e file appartengono allo stesso punto temporale;
• come tratta upload su storage esterno;
• come verifica l’integrità dell’archivio.

Per e-commerce e aree transazionali, il ripristino deve anche gestire ciò che è avvenuto dopo il punto scelto: ordini, pagamenti, email, stock e sistemi esterni non possono essere ignorati.

Cifrare, limitare e monitorare gli accessi

Le copie possono contenere dati personali, credenziali e configurazioni sensibili. Devono essere protette almeno quanto il sito di produzione.

Controlli utili:

• cifratura durante trasferimento e conservazione;
• account dedicati e autenticazione forte;
• permessi minimi;
• separazione dagli accessi ordinari WordPress;
• log di creazione, download e cancellazione;
• avvisi in caso di backup fallito;
• protezione dalla cancellazione immediata o malevola;
• rotazione delle credenziali;
• policy di conservazione e distruzione.

Un link pubblico a un archivio .zip annulla buona parte della sicurezza del sito.

Testare il ripristino in un ambiente isolato

La prova non dovrebbe sovrascrivere la produzione. Si ripristina una copia in un ambiente separato e si verifica:

1. possibilità di scaricare e decifrare gli archivi;
2. integrità di file e database;
3. compatibilità di versioni PHP, database e server;
4. accesso amministrativo;
5. visualizzazione di pagine, media e contenuti;
6. funzionamento di plugin e codice personalizzato;
7. moduli, email, login e permessi;
8. ordini o funzioni critiche;
9. configurazioni di URL e ricerca-sostituzione;
10. assenza di comunicazioni reali dall’ambiente di prova;
11. tempo impiegato e passaggi manuali.

Il test deve produrre un verbale con esito, problemi, tempi e azioni correttive. “Il database è stato importato” non significa che il sito sia ripristinato.

Preparare un runbook leggibile anche durante un incidente

La procedura deve indicare:

• chi dichiara l’incidente;
• chi sceglie il punto di ripristino;
• dove si trovano copie e credenziali;
• come mettere in sicurezza l’infrastruttura compromessa;
• ordine di ripristino;
• controlli prima della riapertura;
• gestione di DNS, cache e CDN;
• riconciliazione dei dati successivi al backup;
• comunicazioni interne ed esterne;
• criteri per chiudere l’incidente.

Le credenziali non vanno inserite in chiaro nel runbook, ma deve essere chiaro come ottenerle anche se il referente abituale non è disponibile.

Backup, staging e alta disponibilità non sono la stessa cosa

• Lo staging serve a provare modifiche; può contenere dati obsoleti e non è una copia di recupero affidabile.
• L’alta disponibilità riduce i tempi di fermo dovuti a guasti, ma può replicare cancellazioni o corruzioni.
• Il backup permette di tornare a uno stato precedente.
• Il disaster recovery comprende persone, infrastruttura, priorità e procedure per ristabilire il servizio.

Confondere questi controlli crea un falso senso di protezione.

Un esempio di fallimento evitabile

Un sito e-commerce ha backup giornalieri sullo stesso account hosting. Un attacco compromette pannello e sito e cancella anche gli archivi. L’azienda scopre che non esistono copie esterne e che i record degli ordini più recenti non sono presenti nel gestionale.

Una strategia migliore avrebbe previsto copia offsite con account separato, retention, esportazione o replica degli ordini e test periodico. Il problema non era il plugin scelto, ma l’assenza di indipendenza e verifica.

Checklist di accettazione

Un piano può essere considerato operativo quando:

• l’ambito è documentato;
• frequenza e retention derivano da RPO e rischio;
• almeno una copia è separata dall’infrastruttura primaria;
• errori e mancati backup generano avvisi;
• accessi e cifratura sono controllati;
• esiste un runbook;
• un ripristino completo è stato provato;
• tempi e lacune emersi dal test sono stati corretti;
• owner e data della prossima prova sono definiti.

Il principio finale

Il backup è una capacità di recupero, non un archivio. La sua qualità si misura nel momento in cui file, database, persone e procedure devono ricostruire un servizio coerente. Finché il ripristino non è stato provato, esiste soltanto una speranza ben confezionata.

Fonti ufficiali

• 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.