Guida alla policy di conservazione dei backup del sito web
Pubblicato il 10 maggio 2026
Un ripristino che fallisce perché il backup è troppo vecchio è doloroso. Un ripristino che fallisce perché il backup necessario è già stato eliminato è peggio. Questa guida alla policy di conservazione dei backup del sito web è qui per prevenire entrambi i problemi e aiutarti a mantenere una cronologia sufficiente per ripristinare correttamente senza archiviare per sempre mezza internet.
La maggior parte dei problemi con i backup non è causata dal processo di backup stesso. Deriva da decisioni deboli sulla conservazione. I team attivano backup giornalieri, si sentono al sicuro per tre mesi e poi scoprono di aver conservato solo sette copie. Oppure conservano tutto per un anno e pagano per uno spazio di archiviazione che non serve, mentre il ripristino richiede comunque troppo tempo perché nessuno ha pianificato l'uso effettivo del restore.
Cosa controlla realmente una policy di conservazione dei backup
Una policy di conservazione decide per quanto tempo viene mantenuto ogni backup, quanti punti di ripristino esistono e quali copie sono disponibili per diversi scenari di ripristino. Sembra semplice, ma influisce su costi, velocità, conformità, risposta agli incidenti e persino fiducia dei clienti.
Per un sito web aziendale, la conservazione non riguarda solo il ripristino di emergenza dopo un guasto del server. Riguarda anche il recupero da deploy errati, malware, plugin difettosi, eliminazione accidentale di contenuti e corruzione del database iniziata silenziosamente giorni prima. I log stanno raccontando la stessa storia in molti incidenti: il backup esisteva, ma il punto di ripristino utile no.
Per questo frequenza e conservazione devono essere pianificate insieme. Un backup giornaliero conservato per 30 giorni ti offre 30 punti di ripristino. Un backup orario conservato per 48 ore più backup giornalieri conservati per 30 giorni ti offre un recupero rapido a breve termine e una cronologia sufficiente per problemi che si sviluppano più lentamente. Stesso sistema, risultato molto diverso.
Come creare una guida alla policy di conservazione dei backup del sito web adatta al tuo rischio
La policy giusta parte da due domande. Primo: quanti dati puoi permetterti di perdere? Secondo: fino a quanto indietro hai realisticamente bisogno di recuperare?
Se il tuo negozio e-commerce elabora ordini ogni ora, perdere un'intera giornata di dati di solito non è accettabile. Se il tuo sito marketing cambia due volte al mese, snapshot giornaliere possono essere più che sufficienti. Le agenzie che gestiscono più siti di clienti spesso hanno bisogno di una conservazione più lunga perché a volte i problemi vengono scoperti tardi, specialmente dopo aggiornamenti dei plugin o modifiche ai contenuti effettuate da più persone.
Un modello pratico è ragionare per livelli. Conserva backup frequenti per errori a breve termine, backup giornalieri per incidenti recenti e backup settimanali o mensili per uno sguardo più lungo nel tempo. Questo protegge sia il recupero operativo sia i problemi rilevati più lentamente.
Un punto di partenza comune è questo:
- Backup orari per 24-48 ore per siti dinamici
- Backup giornalieri per 14-30 giorni
- Backup settimanali per 8-12 settimane
- Backup mensili per 6-12 mesi
Questa non è una legge universale. È solo una base sensata. Una piattaforma SaaS con scritture costanti può richiedere backup specifici del database ogni pochi minuti. Un sito vetrina può andare perfettamente bene con sole copie giornaliere e settimanali. Dipende dal tasso di cambiamento, dall'impatto sui ricavi, dai requisiti di conformità e dalla rapidità con cui il team nota i problemi.
Abbina la conservazione al tipo di sito web, non solo alla dimensione del server
La capacità di archiviazione è il primo parametro sbagliato. Il rischio di recupero è quello corretto.
Per un negozio WooCommerce, ordini dei clienti, modifiche all'inventario e aggiornamenti dello stato dei pagamenti rendono preziosi intervalli di backup brevi. La protezione oraria di file e database può essere giustificata perché i dati cambiano frequentemente e sono critici per il business. In quel caso, una finestra di conservazione breve per i backup ad alta frequenza più copie giornaliere e settimanali pi ù lunghe mantiene i costi ragionevoli.
Per un sito di agenzia ricco di contenuti o un sito editoriale, gli errori potrebbero non essere notati immediatamente. Un editor può rimuovere pagine, sovrascrivere media o pubblicare modifiche difettose che vengono scoperte solo una settimana dopo. Qui, una conservazione giornaliera più lunga conta più di snapshot molto frequenti.
Per un'applicazione SaaS, potresti aver bisogno di una logica di conservazione separata per il server applicativo, il database, gli asset caricati e la configurazione. Trattare tutti i componenti come un unico set di backup può essere costoso e macchinoso. I database di solito richiedono punti di recupero più stretti. Gli asset statici possono spesso seguire una pianificazione più lenta.
Per ambienti di sviluppo o staging, la conservazione può essere molto più breve. Se l'ambiente è riproducibile dal codice e dalle definizioni dell'infrastruttura, c'è poco motivo di mantenere una lunga cronologia dei backup. Risparmia il budget per la produzione, dove gli errori hanno fatture allegate.
Il compromesso tra costo e profondità di recupero
La conservazione è sempre un esercizio di equilibrio. Più punti di ripristino offrono più opzioni, ma aumentano anche l'uso dello spazio di archiviazione, il tempo di replica e la complessità di gestione. Meno conservazione fa risparmiare denaro, ma restringe le vie di fuga.
La policy che sembra economica non sempre lo è nella vita reale. Se un'infezione malware è iniziata dieci giorni fa e la tua conservazione è di sette giorni, il recupero diventa molto più costoso dello spazio di archiviazione che hai risparmiato. Risposta agli incidenti, attività forense, ordini persi e supporto di emergenza tendono a costare più di qualche backup conservato.
D'altra parte, conservare ogni backup giornaliero per sempre non è molto saggio. Una lunga conservazione senza sfoltimento crea disordine e può rendere più lenta la selezione del ripristino sotto pressione. Durante un'interruzione, nessuno si diverte a scorrere 900 punti di ripristino quasi identici come se fosse un archivio di foto di famiglia del 2014.
Un approccio migliore è la conservazione a livelli. Mantieni una copertura densa dove il cambiamento è recente e una copertura più rada con l'aumentare dell'età. Questo offre flessibilità senza duplicazioni inutili.
Copie locali, offsite e immutabili
Una policy di conservazione è utile solo se i backup sopravvivono allo stesso evento che mette fuori uso il sito. Se il sito web e i backup si trovano sullo stesso sistema compromesso, il servizio non torna tranquillo solo perché esiste una cartella di backup.
Per una protezione seria del sito web, conserva copie in più di un luogo. I backup locali possono accelerare i ripristini. I backup offsite proteggono da guasti dell'host, corruzioni gravi e incidenti a livello di account. Se ransomware o eliminazione malevola fanno parte del tuo modello di minaccia, uno spazio di archiviazione dei backup immutabile o protetto in scrittura merita attenzione.
È qui che a volte le aziende più piccole pianificano poco. Presumono che la conservazione dei backup riguardi solo il tempo. Riguarda anche l'isolamento. Sette copie giornaliere sullo stesso server sono comunque a una sola brutta giornata dal diventare zero copie utili.
Testa la velocità di ripristino, non solo il successo del backup
Un processo di backup contrassegnato come riuscito non garantisce una buona esperienza di recupero. I file possono essere ripristinati lentamente. I database possono richiedere coordinamento point-in-time. Le dipendenze potrebbero non corrispondere. Le credenziali potrebbero mancare. DNS e stato SSL potrebbero richiedere una gestione separata.
La policy di conservazione dovrebbe essere modellata dai test di ripristino. Se il tuo team riesce a ripristinare il sito di un cliente in 20 minuti dallo snapshot di ieri, questa è una solida posizione operativa. Se il ripristino del backup del mese scorso richiede un assemblaggio manuale da diversi sistemi, allora una lunga conservazione esiste solo sulla carta.
Esegui test di ripristino abbastanza spesso da poterti fidare del processo. Testa un backup recente e uno più vecchio. Esegui il ripristino in un ambiente separato, dove possibile. Verifica il comportamento dell'applicazione, non solo la presenza dei file. Un database che viene importato correttamente ma interrompe gli accessi è comunque un recupero fallito.
Conformità, contratti e aspettative dei clienti
Alcuni requisiti di conservazione derivano dalla normativa. Altri derivano da contratti, policy interne o semplice buon senso aziendale. Se gestisci dati dei clienti, flussi di lavoro relativi ai pagamenti o registri regolamentati, la conservazione dei backup potrebbe dover allinearsi agli obblighi legali e ai requisiti di eliminazione.
Fai attenzione qui. La conservazione dei backup non è la stessa cosa della conservazione generale dei dati. Un'azienda può aver bisogno di eliminare i dati dei clienti dai sistemi live su richiesta, mentre i backup seguono cicli di scadenza controllati. Le regole legali e operative dovrebbero essere documentate chiaramente in modo che la tua policy di conservazione non crei confusione durante audit o richieste dei clienti.
Per le agenzie e i clienti di hosting gestito, è anche intelligente definire chi possiede le decisioni di ripristino e fino a quanto indietro il recupero può ragionevolmente arrivare. Le aspettative dovrebbero essere calme e precise, non magiche.
Una policy pratica con cui la maggior parte dei siti web SMB può iniziare
Se hai bisogno di un punto di partenza utilizzabile, questa guida alla policy di conservazione dei backup del sito web consiglierebbe un modello semplice per molti siti web di produzione. Conserva backup orari per 48 ore se il sito cambia durante il giorno. Conserva backup giornalieri per 30 giorni. Conserva backup settimanali per 8 settimane. Conserva backup mensili per 12 mesi se il sito ha valore commerciale, record dei clienti o cicli di contenuto più lunghi.
Poi adatta in base alla realtà. Se i ripristini usano quasi sempre le ultime 24 ore, aumenta la frequenza a breve termine. Se i problemi vengono regolarmente scoperti dopo due settimane, estendi la conservazione giornaliera. Se i costi di archiviazione iniziano a salire, riduci la duplicazione negli ambienti di minor valore prima di toccare la cronologia di produzione.
Per i team che non vogliono fare da babysitter a tutto questo, una configurazione di hosting gestito con backup monitorati, procedure di ripristino chiare e supporto umano elimina molti rischi silenziosi. Questo è uno dei motivi per cui provider come kodu.cloud mettono supporto operativo attorno ai sistemi di backup invece di trattare i backup come una casella da spuntare.
Metti la policy per iscritto. Definisci frequenza dei backup, finestre di conservazione, posizione di archiviazione, pianificazione dei test di ripristino, ownership ed eccezioni. Una policy che esiste solo nella testa di qualcuno di solito scompare nello stesso momento della persona in vacanza.
Conserva una cronologia sufficiente per recuperare dai problemi che affronti davvero, non da quelli che sembrano ordinati solo in un foglio di calcolo. È qui che la conservazione dei backup smette di essere teoria e inizia a proteggere l'azienda.
Andres Saar Customer Care Engineer