Come verificare che i backup di WordPress siano realmente ripristinabili

Obiettivo della guida

Questa guida pratica spiega come controllare che i backup di un sito WordPress siano completi, integri e ripristinabili, fornendo una checklist operativa, i comandi WP-CLI utili e un runbook minimo per testare il restore in staging.

Perché la sola esistenza del backup non basta

La presenza di un file o di un archivio di backup non garantisce che il sito si possa effettivamente ripristinare: archivi mancanti di parti critiche o dump SQL corrotti possono impedire il recovery.

Per valutarne la reale utilità è quindi necessario eseguire test di ripristino periodici, preferibilmente su un ambiente di staging isolato che non impatti la produzione.

Cosa deve contenere un backup WordPress

Un backup utile include sempre due componenti distinte: i file del sito e il database.

• File critici da salvare: wp-config.php e la cartella wp-content (themes, plugins, uploads).
• Nota: i file core di WordPress (wp-admin, wp-includes) possono essere scaricati da un pacchetto ufficiale e quindi non sono obbligatori nei backup; wp-config.php e wp-content contengono personalizzazioni e dati che non si ricreano facilmente.
• I backup creati con tool/plugin possono essere archivi .zip o formati nativi del tool e dovrebbero includere il dump SQL del database insieme ai file.

Prima di generare il backup è buona pratica rimuovere dati temporanei o cache non necessari per ridurre dimensioni e tempi di backup.

Verificare e gestire il database con WP-CLI

Per esportare il database in modo ripetibile si possono usare i comandi documentati di WP-CLI: wp db export o wp db dump, che eseguono mysqldump usando le credenziali definite in wp-config.php e accettano i flag standard di mysqldump.

Per importare un dump SQL si utilizza wp db import (o lettura da STDIN); il comando esegue le query SQL presenti nel file usando le credenziali presenti in wp-config.php, ma non crea automaticamente il database di destinazione: assicurarsi che il database esista e che l’utente abbia i permessi necessari prima dell’import.

Controlli pratici sul dump SQL:

• Verificare dimensione e integrità del file SQL (ad esempio estraendolo in ambiente controllato e controllando che non termini in modo anomalo).
• Eseguire un’import di prova su uno staging isolato per confermare che le query si eseguono senza errori: questo è il test che trasforma l’esistenza del dump in una verifica di ripristinabilità.

Controllare l’integrità dei file: core, temi e plugin

Per i file core di WordPress è disponibile il comando wp core verify-checksums, che scarica checksum MD5 dalla sorgente ufficiale per la versione installata e confronta i file locali per rilevare modifiche o corruzioni.

Avvertenze pratiche:

• Il comando verifica soltanto i file core ufficiali; eventuali modifiche a plugin o temi (in wp-content) non sono coperte da questa verifica e richiedono controlli specifici o confronti con repository/versioni note.
• Per wp-content conviene verificare timestamp, dimensioni dei file e, quando possibile, confrontare con copie note o repository dei temi/plugin.

Dove conservare i backup: strategia 3-2-1 e separazione

Applicare la regola 3-2-1: mantenere almeno tre copie dei dati, su due supporti differenti, con almeno una copia offsite. Questo riduce il rischio di perdita simultanea.

Non conservare esclusivamente le copie di backup sullo stesso server di produzione: molte guide raccomandano di salvare copie autonome in posizioni diverse e rimuovere archivi temporanei dal server dopo il download.

Nota sui servizi hosting: alcuni provider offrono backup automatici (ad es. backup giornalieri e funzionalità di restore per gli ultimi N punti), ma non bisogna affidarsi unicamente a questi senza avere copie autonome.

Testare il ripristino: runbook minimo per restore in staging

Eseguire restore di prova su un ambiente di staging isolato è il modo concreto per verificare la ripristinabilità. Di seguito un runbook minimo e ripetibile:

1. Preparazione ambiente staging
   • Creare uno staging isolato con versione PHP/MySQL simili alla produzione; assicurarsi che sia isolato per non influire sui dati live.
   • Predisporre credenziali DB e spazio sufficiente.
2. Ripristino file
   • Caricare l’archivio dei file nello staging; estrarre wp-content e, se presente e necessario, adattare wp-config.php (o fornire una versione dello staging con DB e prefissi corretti).
   • Evitate di sovrascrivere wp-config.php originale se contiene credenziali sensibili; adattare i parametri di connessione per lo staging.
3. Ripristino database
   • Creare/determinare il database di destinazione sullo staging e verificare permessi.
   • Importare il dump SQL con wp db import o tramite utility equivalente; ricordare che wp db import esegue il file SQL ma non crea il database.
4. Verifiche post-restore
   • Eseguire wp core verify-checksums per controllare i file core del sito ripristinato.
   • Eseguire test funzionali essenziali: login admin, navigazione pagine pubbliche principali, operazioni critiche (es. checkout per e-commerce).
5. Documentazione
   • Registrare esito del test, tempi impiegati e problemi riscontrati; aggiornare il runbook con le eccezioni incontrate.

Inclusione di metadata utili: aggiungere ai backup una lista plugin/tema con le versioni e le regole server rilevanti per facilitare la ricostruzione dell’ambiente in caso di bisogno.

Avvertenza: senza un runbook documentato e provato, il ripristino rischia di essere più lento e soggetto a errori.

Checklist rapida di verifica pre-restore

• Dump SQL presente e dimensione plausibile; provare a estrarlo e leggere le prime/ultime righe.
• Presenza di wp-config.php e cartella wp-content nell’archivio.
• Eseguire wp core verify-checksums sui file core se sono stati inclusi o se il sito è già ripristinato in staging.
• Effettuare un import di prova del DB in staging per confermare che il dump sia eseguibile senza errori.
• Controllare che l’archivio non sia corrotto (estrazione locale) e che non contenga file temporanei non necessari.

Ricorda: anche se tutti i punti risultano positivi, il test di restore resta il modo definitivo per verificare la funzionalità del backup.

Automazione dei test di restore: opportunità e limiti

Le fonti raccolte sottolineano l’importanza dei test periodici di restore e suggeriscono di eseguirli su ambienti isolati, ma non forniscono un processo standardizzato per automatizzare interamente i test di restore (ad es. integrazione CI/CD con container).

Questo rappresenta un’opportunità: valutare soluzioni che eseguano restore automatici in ambienti containerizzati e che verifichino login/percorsi critici. Tuttavia, le procedure e gli script devono essere progettati e testati internamente, perché le fonti non offrono implementazioni consolidate.

Risorse e contenuti da includere nel runbook

Nel runbook minimo includere almeno:

• Lista plugin/tema e relative versioni (metadata).
• Comandi WP-CLI usati per export/import e verify-checksums (come documentato nelle fonti).
• Passi di verifica post-restore e responsabilità operative per ciascun step.

Conclusione e prossimi passi operativi

1. Verifica che i tuoi backup contengano sia i file che il database e che includano wp-config.php e wp-content.
2. Definisci e documenta un runbook di restore e pianifica test di restore su staging almeno periodicamente.
3. Applica la regola 3-2-1 per la conservazione dei backup e non affidarti solo alle copie sul server di produzione.

Esegui il primo test di restore controllato seguendo il runbook e registra i tempi e le issues: è il modo più efficace per trasformare il backup da promessa a garanzia operativa testata.