Quante volte hai rimandato a verificare se il backup del tuo sito WordPress funziona davvero? La maggior parte dei siti ha qualcosa attivo, qualche copia salvata da qualche parte, e la sensazione di essere al sicuro.
La sensazione, appunto.
Un backup sito WordPress incompleto è peggio di non averlo: ti fa credere di essere protetto quando non lo sei. E scoprirlo — che mancava un componente, che la destinazione remota non era configurata, che le copie contenevano già il problema — lo scopri sempre nel momento peggiore.
Un backup WordPress completo non è un plugin installato e dimenticato. È un sistema con tre componenti che devono funzionare insieme: i file del sito, il database, e una destinazione remota indipendente dall’hosting. A questi si aggiunge una retention policy — la decisione su quante copie conservare e per quanto tempo — che determina se puoi tornare indietro abbastanza nel tempo quando serve.
Se manca uno dei tre componenti, o se la retention è troppo corta, il backup esiste ma non ti salva. In questo articolo spiego come funziona un sistema di backup completo, perché il backup dell’hosting da solo non basta, e come valutare se quello che hai ora è davvero sufficiente per il tuo tipo di sito.
Cosa succede concretamente quando un sito WordPress perde i dati
Circa 13.000 siti WordPress vengono compromessi ogni giorno nel mondo. La maggior parte non viene presa di mira direttamente — viene trovata da bot automatizzati che scansionano la rete cercando installazioni con plugin non aggiornati, versioni PHP obsolete, o credenziali deboli. Non sei un obiettivo speciale. Sei un’opportunità che i bot trovano prima o poi.
Quando un sito viene compromesso o perde dati, le conseguenze non sono solo tecniche. Sono conseguenze di business:
- Il sito va offline. Ogni ora di inattività significa contatti non ricevuti, ordini non completati, clienti che trovano un messaggio di errore invece della tua pagina. Per un e-commerce attivo, anche 24-48 ore offline hanno un costo immediato e misurabile.
- Google penalizza il sito. I motori di ricerca rilevano i siti che servono contenuto malevolo e li rimuovono dai risultati di ricerca, o mostrano un avviso ‘sito non sicuro’ nei browser. Recuperare il posizionamento perso richiede settimane o mesi di lavoro — non è automatico.
- Il danno alla reputazione è reale. Un cliente che visita il sito e viene reindirizzato verso contenuto spam, o che vede un avviso di sicurezza nel browser, non torna. La fiducia si costruisce nel tempo e si perde in un’ora.
- Ci sono implicazioni GDPR. Se il sito gestisce dati personali di utenti o clienti e viene compromesso, c’è un obbligo di notifica al Garante entro 72 ore. Una violazione dei dati può avere conseguenze legali ed economiche significative.
Prova a fare questo calcolo
Quante ore è stato online il tuo sito ieri? Quanti contatti o ordini sono arrivati? Ora moltiplica per i giorni che potrebbero servire per rimettere online un sito compromesso senza backup — ammesso che i dati siano recuperabili. Aggiungi le settimane per recuperare il posizionamento Google. Aggiungi i clienti che nel frattempo hanno trovato il sito offline o compromesso e non torneranno.
Quello è il costo di non avere un backup completo.
I tre componenti di un backup sito WordPress completo
Un backup WordPress completo ha tre componenti distinte. Quasi tutti i siti ne hanno una o due. Il problema emerge quando serve quella che manca.
I file del sito
I file del sito includono il tema attivo con tutte le sue personalizzazioni, i plugin installati, e la cartella che contiene tutto quello che hai caricato nel tempo: immagini, documenti, video, file scaricabili. Anni di lavoro editoriale e grafico.
Se perdi i file senza averli nel backup, puoi reinstallare WordPress e un tema base — ma perdi ogni personalizzazione grafica, ogni immagine del catalogo, ogni documento caricato. Ricostruirli richiede tempo che quasi mai è disponibile nel mezzo di un’emergenza.
Il database MySQL
Il database contiene tutto quello che non è un file: i contenuti delle pagine e degli articoli, le impostazioni del sito, gli utenti registrati, gli ordini WooCommerce con dati clienti e storico acquisti, i commenti, le configurazioni di ogni plugin.
Il database è la memoria del sito. Se hai i file senza il database, il sito si carica ma è completamente vuoto — nessuna pagina, nessun prodotto, nessun contenuto. Se hai il database senza i file, non c’è niente da mostrare. Servono entrambi — e devono essere dello stesso momento. Un backup dei file di ieri e un database di tre giorni fa producono un sito parzialmente rotto al momento del ripristino.
La destinazione remota
È il componente che manca alla maggior parte dei siti. Un backup salvato solo sul server dello stesso hosting non è una protezione indipendente — se l’account viene compromesso o il server ha un problema grave, il backup è sullo stesso sistema che ha il problema.
Una destinazione remota — Google Drive, Dropbox, Amazon S3, o qualsiasi servizio esterno all’hosting — garantisce che esista sempre almeno una copia del sito completamente indipendente dall’hosting. È il componente che trasforma un backup da ‘probabilmente funziona’ a ‘funziona sicuramente anche nel caso peggiore’.
Perché la maggior parte dei backup WordPress non è davvero completa
Nella mia esperienza, i problemi più comuni non riguardano chi non fa il backup — riguardano chi pensa di farlo correttamente ma ha lasciato un componente incompleto.
Il problema più comune: il backup viene eseguito regolarmente, ma viene salvato solo sul server dello stesso hosting. La destinazione remota non è mai stata configurata perché richiede un passaggio aggiuntivo che si rimanda. Finché non serve, nessuno se ne accorge.
Il secondo problema: il backup include i file ma non il database, o viceversa. Alcuni sistemi di backup nella loro configurazione base non includono entrambi automaticamente. Chi ha configurato il backup una volta sola senza verificare cosa venisse effettivamente salvato potrebbe scoprirlo solo al momento del ripristino.
Il terzo problema: la retention troppo corta. Conservare solo le ultime 7 copie sembra sufficiente — non lo è se un malware si è infiltrato silenziosamente 10 giorni fa. Tutti i backup disponibili contengono già il malware, e ripristinare da uno di essi non risolve il problema: lo reimpianta.
Il backup dell’hosting: cosa copre e cosa lascia scoperto
Quasi tutti gli hosting offrono backup automatici — Aruba, SiteGround, Register.it, Netsons. Molti proprietari di siti li considerano la loro protezione principale, spesso l’unica. È una delle false sicurezze più comuni nella gestione di un sito WordPress.
Il problema non è la qualità del backup dell’hosting — molti fanno backup eccellenti con retention di 30 giorni o più. Il problema è strutturale: quel backup è sullo stesso account, sullo stesso sistema, spesso sullo stesso data center del sito live. In tre scenari specifici, non basta:
- Compromissione dell’account. Se un attaccante ottiene accesso all’account hosting, ha accesso anche ai backup. Può cancellarli, modificarli, o usarli per capire come è strutturato il sito prima di attaccarlo ulteriormente.
- Errore lato server. Raro ma non impossibile. Migrazioni mal gestite, guasti hardware, errori di configurazione possono compromettere sia il sito che i backup sullo stesso sistema.
- Cancellazione o scadenza dell’account. Se l’abbonamento scade o l’account viene sospeso, i backup dell’hosting scadono con lui.
La soluzione non è smettere di affidarsi al backup dell’hosting — rimane un’ottima prima linea di difesa per i problemi più comuni. La soluzione è affiancargli una copia indipendente su destinazione esterna. Le due protezioni insieme coprono praticamente ogni scenario di rischio reale.
Quante copie tenere, dove e per quanto tempo: la retention policy
La retention policy è la decisione su quante copie conservare e per quanto tempo. È il componente che quasi nessuno configura consapevolmente — la maggior parte dei siti usa i valori predefiniti del sistema di backup, che quasi sempre non sono calibrati sul tipo di sito.
Il rischio che la retention deve coprire non è solo il guasto tecnico improvviso — per quello bastano le ultime 2-3 copie. Il rischio più subdolo è il problema che si manifesta in ritardo: un accesso non autorizzato che nessuno ha notato subito, un contenuto modificato settimane fa, un errore che produce effetti visibili solo dopo.
Una retention pratica per siti business
- Backup giornalieri conservati per 14 giorni. Coprono problemi scoperti entro due settimane dall’evento.
- Backup settimanali conservati per 4 settimane. Coprono problemi scoperti entro un mese.
- Backup mensili conservati per 3 mesi. Coprono scenari di compromissione lenta e problemi scoperti in ritardo.
Per e-commerce con transazioni quotidiane, il database degli ordini merita backup più frequenti — ogni 6 ore o in tempo reale. Ogni ordine non salvato nel backup è un dato potenzialmente perso in caso di ripristino.
Il calcolo dello spazio
Un sito WordPress medio pesa tra 500MB e 2GB incluso il database. Con la retention descritta si arriva a circa 20-30 copie totali. Su Google Drive o Dropbox, 30 copie da 1GB occupano 30GB — una cifra trascurabile rispetto al rischio che copre.
Gestirlo da soli o delegarlo: la domanda giusta da farsi
La gestione corretta di un sistema di backup WordPress non è una configurazione una tantum. È un processo con quattro attività distinte nel tempo:
- Configurazione iniziale. Definire i tre componenti, la destinazione remota, la retention policy adatta al tipo di sito. Un’ora di lavoro la prima volta, se si sa esattamente cosa si sta facendo.
- Verifica mensile. Controllare che le copie vengano eseguite regolarmente, che la destinazione remota sia raggiungibile, che le dimensioni siano coerenti con quelle del sito. Anomalie in questi dati indicano spesso problemi che non hanno ancora generato un errore visibile.
- Test del ripristino. Almeno una volta ogni tre mesi, verificare che sia possibile ripristinare effettivamente da un backup su un ambiente separato. Una copia mai testata è un’assunzione, non una certezza.
- Aggiornamento della strategia. Quando il sito cresce — più contenuti, più utenti, WooCommerce aggiunto — la frequenza e la retention devono essere ricalibrate. Quello che bastava per un sito vetrina non basta per un e-commerce attivo.
Chi gestisce queste quattro attività in modo sistematico ha una protezione reale. Chi le gestisce saltuariamente — quando se ne ricorda, quando ha tempo — ha una protezione parziale che sembra completa.
La domanda da farsi non è ‘posso gestirlo da solo?’. La domanda è: ‘lo farò davvero ogni mese, ogni trimestre, ogni volta che il sito cambia significativamente?’ Se la risposta onesta è ‘probabilmente no’, il costo di delegarlo è inferiore al costo del primo problema che si presenterà senza una protezione adeguata.
Se vuoi la certezza che il sistema di backup del tuo sito sia configurato correttamente — non l'impressione — contattami per una verifica. Analizzo la situazione attuale e imposto una gestione che funziona anche quando non ci pensi.
In sintesi
Un backup sito WordPress completo è un sistema con tre componenti che devono funzionare insieme: file del sito, database e destinazione remota indipendente dall’hosting. A questi si aggiunge una retention policy calibrata sul tipo di sito — abbastanza lunga da coprire problemi che si manifestano in ritardo, non solo guasti improvvisi.
Il backup dell’hosting è un punto di partenza, non una protezione completa. Le copie salvate sullo stesso sistema del sito non ti proteggono nei casi in cui il sistema stesso è il problema.
Gestire correttamente un sistema di backup richiede quattro attività nel tempo: configurazione iniziale, verifica mensile, test del ripristino ogni trimestre, aggiornamento della strategia quando il sito cambia. Chi fa tutte e quattro ha una protezione reale. Chi ne fa una o due ha una protezione parziale che sembra completa — finché non serve.
La domanda non è se vale la pena averlo. È se quello che hai ora è davvero completo.
Domande frequenti (FAQ) riguardo i backup del sito WordPress
Quanto costa ripristinare un sito WordPress compromesso senza backup?
Dipende completamente dal sito. Un sito vetrina con poche pagine è un problema gestibile. Un e-commerce con anni di ordini, dati clienti, schede prodotto e recensioni accumulate è un’altra storia — parte di quei dati potrebbe essere semplicemente irrecuperabile. Non esiste un prezzo per qualcosa che non torna. Il database degli ordini degli ultimi tre anni non si ricostruisce.
Il backup automatico del mio hosting è sufficiente?
Dipende da cosa vuoi che copra. Il backup dell’hosting funziona bene per i problemi più comuni — un aggiornamento che rompe il sito, un errore umano, un file cancellato per sbaglio. Non è sufficiente come unica protezione perché è sullo stesso sistema del sito: se l’account hosting viene compromesso, il backup è compromesso con lui. La protezione corretta prevede sempre una copia su destinazione esterna e indipendente dall’hosting, che si aggiunge al backup dell’hosting senza sostituirlo.
Ogni quanto fare il backup di un sito WordPress attivo?
Dipende dal tipo di sito. Per un sito vetrina che cambia raramente, un backup settimanale con destinazione remota è sufficiente. Per un e-commerce con transazioni quotidiane, il backup dei file dovrebbe essere giornaliero e il database dovrebbe essere salvato ogni 6 ore o in tempo reale. La regola pratica: la frequenza del backup deve essere proporzionale alla quantità di dati che sei disposto a perdere in caso di ripristino.
Cosa succede se ho solo il backup dei file senza il database?
Puoi ripristinare la struttura del sito — il tema, i plugin, le immagini caricate — ma il sito sarà completamente vuoto. Nessuna pagina, nessun articolo, nessun prodotto WooCommerce, nessun utente registrato. Tutto il contenuto di WordPress è nel database, non nei file. Viceversa, se hai solo il database senza i file, hai i contenuti ma non hai niente da mostrare. Un backup completo deve includere entrambi, dello stesso momento, per garantire un ripristino coerente.
Come faccio a sapere se il mio backup funziona davvero?
L’unico modo per saperlo con certezza è testarlo. Verificare che il backup esista e che abbia una dimensione ragionevole è il minimo — non basta. La verifica completa prevede di scaricare il backup e ripristinarlo su un ambiente separato, poi controllare che il sito funzioni correttamente. Un backup mai testato è un’assunzione: sai che esiste, non sai se funziona. Il test va fatto almeno una volta ogni tre mesi, e ogni volta che il sito cambia significativamente.