Il backup sito web è la voce che quasi tutte le aziende danno per risolta e quasi nessuna verifica. C'è una casella spuntata nel pannello dell'hosting, un plugin che gira di notte, una cartella che si riempie. Poi arriva il giorno del ripristino e la copia c'era, ma non serviva a niente: incompleta, troppo vecchia, cifrata insieme al resto o semplicemente illeggibile.
Il punto è che un backup non è una copia: è un tempo di ripristino misurato. Finché quel tempo non lo hai cronometrato almeno una volta, stai comprando tranquillità, non continuità.
Backup sito web: la fiducia non coincide con i numeri
La distanza tra "abbiamo i backup" e "siamo tornati online" è documentata. Il rapporto Veeam sulla resilienza dei dati pubblicato ad aprile 2026, su oltre 900 responsabili IT, sicurezza e rischio, racconta due storie opposte: il 90% si dichiara sicuro di riuscire a recuperare entro i tempi previsti, ma tra chi ha subito davvero un attacco solo il 28% ha recuperato tutti i dati colpiti. Il 44% ne ha recuperato meno di tre quarti. La media si ferma al 72%.
Un'analisi di sinistri assicurativi su 186 casi di ransomware aggiunge il dettaglio decisivo: il 92% delle aziende colpite aveva una soluzione di backup e il 31% non è comunque riuscito a ripristinare. Chi non ci riesce paga in media 190.000 dollari in più; chi ci riesce ha quasi tre volte meno probabilità di pagare un riscatto.
Gli ordini di grandezza sono quelli delle grandi organizzazioni, d'accordo. Il meccanismo però è identico sul backup sito web di una PMI: la copia esiste, il ripristino no. E lì il danno non si misura in milioni ma in giorni di sito fermo, ordini persi e clienti che nel frattempo hanno scritto a qualcun altro.
Che cosa deve contenere davvero una copia utile
Il primo errore è copiare solo metà del sito. La documentazione ufficiale di WordPress è esplicita: servono il database e i file, perché il database "vive fuori" dalla cartella del sito e scaricare la directory non lo porta con sé. Vale per qualsiasi CMS: i contenuti stanno da una parte, il codice e i media dall'altra.
Una copia che ti rimette davvero online contiene cinque cose:
- Il database — contenuti, ordini, utenti, configurazioni del CMS.
- I file — tema, plugin o codice applicativo, e soprattutto la cartella dei media caricati.
- Le configurazioni — file di connessione, regole del server web, variabili d'ambiente.
- Le credenziali e i servizi collegati — chiavi API, account SMTP, gateway di pagamento: senza, il sito torna su ma non spedisce e non incassa.
- Le istruzioni per rimontarlo — versione di PHP, estensioni richieste, dove puntano i DNS. Sono le venti righe che trasformano un ripristino di due giorni in uno di due ore.
Sulla frequenza la stessa documentazione suggerisce una copia settimanale per un sito tranquillo e una giornaliera per uno attivo, tenendo tre-cinque copie recenti in posti diversi: una sul server, una su uno spazio cloud, una scaricata in locale.
Due numeri da decidere prima: quanto puoi perdere, quanto puoi stare fermo
Prima di scegliere uno strumento vanno decisi due numeri, in italiano semplice. Il primo: quanti dati puoi perdere. Se il backup è notturno e il guasto arriva alle 18, hai perso una giornata di moduli di contatto e di ordini. Per un sito istituzionale è irrilevante, per un e-commerce è un problema serio.
Il secondo: quante ore puoi stare offline. Otto ore di fermo su un sito vetrina si assorbono, otto ore su un portale di prenotazioni no. Da questi due numeri discende tutto il resto — frequenza, tecnologia, costo — e non il contrario. Inoltre li decide l'imprenditore, non il tecnico: sono una scelta di rischio, non di configurazione.
Scriverli nero su bianco rende subito visibile quando la soluzione in uso non è all'altezza della promessa. Un backup settimanale su un negozio che fattura ogni giorno non è una svista tecnica: è una decisione implicita che nessuno ha mai preso consapevolmente.
Perché il backup dell'hosting da solo non basta
Quasi tutti gli hosting includono un backup sito web automatico. È utile e va tenuto, ma ha un limite strutturale: vive nello stesso perimetro del sito. Se il problema è l'account compromesso, il fornitore che ha un disservizio o una cancellazione fatta con le credenziali giuste, la copia sparisce insieme all'originale.
Non è un'ipotesi teorica. La guida #StopRansomware della CISA raccomanda di mantenere backup "offline, cifrati" proprio perché "molte varianti di ransomware cercano e poi cancellano o cifrano i backup accessibili". Tradotto: una copia raggiungibile dalle stesse credenziali che gestiscono il sito è una copia a rischio. Le rilevazioni di settore del 2026 confermano che gli archivi di backup sono ormai un bersaglio primario, non un ripiego sicuro.
La contromisura è vecchia e continua a funzionare: almeno una copia fuori dall'infrastruttura del sito, su un account separato con credenziali proprie, possibilmente immutabile — cioè non cancellabile per un certo numero di giorni nemmeno da chi ha i permessi di amministratore. È lo stesso principio di riduzione della superficie di attacco di cui parlavamo a proposito della sicurezza di WordPress e dei plugin: meno cose condividono lo stesso destino, meglio è.
La prova di ripristino: come si fa in un pomeriggio
Qui sta la parte che quasi nessuno esegue. La CISA la mette tra le raccomandazioni operative: "testare regolarmente la disponibilità e l'integrità dei backup in uno scenario di ripristino". Non "controllare che il file esista": rimetterlo davvero in piedi.
Per un sito aziendale bastano poche ore, una volta all'anno o dopo ogni cambiamento importante:
- Prendi la copia più recente e portala su un ambiente separato — un sottodominio di prova, un server temporaneo, una macchina locale. Mai in produzione.
- Fai partire il cronometro. Il numero che conta non è "ha funzionato", è "in quante ore".
- Rimonta tutto partendo solo da quello che il backup contiene, senza attingere al sito vivo: è così che scopri cosa manca.
- Prova i percorsi che fanno girare i soldi: pagina prodotto, carrello, modulo di contatto, invio email, area riservata. Un sito che carica ma non manda un'email è fermo comunque.
- Scrivi mezza pagina di verbale: data, tempo impiegato, cosa mancava, cosa correggere. È l'unico documento che rende la promessa verificabile l'anno dopo.
Quasi sempre la prima prova riserva una sorpresa: una cartella di media esclusa per risparmiare spazio, una chiave API che era solo nella testa di chi ha fatto il sito, una versione di PHP che non esiste più. Meglio scoprirlo di martedì pomeriggio che di sabato notte.
Lo stesso vale per agenti e automazioni
Chi lavora con agenti AI e automazioni si porta dietro lo stesso problema, spostato di un livello. Di un agente non si salva "il modello": si salvano le istruzioni, le configurazioni, le chiavi e gli account dedicati, il set di prova con cui ne misuri la qualità e i registri delle azioni. È materiale che vale mesi di lavoro e che spesso vive in un unico posto.
Noi di Studiollice lo trattiamo come parte della manutenzione ordinaria di un'automazione, non come un extra: se un'automazione va rimontata da zero e nessuno sa più con quali istruzioni girava, il ripristino non è un'operazione tecnica, è una ricostruzione. Infine, vale la pena ricordare che la domanda da fare a chi gestisce il tuo sito non è "fate i backup?" — la risposta è sempre sì. È "quando è stata l'ultima volta che avete ripristinato questo sito, e quanto ci è voluto?". Se non c'è una data, non c'è un backup: c'è un file.
Studiollice progetta siti, agenti AI e automazioni su misura, e mette la prova di ripristino nel piano di manutenzione fin dal primo giorno. Se non sai rispondere a quella domanda sul tuo sito, è il momento giusto per provarci.