Tre modi di salvare WordPress, tre ripristini veri: col solo database il sito non torna

Il 5 ottobre 2026 abbiamo distrutto tre volte lo stesso negozio WooCommerce, per vedere quale dei tre backup più comuni lo riportava davvero in piedi. Risposta breve: uno su tre no, anche se sembra il più comodo.

L'impianto

Negozio di prova: 500 prodotti, 41 allegati, 290 file nella cartella uploads, un ordine reale. Stack: WordPress 7.1.2, WooCommerce 11.1.2, PHP 8.3.35, MariaDB 11.8.9. Versioni reali: WordPress 7.1.2 è uscita il 22 settembre 2026 come release di sicurezza, WooCommerce 11.1.2 lo stesso giorno, anch'essa con una correzione di sicurezza oltre a un paio di bug fix.

Per ogni metodo abbiamo fatto il backup, poi distrutto l'impianto come in un trasloco su server nuovo: core reinstallato da zero, wp-content e database persi. Poi il ripristino, poi otto controlli: home, pagina catalogo e immagine devono rispondere ed essere vere (non basta il codice HTTP), più i conteggi di prodotti, allegati, ordini, file in uploads, utenti e opzioni.

Il dettaglio che frega tutti: una pagina di errore di WordPress risponde comunque con codice 200. Un controllo che guarda solo lo status code dice "sito su" anche quando il sito è morto. I nostri controlli guardano anche il contenuto della risposta e il tipo di file restituito.

I risultati

Metodo	Tempo backup	Dimensione	Tempo ripristino	Controlli superati
Solo database	0,3 s	1 MB	1,1 s	4 su 8
Database + wp-content	1,8 s	34 MB	1,8 s	8 su 8
Database + root intera	2,9 s	60 MB	2,4 s	8 su 8

Con il solo database (mysqldump): home rotta, pagina catalogo rotta, immagine persa, 0 file su 290 recuperati. Prodotti, allegati (come record) e ordini invece tornano tutti, perché quei dati vivono nelle tabelle. È il punto pericoloso: il database contiene ancora i nomi dei file immagine, quindi a un controllo superficiale "i dati ci sono". Ma i file fisici in uploads non esistono più, quindi il sito non si apre correttamente.

Database + wp-content porta tutto a casa: 8 controlli su 8, con 33 MB e un secondo abbondante in più rispetto al solo database.

Database + root intera dà lo stesso risultato (8 su 8) ma pesa di più, perché include anche il core di WordPress che tanto si reinstalla da zero. Serve comunque, in altri scenari, per wp-config.php e per tutto quello che sta fuori da wp-content (es. file di configurazione del webserver nella root).

La tesi

Il backup del solo database è il caso peggiore, non perché non funzioni mai, ma perché sembra un backup: il file c'è, pesa poco, si fa in un terzo di secondo. Chi non prova il ripristino scopre il buco solo quando serve davvero. Fare la cosa giusta — aggiungere wp-content — costa 33 MB e un secondo in più di backup. Poco, a confronto del sito rotto.

Come provarlo senza rischi

Prima di fidarsi di un backup, va ripristinato su un sottodominio di prova (es. test.tuosito.it), puntato a una copia del database con nome diverso, senza toccare DNS o impianto in produzione. Bastano una cartella nuova, un wp-config.php con credenziali diverse e un dump importato a parte. La prova dura meno di tre secondi per il ripristino vero e proprio: chi non l'ha mai fatta non sa se ha un backup, sa soltanto di avere un file.