Una Policy di Conservazione dei Backup per Siti Web che Funziona
Pubblicato il 14 agosto 2026
Una policy di conservazione dei backup per i siti web dovrebbe offrirti diversi punti di ripristino recenti, alcune opzioni di recupero meno recenti e almeno una copia esterna al server che esegue il sito. Se un aggiornamento di un plugin interrompe il checkout alle 10:15, ti serve una versione pulita delle 10:00, non un backup di martedì scorso e un'espressione fiduciosa.
La pianificazione giusta dipende da quanto spesso cambiano i tuoi dati, da quanto costa il downtime e da quanto rapidamente il tuo team riesce a identificare quando è iniziato un problema. Un sito aziendale statico e un negozio WooCommerce molto attivo non dovrebbero essere protetti allo stesso modo. Il servizio può anche essere online, ma se mancano gli ordini di ieri, gli invii dei moduli o le modifiche dei clienti, non si può ancora stare davvero tranquilli.
Cosa Deve Coprire una Policy di Conservazione dei Backup per Siti Web
La conservazione non è semplicemente il numero di backup che mantieni. È l'insieme di regole che decide quali copie di backup restano disponibili, dove sono archiviate, per quanto tempo vi restano e quando vengono eliminate.
Una policy utile tiene conto di tre esigenze di recupero distinte. Primo, ti serve un recupero operativo rapido per gli errori recenti: un deployment errato, file eliminati, un aggiornamento non riuscito o una modifica accidentale della configurazione. Secondo, ti serve un recupero storico quando un problema è rimasto silenziosamente presente per settimane, come un accesso admin compromesso o codice infetto. Terzo, potresti aver bisogno di conservare registrazioni per motivi aziendali, contrattuali o normativi.
Questi obiettivi possono entrare in conflitto. Conservare ogni backup per sempre comporta costi di archiviazione, job di backup più lenti e un elenco di ripristino confuso. Conservare troppo poco fa risparmiare spazio fino al momento in cui il backup di cui hai bisogno è già scaduto. La risposta sensata è una conservazione a livelli, non una lunga fila di backup giornalieri identici.
Parti dagli Obiettivi di Recupero, Non da un Numero di Archiviazione
Prima di impostare i periodi di conservazione, definisci due obiettivi pratici: recovery point objective e recovery time objective.
Il tuo recovery point objective, spesso chiamato RPO, risponde a quanti dati recenti puoi permetterti di perdere. Un negozio e-commerce che elabora ordini durante tutta la giornata può aver bisogno di backup orari del database o di backup consapevoli delle transazioni. Un sito vetrina aggiornato due volte al mese può accettare un backup giornaliero, a condizione che i dati critici dei moduli di contatto siano gestiti altrove.
Il tuo recovery time objective, o RTO, risponde a quanto rapidamente il sito deve essere ripristinato. Un backup recente archiviato localmente o in un archivio di backup vicino di solito può essere ripristinato più velocemente di un archivio cold. Ma le sole copie locali non bastano. Un guasto del server, un evento ransomware, un'operazione errata sul disco o una compromissione a livello di account possono colpire insieme il sito e i suoi backup locali.
Per la maggior parte dei siti web aziendali, definisci questi obiettivi in linguaggio semplice. Per esempio: “Non possiamo perdere più di un'ora di ordini, e la vetrina online deve essere ripristinata entro due ore.” È molto più utile che dire “facciamo backup giornalieri” e scoprire in seguito che giornaliero significa una volta ogni 24 ore.
Controlla Cosa Cambia Davvero
I file del sito web e i dati del database non cambiano allo stesso ritmo. I file core di WordPress possono restare invariati per mesi, mentre il database riceve ordini, commenti, prenotazioni, modifiche alle iscrizioni e invii di moduli per tutto il giorno.
Un backup completo dovrebbe includere file dell'applicazione, database, file di configurazione, contenuti multimediali caricati, configurazione relativa a SSL dove pertinente, definizioni delle attività pianificate e qualsiasi dato applicativo personalizzato archiviato fuori dalla web root. Se un backup del database riesce ma la directory degli upload è esclusa, il sito ripristinato può funzionare mentre immagini di prodotto o documenti dei clienti scompaiono silenziosamente.
Per un'applicazione più grande, documenta anche le dipendenze. Object storage, servizi email, sistemi di pagamento, database esterni e record DNS potrebbero non rientrare in un backup del server. Fanno comunque parte del piano di recupero.
Una Pianificazione di Conservazione Pratica per la Maggior Parte dei Siti Web
Un punto di partenza comune è conservare i backup frequenti per un breve periodo e i backup meno frequenti più a lungo. Questo offre opzioni di ripristino utili senza far crescere l'uso dello storage come un garage abbandonato.
Per un tipico sito di piccola impresa, un sito gestito da un'agenzia o un sito di marketing, conserva backup giornalieri per 14-30 giorni, backup settimanali per 8-12 settimane e backup mensili per 6-12 mesi. Esegui un backup aggiuntivo prima di modifiche importanti come un upgrade del CMS, il lancio di un redesign, una migrazione, la sostituzione di un plugin o lavori sulla configurazione del server.
Per negozi, dashboard SaaS, siti membership, piattaforme di prenotazione e altri servizi che fanno un uso intensivo del database, aggiungi una protezione del database più frequente. Backup orari del database conservati per 24-72 ore possono essere appropriati, seguiti da backup giornalieri per 30 giorni, backup settimanali per 12 settimane e backup mensili per 12 mesi. L'intervallo esatto dipende dal volume delle transazioni e dal fatto che l'applicazione possa eseguire il backup dei dati attivi in modo coerente.
Le agenzie dovrebbero valutare policy specifiche per cliente invece di applicare una sola pianificazione a ogni account. Un sito con il menu di un ristorante non ha bisogno della stessa conservazione di un portale clienti che gestisce documenti caricati. Raggruppa i siti in base al rischio e all'impatto aziendale, poi rendi la policy visibile nel contratto con il cliente o nell'ambito del servizio.
Tieni Separati i Punti di Ripristino Pre-Modifica
Le pianificazioni automatizzate non sostituiscono i backup eseguiti consapevolmente prima di attività rischiose. Crea un punto di ripristino etichettato prima di aggiornamenti, migrazioni, manutenzione del database, modifiche ai template o regolazioni a livello di server.
Conserva i backup pre-modifica per almeno sette-quattordici giorni dopo il completamento del lavoro. Alcuni problemi compaiono solo dopo un ciclo di fatturazione, un job in background o l'esecuzione di un'integrazione. Una volta confermata la stabilità della modifica, può subentrare la normale conservazione.
Segui il Principio 3-2-1, con Operazioni Realistiche
Il classico modello 3-2-1 resta pratico: mantieni tre copie dei dati, su due tipi di archiviazione diversi, con una copia offsite. Per le operazioni dei siti web, questo spesso significa i dati di produzione, una copia di backup nell'ambiente di hosting e una copia cifrata in uno storage offsite indipendente.
La parola chiave è indipendente. Un backup archiviato sullo stesso server virtuale è comodo, ma non protegge da un guasto a livello di server. Un backup archiviato nello stesso account hosting può essere esposto anche se un attaccante ottiene le credenziali dell'account o se viene eseguita un'azione di eliminazione estesa.
Le copie offsite dovrebbero essere cifrate in transito e a riposo. L'accesso dovrebbe usare credenziali separate dove possibile, idealmente con autenticazione multi-fattore e permessi limitati. I permessi di eliminazione dei backup meritano particolare attenzione. Se un ransomware o un amministratore compromesso può cancellare dati di produzione e ogni punto di recupero in una sola sessione, la pianificazione di conservazione sembrerà eccellente sulla carta e inutile nella pratica.
Su kodu.cloud, le soluzioni gestite di backup e monitoraggio possono ridurre il lavoro di routine, ma la responsabilità dei requisiti di recupero dovrebbe comunque restare chiara. Il tuo provider può mantenere il sistema; la tua azienda dovrebbe decidere quanta perdita di dati e quanto downtime può accettare.
Rendi la Conservazione Consapevole degli Incidenti di Sicurezza
Una finestra di conservazione breve può essere pericolosa quando il malware viene scoperto tardi. Un sito potrebbe restare compromesso per diverse settimane prima che redirect sospetti, attività di spam o account admin non autorizzati diventino visibili. Se ogni backup viene sovrascritto dopo sette giorni, potresti conservare solo copie infette.
Ecco perché i punti di ripristino settimanali e mensili sono importanti. Per ambienti a rischio più elevato, considera copie di backup immutabili o protette da scrittura per un periodo definito. L'immutabilità non rende magicamente corretto un backup, ma può impedire a un attaccante di modificarlo o eliminarlo dopo una compromissione.
Mantieni log delle attività di successo, errore, eliminazione e ripristino dei backup. Gli avvisi dovrebbero raggiungere una persona che possa intervenire, non una casella di posta diventata un piccolo museo digitale. Il monitoraggio dovrebbe controllare anche capacità di archiviazione, durata dei backup e cambiamenti insoliti nella dimensione dei backup. Un backup improvvisamente minuscolo può indicare un database escluso o una raccolta file non riuscita; uno improvvisamente enorme può indicare log, file di cache o dati indesiderati che entrano nel set di backup.
Testa i Ripristini Prima di Averne Bisogno
Un backup è uno strumento di recupero solo dopo essere stato ripristinato con successo. Lo stato del job di backup conferma che i dati sono stati copiati. Non dimostra che l'archivio sia completo, leggibile, compatibile con l'ambiente corrente o utilizzabile sotto pressione temporale.
Testa un ripristino almeno trimestralmente per un sito web aziendale standard e più spesso per applicazioni critiche per i ricavi. Ripristina in un ambiente di staging o in una posizione isolata dove non possa sovrascrivere la produzione. Conferma che l'applicazione si avvii, che il database si connetta, che i file multimediali vengano caricati, che i moduli funzionino, che le attività pianificate siano presenti e che le azioni utente critiche si comportino normalmente.
Registra quanto tempo ha richiesto il ripristino e quali passaggi manuali sono stati necessari. Se il recupero dipende da uno sviluppatore che ricorda una password del database, una sequenza DNS e un comando shell di cinque anni fa, quello non è un piano. È un reperto folkloristico.
Documenta le Eccezioni e Riesamina la Policy
La tua policy di conservazione dovrebbe stare in una pagina e rispondere a qualche domanda diretta: cosa viene sottoposto a backup, con quale frequenza, dove sono archiviate le copie, per quanto tempo viene conservata ciascuna copia, chi può richiedere un ripristino e come viene documentato il test di ripristino. Indica anche i sistemi che non sono inclusi, così nessuno presume che un backup copra un servizio di terze parti a cui non può accedere.
Riesamina la policy dopo una modifica importante del sito, un nuovo requisito di conformità, una crescita del traffico o un incidente di recupero. Backup più frequenti possono diventare necessari man mano che un negozio online cresce. D'altra parte, conservare backup giornalieri per più anni per un sito con poche modifiche può rappresentare un costo senza una protezione utile.
Imposta la policy di conservazione attorno al momento in cui ne avrai più bisogno: un deployment affrettato di venerdì, un aggiornamento malevolo di un plugin o un problema al disco nel momento peggiore. Punti di ripristino chiari, una copia indipendente e un processo testato offrono al tuo team qualcosa di meglio della semplice fiducia. Ti danno un passo successivo praticabile.
Andres Saar Customer Care Engineer