La maggior parte dei siti WordPress ha un qualche tipo di backup. Il provider di hosting ne fa uno, un plugin ne fa un altro e qualcuno, prima o poi, potrebbe averne scaricato una copia.
La domanda scomoda non è se un backup esiste. È se quel backup riesce davvero a rimettere in piedi il sito quando qualcosa va storto.
I backup falliscono più spesso di quanto si pensi. Un file può essere incompleto, il database può mancare, la cartella dei media può essere stata esclusa per risparmiare spazio, oppure l’unica copia può trovarsi sullo stesso server che si è appena guastato. Di solito nessuno se ne accorge fino al giorno in cui il backup serve.
La buona notizia è che si può prevenire facilmente. Un test di ripristino, fatto con calma e a cadenza regolare, ti dice se i backup funzionano quando c’è ancora tempo per correggerli.
Questa guida spiega cos’è un test di ripristino, ogni quanto farlo in base al tipo di sito, cosa controllare e chi dovrebbe occuparsene.
Perché un backup è utile solo se si ripristina?
Un backup è una promessa: se il sito si rompe, viene violato o cancellato, puoi tornare a uno stato funzionante noto.
Quella promessa dipende da più condizioni che devono essere vere contemporaneamente:
- il backup include tutti i file di cui il sito ha bisogno
- il backup include il database, dove si trovano pagine, impostazioni, utenti e ordini
- il backup è abbastanza recente da essere utile
- il backup è conservato in un posto che puoi raggiungere anche se il server non è disponibile
- qualcuno sa come ripristinarlo e ha gli accessi per farlo
Se anche una sola di queste manca, il backup può sembrare a posto in una dashboard ed essere comunque inutilizzabile.
Tra i problemi più comuni emersi durante i test di ripristino:
- archivi che hanno smesso di essere creati settimane fa senza che nessuno se ne accorgesse
- backup che contengono i file ma non il database, o viceversa
- caricamenti media esclusi perché il backup era troppo pesante
- backup cifrati con una password che nessuno ricorda
- copie conservate solo sullo stesso account di hosting del sito
- procedure di ripristino che conosceva solo lo sviluppatore originale
Nessuno di questi è un caso raro. Semplicemente restano invisibili finché qualcuno non prova a ripristinare.
Cos’è un test di ripristino?
Un test di ripristino significa prendere un backup, ripristinarlo davvero in un ambiente sicuro e poi verificare che il sito ripristinato funzioni.
Non è la stessa cosa che:
- vedere una spunta verde in un plugin di backup
- controllare che un file di backup esista
- leggere la dimensione del backup nel pannello dell’hosting
Sono segnali utili, ma non dimostrano che il backup sia in grado di ricostruire il sito.
Un vero test di ripristino si fa di solito su:
- una copia di staging fornita dall’hosting
- un dominio o un sottodominio di test separato
- una copia locale sul computer di uno sviluppatore
Non va mai fatto sovrascrivendo il sito online. Lo scopo è testare il backup senza mettere a rischio il sito reale.
Ogni quanto dovresti testare i backup?
Non esiste una risposta unica. La frequenza giusta dipende da quanto spesso cambia il sito e da quanto costerebbe all’azienda perdere i dati più recenti.
Come punto di partenza, considera quanto segue.
Siti vetrina o informativi
I siti che cambiano poche volte al mese, senza ordini né account utente, di solito si possono testare meno spesso. Un test di ripristino ogni qualche mese, e dopo ogni cambiamento importante come un restyling, una migrazione o un cambio di hosting, è una base ragionevole.
Siti con moduli, prenotazioni o aree riservate
Se il sito raccoglie richieste, prenotazioni, registrazioni o dati degli iscritti, il database cambia più spesso. Testare con maggiore regolarità, per esempio ogni uno o due mesi, aiuta a confermare che i dati recenti vengano salvati.
Negozi WooCommerce e siti molto attivi
I negozi online cambiano di continuo: ordini, clienti, giacenze e pagamenti. Qui un test di ripristino mensile è un minimo sensato e molte aziende preferiscono controllare più spesso. Vale anche la pena verificare che la frequenza dei backup sia adeguata al volume degli ordini. La guida su se un negozio WooCommerce ha bisogno di backup in tempo reale approfondisce la questione.
Dopo ogni cambiamento significativo
Qualunque sia il tipo di sito, esegui un test di ripristino dopo:
- il passaggio a un nuovo provider di hosting
- il cambio di plugin o di servizio di backup
- un aggiornamento importante di WordPress, del tema o dei plugin
- un incidente di sicurezza
- l’aggiunta di molti nuovi contenuti o media
Sono i momenti in cui è più probabile che le impostazioni dei backup cambino senza che nessuno se ne renda conto.
Cosa controllare dopo il ripristino?
Un sito ripristinato che carica la homepage è un buon inizio, ma non basta. Controlla le parti che contano per la tua attività.
File e codice
- il tema attivo si carica con la grafica corretta
- i plugin sono presenti e attivi
- eventuali funzionalità personalizzate funzionano ancora
- non ci sono errori di file mancanti
Il database
- pagine, articoli e menu sono presenti
- le impostazioni sembrano corrette, come nome del sito e lingua
- gli account utente esistono e puoi accedere con un account di prova
- compaiono i contenuti recenti, non solo quelli più vecchi
Media
- le immagini si vedono nelle pagine e nella libreria media
- i file scaricabili, come i PDF, sono presenti
- le immagini caricate di recente sono incluse
Le immagini mancanti sono uno dei segnali più comuni che la cartella wp-content/uploads non è stata inclusa nel backup.
Ordini e invii dei moduli recenti
Se il sito riceve ordini o raccoglie invii tramite moduli:
- controlla l’ordine più recente nella copia ripristinata
- confronta la sua data con il momento in cui è stato fatto il backup
- verifica che account cliente e abbonamenti siano presenti
- verifica che gli invii dei moduli salvati siano inclusi, se il tuo plugin per i moduli li salva
Così sai esattamente quanti dati andrebbero persi se questo backup venisse ripristinato sul sito online.
Dove conservare le copie di backup?
Un backup conservato sullo stesso server del sito protegge da alcuni problemi, come un aggiornamento andato male. Non protegge da altri, come:
- la sospensione o la compromissione dell’account di hosting
- un guasto del server
- una perdita di dati da parte del provider di hosting
- un attaccante che cancella sia il sito sia i suoi backup
Per questo almeno una copia va conservata off-site, cioè in un luogo separato e gestito in modo indipendente dall’account di hosting. Può essere un servizio di backup dedicato o uno spazio cloud che il sito stesso non può cancellare.
Durante i test, conviene ripristinare almeno qualche volta dalla copia off-site. È quella che ti servirà nello scenario peggiore.
Per quanto tempo conservare i backup?
La conservazione (retention) indica quanto indietro nel tempo arrivano i tuoi backup.
Tenere solo gli ultimi giorni può essere un problema. Alcuni guasti si notano tardi:
- malware presente da settimane
- contenuti cancellati per errore di cui ci si accorge solo dopo
- un plugin che ha corrotto i dati poco alla volta
Un approccio comune è tenere backup recenti frequenti, come copie giornaliere per qualche settimana, e meno copie più vecchie, come settimanali o mensili, per un periodo più lungo. La conservazione giusta dipende dalla tua attività, dallo spazio disponibile e da eventuali obblighi di legge sui dati dei clienti.
Ricorda che i backup contengono dati personali se il sito memorizza i dati dei clienti. I backup più vecchi vanno protetti e cancellati quando non servono più, nel rispetto dei tuoi obblighi in materia di privacy.
Chi è responsabile dei test sui backup?
Spesso è proprio qui la vera lacuna. Il provider di hosting presume che sia lo sviluppatore a testare i backup. Lo sviluppatore presume che lo faccia l’hosting. Il titolare presume che qualcuno se ne occupi.
Aiuta mettere per iscritto, in modo chiaro:
- quali sistemi creano i backup e con quale frequenza
- dove è conservata ciascuna copia
- chi controlla che i backup vengano creati
- chi esegue i test di ripristino e ogni quanto
- chi ha gli accessi necessari per ripristinare in caso di emergenza
- dove sono conservate le istruzioni di ripristino
I backup dell’hosting sono utili, ma molti provider li presentano come una comodità più che come una garanzia. Leggi le condizioni del tuo hosting per capire cosa coprono davvero.
Se nessuno ne è chiaramente responsabile, i test di ripristino tendono a non essere fatti.
Quali sono gli errori più comuni?
- Fidarsi della dashboard. Una notifica di backup riuscito non significa che il backup si possa ripristinare.
- Testare sul sito online. Ripristinare sopra la produzione per "vedere se funziona" può sovrascrivere ordini e contenuti reali.
- Tenere una sola copia. Una copia in un solo posto è un unico punto di fallimento.
- Dimenticare il database o i caricamenti. Un backup dei soli file, o del solo database, non è un sito completo.
- Non controllare mai la data del backup. Se i backup si sono interrotti senza avvisare, l’ultima copia potrebbe avere settimane.
- Nessuna procedura scritta. Sotto pressione, nessuno vuole ricostruire da zero il processo di ripristino.
Come si presenta una buona gestione dei backup?
Una gestione dei backup sana di solito prevede:
- backup automatici con una frequenza adeguata a quanto spesso cambia il sito
- almeno una copia off-site
- una conservazione abbastanza lunga da recuperare problemi notati in ritardo
- test di ripristino regolari su una copia di staging o locale
- una breve nota scritta per ogni test: data, backup usato, cosa è stato controllato, cosa mancava
- una persona o un fornitore indicato per nome come responsabile di tutto questo
Non serve che sia complicato. Serve che sia fatto con costanza.
Come può aiutarti D4Hub
D4Hub può aiutarti a trasformare i backup da un’ipotesi in qualcosa che hai verificato davvero.
In base al tuo sito, D4Hub può aiutarti a:
- verificare quali backup esistono e dove sono conservati
- controllare se file, database e media sono inclusi
- impostare una copia di backup off-site
- eseguire un test di ripristino su una copia di staging o locale
- documentare una procedura di ripristino che il tuo team possa seguire
- suggerire una frequenza e una conservazione dei backup adatte al tuo sito
- includere i controlli sui backup nella manutenzione continuativa con i piani di supporto D4Hub
Puoi chiedere supporto in qualsiasi momento, sia che ti serva un controllo una tantum sia test regolari nell’ambito della manutenzione.
Apri un ticket di supportoPer chi vuole fare da sé: eseguire un test di ripristino
Questi passaggi sono pensati per chi ha dimestichezza con i pannelli di hosting, SFTP e WP-CLI. Lavora solo su una copia di staging o locale, mai sul sito online. Se non sei sicuro di quale installazione stai usando, fermati e controlla prima di eseguire qualsiasi comando.
Controllare cosa contiene il backup
Prima di ripristinare qualsiasi cosa, guarda dentro l’archivio di backup e verifica che includa la cartella dei caricamenti e un file di database.
Per un archivio .zip:
unzip -l backup.zip | grep "wp-content/uploads" | head
unzip -l backup.zip | grep "\.sql"Per un archivio .tar.gz:
tar -tzf backup.tar.gz | grep "wp-content/uploads" | head
tar -tzf backup.tar.gz | grep "\.sql"Se la cartella dei caricamenti o il file SQL non compaiono, il backup è incompleto. Alcuni plugin di backup salvano database e file in archivi separati, quindi controlla tutti i file dello stesso set di backup.
Puoi anche verificare che il dump del database contenga delle tabelle:
grep -c "CREATE TABLE" database.sqlUn risultato pari a zero, o un numero molto basso, fa pensare a un dump vuoto o parziale.
Ripristinare su una copia di staging o locale
Usa lo strumento di staging del tuo hosting, la funzione di ripristino del plugin di backup puntata su un sito di test o un ambiente di sviluppo locale.
Su un sito di test dove WP-CLI è disponibile, un dump del database si può importare così. Prima fai una copia del database attuale del sito di test, nel caso tu debba tornare indietro:
wp db export test-site-before-import.sql
wp db import database.sqlwp db import sostituisce il contenuto del database a cui è collegato. Eseguilo solo sul sito di test. Controlla prima wp-config.php o esegui wp option get siteurl per confermare su quale sito stai lavorando.
Se il backup proviene da un dominio diverso, il sito ripristinato potrebbe cercare di caricare gli URL del sito online. Solo sul sito di test, visualizza prima un’anteprima della modifica:
wp search-replace "https://www.example.com" "https://staging.example.com" --dry-runTogli --dry-run solo dopo aver controllato il risultato.
Evitare che il sito di test si comporti come quello online
Una copia ripristinata di un sito online può inviare email, eseguire operazioni pianificate o collegarsi ai servizi di pagamento. Prima di testare:
- in Settings > Reading (Impostazioni > Lettura), spunta "Discourage search engines from indexing this site" (Scoraggia i motori di ricerca dall’effettuare l’indicizzazione di questo sito)
- disattiva o reindirizza le email in uscita con un plugin che blocca la posta o con l’opzione dello strumento di staging, se disponibile
- metti i gateway di pagamento in modalità test o sandbox, oppure disattivali
- proteggi il sito di test con una password se il tuo hosting lo consente
Sul sito di test, puoi impostare l’esclusione dai motori di ricerca anche con:
wp option update blog_public 0Una semplice checklist di ripristino
Annota le risposte ogni volta che fai un test:
- Quale backup hai usato e quando è stato creato?
- Dove era conservato: sul server o off-site?
- Il ripristino si è concluso senza errori?
- La homepage si carica con la grafica corretta?
- Riesci ad accedere alla bacheca con un account di prova?
- Pagine, menu e articoli recenti sono presenti?
- Immagini e file scaricabili si vedono correttamente?
- Qual è l’ordine o l’invio di modulo più recente e che data ha?
- Le funzioni chiave funzionano, come moduli, ricerca e checkout in modalità test?
- Cosa mancava o non andava, e chi lo sistemerà?
Quando hai finito, cancella la copia di test o tienila protetta. Contiene gli stessi dati del tuo sito online.
Domande frequenti
Basta il backup del mio provider di hosting?
Può essere un buon primo livello, ma vale la pena verificare cosa include, per quanto tempo viene conservato, se puoi ripristinarlo da solo e se è conservato separatamente dal tuo account di hosting. Molte aziende tengono anche una copia off-site indipendente.
Posso testare un backup senza un sito di staging?
Sì. Può andare bene una copia locale su un computer o un sottodominio temporaneo. Quello che conta è che il test avvenga lontano dal sito online e non invii email né elabori pagamenti.
Quanto dura un test di ripristino?
Dipende dalle dimensioni del sito, dallo strumento di backup e dall’ambiente di hosting. Un sito piccolo può essere ripristinato in fretta, mentre un negozio grande con molte immagini può richiedere più tempo. Il primo test di solito è il più lungo, perché stai anche mettendo a punto la procedura.
E se il test di ripristino fallisce?
È un’informazione utile, e molto meglio scoprirla ora che durante un’emergenza. Annota cosa non ha funzionato, correggi la configurazione dei backup e ripeti il test. Un test fallito di solito indica una cartella mancante, un database escluso o un problema di archiviazione.
Devo testare ogni singolo backup?
Di solito no. Controlli automatici sulla creazione dei backup, abbinati a test di ripristino completi regolari su un backup a campione, offrono un buon equilibrio. Testa più spesso dopo modifiche all’hosting, ai plugin o al sistema di backup stesso.
I backup devono rispettare le regole sulla privacy?
Se il sito memorizza dati personali, come i dati dei clienti o gli invii dei moduli, anche i backup contengono quei dati. Vanno protetti, l’accesso va limitato e le copie vecchie vanno cancellate secondo le tue politiche di conservazione e privacy.