Come fare il backup di un sito web (e ripristinarlo)
Come fare il backup di un sito web: cosa salvare davvero, la regola 3-2-1, ogni quanto farlo e perché un backup mai testato non è un backup.
Il backup è quella cosa a cui nessuno pensa finché non serve, e nel momento in cui serve è troppo tardi per organizzarlo. Un aggiornamento andato male, un attacco, una cancellazione per errore, un hosting che chiude: sono tutti scenari ordinari, non catastrofi improbabili. In questo articolo trovi cosa salvare davvero, come, e la verifica che quasi nessuno fa.
Cosa salvare
Un sito è fatto di due cose separate, e servono entrambe: i file e il database. Un backup che contiene solo uno dei due non permette di ripristinare nulla.
È l'errore più comune: si scaricano i file via FTP e ci si sente al sicuro. Ma su WordPress, su un e-commerce o su qualunque sito dinamico, i contenuti stanno nel database — articoli, prodotti, ordini, utenti. Senza quello hai un sito vuoto.
L'elenco completo di cosa serve:
I file. Il codice, i temi, i plugin, e soprattutto i contenuti caricati — immagini, PDF, allegati. Su un sito di anni questa è la parte più insostituibile.
Il database. Tutto il contenuto dinamico.
I file di configurazione. Le impostazioni di connessione, le variabili d'ambiente, le regole del server. Piccoli ma fondamentali per far ripartire tutto.
Le informazioni di accesso, custodite a parte: registrar del dominio, hosting, certificati, servizi collegati. In un'emergenza servono subito, e spesso sono l'unica cosa che manca.
Cosa NON serve salvare: la cache, i file temporanei, e le dipendenze installate (quelle si reinstallano da un elenco, non vanno archiviate).
Ogni quanto
Dipende da quanto spesso cambia il sito, e il criterio è semplice: quanto lavoro sei disposto a perdere?
| Tipo di sito | Frequenza |
|---|---|
| Sito vetrina che cambia raramente | Settimanale |
| Blog con pubblicazioni regolari | Giornaliera |
| E-commerce con ordini | Giornaliera o più frequente |
| Applicazione con dati utenti | Continua o più volte al giorno |
Per un e-commerce il calcolo è concreto: un backup giornaliero significa poter perdere fino a un giorno di ordini. Se sono venti ordini al giorno, valuta se puoi permettertelo.
E in ogni caso: un backup manuale prima di ogni modifica importante — aggiornamento della piattaforma, installazione di un plugin, modifica al database. È il momento in cui le cose si rompono davvero.
La regola 3-2-1
È lo standard di riferimento, ed è semplice da ricordare:
- 3 copie dei dati (l'originale più due backup)
- 2 supporti diversi
- 1 copia in un luogo separato
Il punto centrale è l'ultimo. Un backup che sta sullo stesso server del sito non protegge da: server compromesso, account sospeso, hosting che chiude, disco guasto.
Il backup del tuo hosting non basta da solo. Molti provider ne offrono uno incluso, ed è utile — ma se il problema è l'account bloccato o una controversia con il provider, non hai accesso nemmeno ai backup. Serve almeno una copia che controlli tu, su un servizio diverso.
Come farlo
Dal più semplice al più strutturato:
Il pannello dell'hosting. Quasi tutti offrono backup automatici o su richiesta. Il modo più immediato per iniziare — con l'avvertenza sopra: non è sufficiente da solo. Vale la pena verificare cosa include il tuo piano: le politiche variano parecchio, come racconto in migliori hosting in Italia.
Plugin, se usi WordPress. Diverse estensioni gestiscono file e database insieme, con invio automatico su uno spazio cloud esterno. La configurazione richiede dieci minuti ed è la soluzione più pratica per la maggior parte dei siti.
Script personalizzato. Su un VPS, uno script che esporta il database e comprime i file, lanciato da un cron job:
#!/bin/bash
DATA=$(date +%Y-%m-%d)
mysqldump -u utente -p'password' nome_db > /backup/db-$DATA.sql
tar -czf /backup/file-$DATA.tar.gz /var/www/sito
# poi sincronizza /backup su uno spazio esterno
Un'avvertenza importante: in uno script reale le credenziali non vanno scritte nel file. Vanno in un file di configurazione con permessi ristretti, altrimenti chiunque acceda al server le legge.
Servizi di backup gestiti. Si occupano di tutto, con conservazione su più giorni e ripristino con un clic.
Git per il codice. Se il sito è in un repository, il codice è già versionato — ma Git non è un backup dei contenuti: non contiene database né file caricati dagli utenti.
La verifica che quasi nessuno fa
Questo è il punto più importante dell'articolo.
Un backup mai ripristinato non è un backup: è un file di cui speri qualcosa.
Le cose che si scoprono solo provando: l'archivio è corrotto, il database esportato è incompleto, mancava una cartella, il processo automatico ha smesso di funzionare tre mesi fa, il file è protetto da una password che nessuno ricorda.
Prova un ripristino completo almeno una volta, su un ambiente di prova o in locale. E ripetilo periodicamente — ogni sei mesi è ragionevole.
Durante la prova, misura anche quanto tempo ci vuole. Sapere che il ripristino richiede due ore è un'informazione che serve prima dell'emergenza, non durante.
La conservazione
Non tenere solo l'ultima copia: alcuni problemi si scoprono in ritardo.
Un sito compromesso o un database corrotto possono passare inosservati per settimane. Se hai solo il backup di ieri, stai ripristinando il problema.
Uno schema che funziona: gli ultimi 7 giorni, più le ultime 4 settimane, più gli ultimi 6 mesi. Occupa poco più spazio e copre anche i disastri scoperti tardi.
Occhio anche ai dati personali: un backup contiene dati di clienti e utenti. Va conservato in modo sicuro e non tenuto all'infinito — vale il principio di limitazione della conservazione del GDPR.
Una checklist
- Salvo sia i file sia il database
- Almeno una copia è fuori dall'hosting del sito
- Il backup è automatico, non affidato alla mia memoria
- Ricevo una notifica se fallisce
- Conservo più versioni, non solo l'ultima
- Ho provato un ripristino completo almeno una volta
- So quanto tempo richiede il ripristino
- Le credenziali di accesso ai servizi sono custodite a parte
- I backup sono protetti, non pubblicamente accessibili
L'ultimo punto merita attenzione: un archivio di backup lasciato in una cartella raggiungibile dal web è una fuga di dati completa servita a chiunque indovini il nome del file.
In sintesi
Un backup completo comprende file e database insieme, più le configurazioni e le credenziali custodite a parte. Salvare solo i file è l'errore più diffuso e rende il backup inutile su qualunque sito dinamico.
La frequenza si decide chiedendosi quanto lavoro puoi permetterti di perdere, e vale sempre la regola di farne uno prima di ogni modifica importante.
La regola 3-2-1 si riassume in un punto: almeno una copia deve stare fuori dall'hosting del sito, perché il backup del provider non ti protegge dai problemi che riguardano il provider stesso.
E la cosa che fa davvero la differenza: prova un ripristino. Finché non l'hai fatto, non sai se hai un backup — sai solo di avere dei file.
Se gestisci un sito che porta clienti e vuoi impostare bene backup e sicurezza, la consulenza tecnica parte esattamente da questo tipo di verifiche.
Contenuto redatto con l'assistenza di strumenti di intelligenza artificiale e rivisto dalla redazione di Codegrind, che ne è responsabile. Hai trovato un errore? Scrivici.