Backup di un sito WordPress: la strategia 3-2-1 spiegata semplice

Un sito WordPress non è un file unico: è un database che contiene contenuti e impostazioni, più una cartella di file (temi, plugin, immagini caricate) che li rende visibili. Un backup che ne salva solo uno dei due non è un backup completo, tanto che la documentazione ufficiale di WordPress dedica due pagine separate a «Backing Up Your Database» e «Backing Up Your WordPress Files».

1. Cosa salvare: database e file, sempre insieme

• Database: articoli, pagine, commenti, utenti e impostazioni di temi e plugin. Si esporta tipicamente in un file .sql.
• File: soprattutto la cartella wp-content (temi, plugin, immagini caricate) e il file wp-config.php con le credenziali di connessione. I file «core» di WordPress non sono indispensabili da salvare: si possono sempre recuperare da un pacchetto ufficiale scaricato da zero.

Al momento del ripristino, l'ordine conta: prima si ripristinano i file, poi si importa il database.

Fonte: developer.wordpress.org Advanced Administration Handbook: «Backing Up Your Database» e  «Backing Up Your WordPress Files»

2. La regola 3-2-1: spiegata in una frase

La strategia 3-2-1, nata nel mondo della gestione dati e applicata qui a WordPress, si riassume così: 3 copie dei tuoi dati, su 2 supporti diversi, con almeno 1 copia offline. Applicata a un sito: una copia può restare sull'hosting stesso (spesso inclusa nel backup del fornitore), una seconda va scaricata o salvata su uno spazio di archiviazione diverso, e almeno una deve trovarsi in un luogo fisicamente separato dal server che ospita il sito e comunque non raggiungibile dall'esterno.

3. Dove conservarlo

Il punto debole più comune è tenere l'unica copia di backup sullo stesso server del sito. Se l'hosting subisce un attacco, un guasto al disco o un blocco per mancato pagamento, quella copia diventa irraggiungibile esattamente insieme al sito che dovrebbe salvare. Uno spazio di archiviazione cloud indipendente dal fornitore di hosting o un servizio di backup dedicato, garantisce che almeno una copia resti disponibile qualunque cosa succeda all'hosting.

4. Frequenza: dipende da quanto cambia il sito

Non esiste un intervallo universale: la frequenza giusta dipende da quanto spesso cambiano i contenuti. Un e-commerce con ordini quotidiani o un blog aggiornato ogni giorno ha bisogno di backup del database quotidiani, se non più frequenti; un sito istituzionale aggiornato di rado può bastare con cadenza settimanale. Una regola vale comunque per tutti: un backup manuale prima di ogni aggiornamento di core, temi o plugin, indipendentemente dalla frequenza programmata.

5. Il test di ripristino: il passaggio che quasi tutti saltano

Un backup mai ripristinato è solo un'ipotesi. Verificarne periodicamente il funzionamento ripristinandolo su un ambiente di prova separato, non sul sito live, è l'unico modo per scoprire in anticipo problemi come un prefisso delle tabelle diverso da quello atteso o credenziali del database non aggiornate nel file wp-config.php, che sono le cause più comuni di un ripristino fallito.

In sintesi

La regola 3-2-1 non è burocrazia: è l'unica cosa che rende reversibile un aggiornamento andato storto, un errore umano o un attacco riuscito. E, come ogni misura di sicurezza, vale solo quanto l'ultima volta in cui è stata davvero messa alla prova con un ripristino.