Un backup sito web non è un file copiato nella stessa cartella del sito. È una copia da cui puoi ripartire se pagine, database o media si corrompono, vengono cifrati o cancellati. Senza una copia provata, "abbiamo il backup" è una frase, non un piano. Questa guida serve a un titolare o a un responsabile IT di PMI che deve decidere cosa comprare e cosa mettere per iscritto nel contratto.
Non tratta le prime ore di un attacco: quello sta nella guida su cosa fare se il sito è stato hackerato. Qui si parla di copie, restore e responsabilità. I segnali che il sito è compromesso senza rumore stanno in sito compromesso senza saperlo.
Per chi è utile (e per chi no)
È utile se hai un sito aziendale o un ecommerce, paghi un canone o un hosting, e non sai se esiste una copia da cui ripartire. Il lettore tipo sta rinnovando un contratto, cambiando fornitore, o ha sentito "backup incluso" senza dettagli.
Non è la guida giusta se cerchi uno script da lanciare stasera su un server che amministri da solo: qui non c'è un tutorial di comandi. Non lo è neanche se il problema è un incidente in corso: torna alla guida sulle prime ore. Non sostituisce una policy di continuità per un gruppo con data center propri: lì servono procedure e ruoli che un articolo non scrive.
Cosa è un backup sito web, in pratica
Un backup sito web è una copia usabile di ciò che fa funzionare il sito: file (tema, media, configurazioni), database (contenuti, utenti, ordini), e quanto serve a rialzarlo. Una cartella di immagini senza il database non è un sito. Un dump del database senza i media lascia le schede vuote.
Due misure, da chiedere, non da inventare:
RPO (obiettivo di punto di ripristino): quanta storia puoi perdere. Se l'ultima copia è di ieri sera e questa mattina hai preso dieci ordini, quei dieci non ci sono.
RTO (obiettivo di tempo di ripristino): quanto può restare spento il sito mentre qualcuno ripristina. Non è lo stesso numero del RPO.
Non sono standard di legge universali. Sono accordi. Se il fornitore non li scrive, non esistono.
Perché una copia sullo stesso server non basta
Il NCSC, nella guida su come mitigare malware e ransomware (consultata il 14 settembre 2026), mette i backup regolari come prima azione: copie aggiornate dei file importanti, test di restore, copie offline o comunque separate dalla rete di produzione. Motivo dichiarato: il ransomware prende di mira anche le copie collegate, per rendere più probabile il pagamento. La stessa guida chiede di non lasciare dischi di backup sempre attaccati alla rete, di proteggere le versioni precedenti in cloud, di analizzare le copie prima di ripristinare, e di aggiornare i prodotti usati per il backup.
CISA, sul portale StopRansomware, formula lo stesso punto in una riga: copie offline, cifrate, e test regolari. Non è una classifica di fornitori. È il perimetro minimo da verificare.
Una copia che vive nella stessa macchina del sito può sparire con il sito. Una copia che si sincronizza in tempo reale sul cloud può copiare anche i file già cifrati. Per questo "abbiamo il backup in cloud" senza versioni precedenti e senza un test non chiude la domanda.
Le sette domande da fare al fornitore
Da ottenere per iscritto. Se la risposta è "ci pensiamo noi", chiedi il come.
Cosa viene copiato? File, database, media, mail, certificati, configurazioni. Elenco, non slogan.
Ogni quanto, e quante copie si tengono? Frequenza e retention. Un dump al mese su un ecommerce quotidiano è un buco, non un piano.
Dove sta la copia? Stesso server, altro disco, altro datacenter, cloud, offline. Quanti luoghi distinti.
Chi può cancellarla o cifrarla? Stessi account di amministrazione del sito, o accessi separati, con autenticazione a più fattori.
Quando è stato fatto l'ultimo restore di prova? Data, perimetro, esito, durata. Senza questa riga, la copia non è dimostrata.
Cosa succede se la copia è infetta? Si analizza prima del restore? Su quale ambiente? Il NCSC lo indica esplicitamente: la compromissione può essere precedente alla scoperta.
Chi paga il tempo di ripristino, e in quante ore? Incluso nel canone, extra, fascia oraria. Non è un dettaglio: è il costo vero dell'incidente.
Tre scenari, con ipotesi esplicite
Non sono medie di mercato. Servono a non comprare lo stesso prodotto per tre problemi diversi.
Vetrina aggiornata di rado, pochi form. Una copia completa a cadenza definita, più una copia offline o su un altro account, più un restore di prova almeno quando cambiate fornitore o piattaforma, può essere sufficiente. Il rischio è un deface o un file caricato male, non cento ordini persi.
Sito con blog, lead, appuntamenti. Serve una frequenza allineata a quanto cambiano i dati, versioni precedenti, e un restore provato su database più file. Se gli appuntamenti vivono solo sul sito, la copia è anche la vostra agenda.
Ecommerce o catalogo che si muove ogni giorno. Qui RPO e RTO vanno scritti. Una copia notturna perde la giornata. Un channel manager o un gestionale esterno, se c'è, ha le sue copie: il sito non deve essere l'unica fonte di verità sugli ordini. Se lo è, il backup del sito è il backup dell'azienda.
Copia locale, hosting, servizio dedicato
Non è una classifica. È un perimetro, simmetrico.
| Modo | A cosa serve | Limite tipico | Quando ha senso |
| Copia sullo stesso hosting | Ripartire da un errore tuo, un plugin, un file cancellato | Sparisce con il server se l'attacco arriva lì | Come strato extra, non come unica copia |
| Copia del fornitore / snapshot | Ripartire se lo gestisce chi tiene acceso il sito | Scope e tempi spesso impliciti; va chiesto il test | Canone gestito, se frequenza e restore sono scritti |
| Servizio di backup dedicato | Copie separate, versioni, a volte immutabilità | Costo e integrazione; va aggiornato anche lui | Dati che non potete perdere, o obblighi di settore |
Quando un CMS gestito non è la scelta giusta
KeideaCMS è un CMS proprietario gestito. Sulla pagina sicurezza dichiara WAF nativo, cifratura AES-256 dei form, 2FA e scansione file. Non dichiara, al 14 settembre 2026, frequenza di backup, retention, cifratura delle copie, test di restore, RPO o RTO. Quindi non è, da quella documentazione, un prodotto di backup enterprise.
Se vi serve un RPO di minuti, copie immutabili a norma di un settore regolato, o un piano di disaster recovery con esercitazioni periodiche, vi serve prima un disegno di continuità (e spesso un fornitore di backup dedicato), non solo un CMS. Se amministrate voi i server, un CMS gestito aggiunge un perimetro che non controllate: va bene solo se accettate quel modello.
In quei casi comprare "il sito" sperando che risolva il restore è il prodotto sbagliato. Meglio dirlo prima della firma.
Cosa dichiara oggi KeideaCMS
Su KeideaCMS la sicurezza dichiarata oggi è quella della pagina sicurezza: WAF nel core, form cifrati, 2FA TOTP, scansione degli upload. Hosting, manutenzione e supporto sono nel canone dei piani. Il confronto con altre strade è nella pagina di confronto.
Il backup, in assenza di una scheda pubblica con frequenza e test, va chiesto nel preventivo come a qualunque altro fornitore: le sette domande di sopra. Non promettiamo che "con noi non serve". Non usiamo l'assenza di un CVE pubblico come prova che non serva una copia. La piattaforma sta sui nostri server: restano vostri dominio, contenuti e dati esportabili, non il codice del software.
Se il sito è già sotto attacco, non partite da qui: partite dalla guida su sito web hackerato, cosa fare. Il quadro "chi tiene accesa la sicurezza nel tempo" è in sicurezza gestita del sito web.
KeideaCMS
Vuoi un elenco scritto di cosa è coperto (backup incluso o escluso) sul tuo sito attuale?
Audit di sicurezza, perimetro e limiti → Contatti
Checklist prima di firmare
Elenco di cosa viene copiato: file, database, media, configurazioni.
Frequenza, retention, e dove stanno le copie (quanti luoghi distinti).
Almeno una copia non vive sullo stesso server del sito.
Data dell'ultimo restore di prova, con esito e durata.
Accessi alle copie separati da quelli del sito, con autenticazione a più fattori se dichiarata.
Cosa si fa se la copia è infetta, prima di rialzare il sito.
Chi paga il ripristino, in quali orari, in quante ore.
Niente "backup incluso" senza i numeri di sopra.
Collegamento scritto con la procedura incidente, non un unico "ci pensiamo noi".
Un backup sito web è una copia da cui avete già ripristinato almeno una volta, in prova. Tutto il resto è una dichiarazione. Il passo successivo, se volete un perimetro sul sito attuale, è un audit con limiti espliciti: non è una certificazione e non è un "sito sicuro".
