Parto da una domanda semplice: hai un backup del tuo sito web?
Non «credo di sì». Non «forse il provider lo fa». Non «il tecnico dovrebbe averlo». Intendo: se domani il sito sparisce, viene hackerato, si rompe dopo un aggiornamento o qualcuno cancella una cartella, tu sai da dove ripartire?
Se la risposta è no, male male. Non per spaventarti, ma perché un sito senza backup è come una casa senza chiavi di riserva: finché va tutto bene non ci pensi, poi basta una porta chiusa male e inizi a sudare.
Vediamo i modi più comuni per fare backup di un sito, dal più semplice al più tecnico. Spoiler: averne uno è il minimo. Averne almeno due è molto più sensato di quanto sembri.
Prima regola: backup non significa solo “ho una copia”
Un backup utile deve avere tre caratteristiche:
- Deve essere completo: file + database, non solo una cartella zip a caso.
- Deve essere raggiungibile: se il server muore, non può stare solo sullo stesso server.
- Deve essere ripristinabile: se non hai mai provato a rimetterlo online, è una promessa, non una certezza.
Il punto più dimenticato è il terzo. Tantissimi hanno un file chiamato backup.zip. Pochi sanno se quel file funziona davvero.
1. Backup del provider
Molti hosting offrono backup automatici: giornalieri, settimanali, a volte mensili. In caso di disastro apri ticket, chiami l’assistenza o premi un pulsante nel pannello, e loro ripristinano il sito.
Pro: è comodo. Non devi installare nulla, non devi ricordarti procedure strane, spesso è incluso nel piano hosting o costa poco. Per chi non è tecnico è una rete di sicurezza importante.
Contro: non lo controlli tu. Devi fidarti di frequenza, conservazione e qualità del backup. Inoltre spesso il backup sta nello stesso ecosistema del provider: se il problema riguarda l’account, il pannello, lo spazio hosting o un errore lato infrastruttura, potresti avere meno margine di quanto pensi.
Io lo attivo quasi sempre, ma lo considero ultima spiaggia. Non il mio unico paracadute.
2. Clone del sito in locale sul tuo PC
Questa, per me, è una delle soluzioni migliori: hai una copia del sito sul computer, con file e database, pronta per essere aperta in locale con strumenti come XAMPP, Local WP, Laragon o simili.
Il vantaggio non è solo il backup. È che quel clone può diventare anche un ambiente di prova: aggiorni plugin, cambi tema, modifichi pagine, fai esperimenti. Se rompi qualcosa, lo rompi sul tuo PC, non sul sito pubblico.
Ne ho parlato in modo più specifico nell’articolo su sito staging e clone WordPress: staging e backup non sono la stessa cosa, ma un clone locale fatto bene può servire a entrambe le cose.
Pro: controllo totale, nessun costo ricorrente, copia fisica fuori dal server. Puoi lavorare senza browser e senza paura di mandare offline il sito live.
Contro: devi saperlo creare e aggiornare. Se il clone locale è vecchio di due anni, non è un backup: è un reperto archeologico.
3. Plugin di backup
È il metodo più semplice per chi usa WordPress. Installi un plugin, clicchi “esporta” e ottieni un file unico con tutto il sito: database, media, temi, plugin. Io spesso uso All-in-One WP Migration, ma esistono anche Duplicator, UpdraftPlus e altri.
Pro: è facile. Anche chi non sa usare FTP o database può creare una copia del sito. Per molti siti vetrina è la prima soluzione concreta da attivare.
Contro: occhio al ripristino. Molti plugin esportano gratis, ma per importare file grandi chiedono una versione a pagamento o un’estensione. E se il sito è già rotto e non riesci nemmeno ad accedere a WordPress, il plugin potrebbe non bastare.
Altro errore comune: installare due o tre plugin di backup e pensare di essere al sicuro. Due plugin non sono automaticamente doppia sicurezza se salvano tutto nello stesso posto e nessuno prova mai il restore.
4. Repository GitHub o GitLab
Questa è la strada degli sviluppatori: il codice del sito viene versionato in un repository, per esempio su GitHub. Ogni modifica ha una storia, puoi tornare indietro, confrontare differenze, ripristinare file cancellati.
Pro: è potentissimo per codice, temi custom, configurazioni e progetti moderni. Ti dice cosa è cambiato, quando e perché. Per siti che sviluppo io è normale avere almeno il tema o il progetto in repository.
Contro: Git non è immediato. Molti non sanno nemmeno cosa sia, e va bene così: non tutti devono diventare sviluppatori. Soprattutto: GitHub non basta da solo per un sito WordPress, perché nel repository di solito non metti database, upload, password, file sensibili e contenuti caricati dal pannello.
Quindi sì: GitHub è un ottimo pezzo del backup, ma non è “il backup del sito” se manca tutto il resto.
5. Backup manuale: file + database
Questo è il metodo meno elegante, ma molto solido se sai cosa stai facendo. Scarichi i file via FTP/SFTP o dal file manager dell’hosting, poi esporti il database da phpMyAdmin o dal pannello del provider.
Nel caso WordPress, i due pezzi minimi sono:
- file del sito, soprattutto
wp-content(tema, plugin, immagini); - database, cioè articoli, pagine, impostazioni, utenti, menu, opzioni.
Pro: non dipendi da plugin. Se WordPress non si apre più, puoi comunque recuperare dal pannello hosting.
Contro: è facile dimenticare un pezzo. Avere solo i file senza database significa perdere contenuti e impostazioni. Avere solo il database senza media e tema significa avere una testa senza corpo.
6. Backup esterno in cloud
Un’altra strada è salvare le copie fuori dall’hosting: Google Drive, Dropbox, OneDrive, S3, Backblaze, o servizi simili. Alcuni plugin permettono di inviare automaticamente il backup lì.
Pro: se il provider ha problemi, il backup resta fuori casa. È una delle idee dietro la regola 3-2-1: tre copie, su due supporti diversi, una fuori sede.
Contro: devi gestire spazio, privacy, permessi e rotazione dei file. Se il backup contiene dati personali, non è un file qualunque da lasciare in giro senza pensarci.
La combinazione che consiglio
Se vuoi una risposta pratica, non partire da “qual è il backup migliore?”. Parti da: quali due backup posso mantenere senza impazzire?
Per un sito WordPress normale, una combinazione sensata è:
- Backup del provider attivo, da usare come ultima spiaggia.
- Backup plugin o clone locale aggiornato prima di ogni modifica importante.
- Repository Git se c’è codice custom o se il sito viene sviluppato sul serio.
Io, per esempio, attivo sempre il backup del provider ma non lo considero sufficiente. I miei siti sono clonati in locale; alcuni hanno anche repository online. Nel caso di uomodicasa.it ho tre livelli: provider, clone locale, repository.
Esagerato? No. Mi è capitato di vedere backup del provider corrotti esattamente come il sito. Può succedere: se il backup automatico viene fatto quando il sito è già compromesso o rotto, il backup conserva il problema invece di risolverlo.
Il test che nessuno fa: provare il ripristino
La domanda vera non è “hai un backup?”. La domanda è: hai mai provato a ripristinarlo?
Non serve farlo ogni settimana, ma almeno una volta dovresti verificare:
- il file si apre?
- il database si importa?
- le immagini ci sono?
- il sito parte in locale o in staging?
- login, form e pagine principali funzionano?
Un backup non testato è come un estintore ancora nella plastica: magari funziona, magari no. Lo scopri nel momento peggiore.
Quando fare un backup
Minimo sindacale:
- prima di aggiornare WordPress, tema o plugin;
- prima di installare un nuovo plugin importante;
- prima di cambiare tema o builder;
- prima di migrare hosting o dominio;
- prima di mettere mano a database, funzioni PHP o file del tema.
Se il sito porta clienti, preventivi o vendite, il backup non è una pignoleria tecnica. È assicurazione operativa.
In sintesi
- Un backup solo è meglio di niente, ma non è il massimo.
- Provider + clone locale è già una buona base.
- I plugin sono comodi, ma controlla bene il ripristino.
- GitHub salva il codice, non automaticamente tutto il sito WordPress.
- Il backup va testato, altrimenti è solo una speranza con estensione
.zip.
Non sai se il tuo sito ha un backup vero o vuoi capire come clonarlo in locale senza fare danni? Scrivimi: prima di rompere qualcosa, due controlli fatti bene costano meno di un ripristino disperato.