Indice dell'articolo
Il backup che non serve a niente
Quasi tutti i siti hanno un backup. Quasi nessuno sa a che data risale, dove si trova e se si apre. Sono tre domande banali, e finché il sito funziona nessuno se le pone: il backup è una voce nel pannello dell'hosting, una casella spuntata, una cosa di cui si occupa qualcun altro.
Poi arriva il giorno storto. Un aggiornamento che rompe il tema, un plugin che cancella mezza tabella, un attacco che riscrive le pagine, un collaboratore che elimina la cartella sbagliata. È in quel momento che la parola backup smette di essere rassicurante e diventa una domanda precisa: quanto indietro mi riporta?
La risposta, troppo spesso, è deludente. La copia c'è ma è di sei giorni fa, e in mezzo ci sono quattro ordini e due articoli. Oppure c'è ma contiene solo i file e non il database, quindi il sito torna su vuoto. Oppure c'è, è completa, e non si apre: l'archivio era corrotto da mesi e nessuno se n'era accorto, perché nessuno l'aveva mai aperto.
Un backup vale quanto l'ultima volta che è stato provato. Tutto il resto — la frequenza, lo spazio occupato, il nome del servizio — viene dopo.
Le tre cose da salvare
Un sito non è un file solo, e questa è la ragione per cui tanti backup risultano inutili al momento del bisogno. Le parti da salvare sono tre e servono tutte e tre insieme.
I file. Il tema, i plugin o i moduli, le immagini e i documenti caricati nel tempo, i fogli di stile. È la parte più voluminosa e quella che si recupera più facilmente, perché buona parte è ricostruibile: un plugin si reinstalla. Le immagini caricate, no.
Il database. Qui vivono pagine, articoli, prodotti, ordini, utenti, commenti, impostazioni. È la parte piccola per dimensione e insostituibile per valore: perderlo significa perdere il contenuto, non l'aspetto. Un sito con i file e senza database è un negozio con gli scaffali e senza merce.
La configurazione. La versione di PHP, i certificati, le regole di riscrittura degli indirizzi, le caselle di posta, i record del DNS. Non sta dentro il sito e quasi mai dentro il backup, ma senza quella un ripristino lascia un sito che gira male, con indirizzi che non rispondono e moduli che non spediscono.
Ogni quanto, davvero
La frequenza giusta non si decide guardando il calendario, ma rispondendo a una domanda scomoda: quanto lavoro sei disposto a rifare? La distanza fra due backup è esattamente quello che perdi nel caso peggiore.
Per un sito vetrina che cambia una volta al mese, una copia a settimana è ragionevole: nel caso peggiore si riscrive una pagina. Per un blog con uscite settimanali serve il backup giornaliero, altrimenti si rischia di perdere l'articolo appena pubblicato e il lavoro che c'è dietro. Per un e-commerce il discorso cambia di natura: lì dentro non ci sono solo contenuti, ci sono ordini di clienti veri, e perderne anche uno solo è un problema con una persona, non con un file. Backup giornaliero come minimo assoluto, più frequente nei periodi di punta.
C'è poi un caso che sfugge a ogni regola: il momento prima di una modifica importante. Un aggiornamento del gestionale, un cambio di tema, l'installazione di un plugin nuovo, una migrazione. Lì il backup va fatto adesso, a mano, prima di toccare qualsiasi cosa — e va verificato che sia andato a buon fine prima di procedere.
Dove tenere le copie
Il backup dell'hosting è comodo e quasi sempre incluso nel piano: va tenuto, è la prima linea. Ma ha due limiti che è bene conoscere prima di scoprirli sul campo.
Il primo è che sta sullo stesso server del sito. Nei casi gravi — un guasto serio, un account sospeso, una compromissione profonda — il problema può portarsi via anche le copie. È il motivo per cui ogni regola sui backup, in qualunque settore, chiede almeno una copia fuori dal sistema che si sta proteggendo.
Il secondo è la finestra temporale. Molti piani conservano gli ultimi sette giorni, a volte trenta. Finché il danno è evidente — il sito non si apre — sette giorni bastano. Ma i danni silenziosi sono i più frequenti: una pagina eliminata per sbaglio, un prezzo modificato male, dei contenuti sovrascritti durante una revisione. Cose che si notano dopo due settimane, quando la copia buona non c'è più.
La regola pratica che funziona è semplice: le copie degli ultimi sette giorni, più una a settimana per un mese e una al mese per un anno, con almeno una di queste conservata in un posto diverso dall'hosting. Occupa poco spazio e copre quasi tutti i casi reali.
La prova che quasi nessuno fa
Questo è il punto in cui la maggior parte dei siti è scoperta, e non per trascuratezza: semplicemente non viene in mente. Un backup che non è mai stato ripristinato non è un backup: è un file di cui si presume il contenuto.
Le cose che si scoprono provando sono sempre le stesse. L'archivio si scarica ma è incompleto, perché il processo andava in timeout da mesi e nessuno leggeva i messaggi d'errore. Il database è stato copiato mentre il sito scriveva, e si ripristina in uno stato incoerente. Mancano le immagini, perché la cartella dei caricamenti era esclusa da una regola scritta anni prima. Il backup c'è ma è di un altro sito.
La prova si fa così: si prende la copia più recente, si ripristina su un sito di prova — un sottodominio, un ambiente locale, uno spazio temporaneo — e lo si guarda. Si aprono tre o quattro pagine, si controlla che le immagini ci siano, si verifica che il modulo di contatto risponda e che nel pannello ci siano gli ultimi contenuti pubblicati. Mezz'ora, una volta ogni sei mesi. È il modo meno costoso che esista per non avere brutte sorprese.
Segna la data dell'ultima prova riuscita dove la rivedi: nel calendario, in un documento condiviso, dove preferisci. Se non sai dire quando è stata l'ultima volta, la risposta onesta è «mai».
Quando il backup non basta
C'è un caso in cui ripristinare non solo non risolve, ma peggiora: il sito compromesso. Se qualcuno è entrato, il codice malevolo è dentro il sito da prima che il problema diventasse visibile — spesso da settimane. Ripristinare la copia di ieri rimette online anche quel codice, e nel giro di poco si torna al punto di partenza.
In quel caso l'ordine delle operazioni è diverso: prima si capisce da dove sono entrati e si chiude la falla, poi si cambiano tutte le password — pannello, database, FTP, utenze del gestionale — e solo dopo si ripristina, scegliendo una copia precedente all'intrusione. Se non si sa quando è avvenuta, bisogna risalire finché il sito non risulta pulito: ed è qui che la regola di conservare copie vecchie di mesi si rivela preziosa.
Ne abbiamo scritto in dettaglio in cosa fare se il sito è stato violato e nei segnali che un sito è compromesso, che spesso compaiono settimane prima del danno evidente.
Cosa chiedere a chi gestisce il sito
Se del sito si occupa qualcun altro — un fornitore, un collaboratore, l'agenzia che lo ha fatto — queste sono le domande da fare, e sono tutte domande a cui si risponde con un dato preciso, non con un «sì, certo».
- A che data risale il backup più recente? La risposta è una data e un'ora, non «è automatico».
- Quante copie sono conservate e per quanto tempo? Sette giorni, trenta, un anno.
- Dove sono fisicamente? Se la risposta è «sul server», manca la copia esterna.
- Comprendono anche il database? Domanda che smaschera metà dei backup inutili.
- Quando è stato provato un ripristino l'ultima volta? È la domanda che conta di più.
- Quanto ci vorrebbe a rimettere online il sito? Un'ora, un giorno, non si sa: cambia tutto.
Se le risposte arrivano chiare, il sito è in buone mani. Se arrivano vaghe, non è detto che ci sia un problema — ma vale la pena verificarlo adesso, mentre tutto funziona, invece che nel giorno in cui l'unica cosa che conta è quanto indietro si può tornare.
Domande frequenti
Ogni quanto va fatto il backup di un sito?
Dipende da quanto spesso cambia. Un sito vetrina che si aggiorna una volta al mese regge con un backup settimanale; un blog con articoli nuovi ogni settimana ne vuole uno al giorno; un e-commerce con ordini e magazzino va salvato ogni giorno come minimo, e nei periodi di punta anche più spesso. La domanda giusta non è «ogni quanto», ma «quanto lavoro sono disposto a rifare se perdo tutto»: quella è la distanza massima fra due backup.
Il backup dell'hosting basta?
È un buon punto di partenza, ma ha due limiti. Primo: sta sullo stesso server del sito, quindi un problema grave dell'hosting può portarsi via anche le copie. Secondo: molti piani conservano gli ultimi sette giorni, e un danno che si scopre dopo due settimane — una pagina cancellata, un plugin che ha corrotto i dati — non è più recuperabile. Serve almeno una copia fuori dal server.
Cosa deve contenere un backup completo?
Tre cose, e servono tutte e tre insieme: i file del sito (tema, plugin, immagini caricate), il database (pagine, articoli, ordini, utenti) e la configurazione del server, cioè la versione di PHP, i certificati e le regole di riscrittura. Un backup dei soli file ricostruisce l'aspetto del sito senza i contenuti; uno del solo database fa il contrario.
Come faccio a sapere se il backup funziona?
Provandolo. Un backup non verificato è una speranza, non una garanzia: capita che il file si scarichi incompleto, che il database sia stato copiato mentre qualcuno scriveva, che l'archivio non si apra. L'unica prova è ripristinarlo su un sito di prova e guardarlo. Una volta ogni sei mesi è sufficiente, e si scopre in mezz'ora quello che altrimenti si scoprirebbe nel giorno peggiore.
Quanto tempo vanno conservati i backup?
Almeno trenta giorni, perché i danni silenziosi — una modifica sbagliata, un contenuto cancellato per errore, un'infezione che resta nascosta — si notano spesso dopo settimane. Una buona regola è tenere le copie degli ultimi sette giorni, più una a settimana per un mese e una al mese per un anno: occupa poco e copre quasi tutti i casi reali.
I backup proteggono da un attacco informatico?
Riducono il danno, non lo evitano. Servono a rimettere online il sito, ma se la falla che ha permesso l'attacco è ancora lì il problema si ripresenta, e ripristinando una copia troppo recente si rimette online anche il codice malevolo. Per questo il ripristino va sempre accompagnato dalla chiusura della falla e dal cambio delle password.