Backup giornalieri vs snapshot spiegati
Pubblicato il 19 giugno 2026
Un punto di rollback non è la stessa cosa di un piano di ripristino. Questo è il punto centrale del confronto tra backup giornalieri e snapshot, ed è ciò che conta di più subito dopo un aggiornamento di plugin riuscito male, un deployment non funzionante, attività ransomware o un cliente che chiede dove siano finiti i dati di ieri. In quei momenti, il servizio deve tornare online rapidamente, ma deve anche tornare pulito.
Gli snapshot riguardano di solito la velocità. I backup riguardano la capacità di sopravvivere agli incidenti. Se li tratti come intercambiabili, prima o poi i log racconteranno la stessa storia, e non sarà quella a lieto fine.
Backup giornalieri vs snapshot: la vera differenza
Uno snapshot acquisisce lo stato di un sistema o di un volume in un momento specifico. A seconda della piattaforma, può usare un comportamento di storage copy-on-write, blocchi modificati o metadati a livello di storage per preservare quel punto nel tempo. È strettamente legato all'infrastruttura sottostante in cui è stato creato. Ecco perché gli snapshot sono eccellenti per rollback e test a breve termine, ma meno affidabili come unica linea di difesa.
Un backup è una copia separata dei dati creata per il ripristino. I buoni sistemi di backup archiviano i dati in modo indipendente dal carico di lavoro live, spesso con regole di conservazione, cronologia delle versioni e storage off-server o storage off-site. Questa separazione è la parte che le persone saltano quando tutto è tranquillo. Poi arriva un problema di storage, una compromissione dell'account o un errore di eliminazione, e all'improvviso la separazione sembra un'idea molto intelligente.
Quindi, in termini pratici, gli snapshot aiutano ad annullare rapidamente le modifiche recenti. I backup giornalieri aiutano a recuperare quando il sistema stesso è danneggiato, eliminato, cifrato, corrotto o semplicemente sparito.
Dove gli snapshot aiutano subito
Se stai aggiornando un'app di produzione, cambiando versioni PHP, applicando patch a un server database o modificando impostazioni di firewall e pacchetti, gli snapshot sono utili perché sono rapidi da creare e rapidi da ripristinare. Per sviluppatori e agenzie che pubblicano modifiche sotto pressione, questa è spesso la differenza tra un incidente di dieci minuti e uno di due ore.
Sono adatti anche a finestre di rischio temporanee. Prima di una migrazione, prima di una modifica importante a un'estensione WooCommerce, prima di un upgrade di pacchetti del sistema operativo: crea uno snapshot. Se la modifica rompe il servizio, esegui il rollback e il sito torna tranquillo.
Questa velocità è il motivo per cui gli snapshot restano preziosi. Possono ridurre drasticamente i tempi di ripristino. Su molte piattaforme virtualizzate, ripristinare uno snapshot è operativamente molto più rapido che ricostruire da backup, soprattutto se l'obiettivo è riportare l'intera macchina a uno stato molto recente.
Ma gli snapshot hanno dei limiti, e questi limiti non sono piccoli.
I punti deboli degli snapshot
Gli snapshot di solito risiedono nello stesso ecosistema di storage del server che proteggono. Se quel livello di storage si guasta, se la VM viene eliminata insieme alla catena di snapshot associata o se un attaccante ottiene accesso sufficiente per rimuoverli, la tua rete di sicurezza può sparire insieme al carico di lavoro.
Possono anche diventare difficili da gestire se conservati troppo a lungo. Catene di snapshot di grandi dimensioni possono influire sulle prestazioni dello storage, complicare i ripristini o creare debito operativo che nessuno ha voglia di ripulire di venerdì sera. Alcune piattaforme sono migliori di altre in questo, ma lo schema è familiare.
C'è anche il problema della coerenza. Uno snapshot acquisito durante scritture attive può essere crash-consistent invece che application-consistent. Questo significa che il filesystem può ripristinarsi correttamente, ma il database o il servizio di posta potrebbero comunque richiedere una riparazione. Non è automaticamente rotto, ma non è nemmeno automaticamente sicuro. Dipende dal carico di lavoro e da come è stato coordinato lo snapshot.
Perché i backup giornalieri contano ancora
I backup giornalieri sono più lenti da creare e a volte più lenti da ripristinare, ma sono progettati per un compito diverso. Proteggono da scenari di guasto più ampi: eliminazione accidentale, corruzione scoperta giorni dopo, malware, aggiornamenti non riusciti e perdita dell'infrastruttura.
La parte importante è la conservazione. Uno snapshot di due ore fa aiuta con un deployment riuscito male. Un set di backup di sette giorni fa aiuta quando scopri che un attaccante ha aggiunto codice malevolo la settimana scorsa e nessuno se n'è accorto. Se tutto ciò che hai è lo snapshot di ieri, potresti semplicemente ripristinare la compromissione.
I backup permettono anche di recuperare elementi specifici invece dell'intero server. Può trattarsi di un singolo database, una mailbox, una directory utente o un file del sito spostato per errore. Per le aziende, questo conta più di quanto sembri all'inizio. Il rollback dell'intero server è uno strumento grossolano. Il ripristino granulare è spesso l'opzione più pulita e meno dirompente.
Una strategia corretta di backup giornalieri dovrebbe includere versioning, conservazione adeguata al rischio aziendale e storage separato dalla macchina di produzione. Idealmente, dovrebbe supportare anche i test di ripristino. Un backup che non è mai stato ripristinato è una raccolta di file molto ottimista.
I punti deboli dei backup giornalieri
Anche i backup non sono magia. Se vengono eseguiti una volta ogni 24 ore, il tuo obiettivo del punto di ripristino è ancora fino a 24 ore di potenziale perdita di dati. Per un negozio e-commerce trafficato o un'app SaaS, potrebbe essere troppo. Giornaliero è un buon punto di partenza, ma da solo potrebbe non bastare per dati che cambiano spesso.
Anche i tempi di ripristino possono essere più lunghi. Ricostruire un intero server da backup richiede più lavoro che ripristinare uno snapshot, soprattutto se devi predisporre una nuova macchina, validare i servizi e confermare l'integrità dei dati. Se i tuoi strumenti di backup sono configurati male, questo può trasformarsi in un lungo pomeriggio.
E naturalmente, i backup falliscono quando nessuno li monitora. Credenziali configurate male, repository pieni, agenti non funzionanti o errori silenziosi non hanno alcun rispetto per la fiducia. Ecco perché i job di backup monitorati contano tanto quanto i job di backup stessi.
Backup giornalieri vs snapshot per scenari di hosting comuni
Per un sito WordPress con frequenti modifiche ai plugin, gli snapshot sono utili prima degli aggiornamenti e del lavoro sul tema. I backup giornalieri restano necessari perché i problemi dei plugin non sono l'unico rischio. Compromissione dei file, corruzione del database ed eliminazione di contenuti sono tutti problemi diversi.
Per un'agenzia che gestisce diversi ambienti dei clienti, gli snapshot aiutano con il controllo delle modifiche. Prima di ogni release, creane uno. Ma la protezione del cliente dipende comunque da backup pianificati con conservazione, idealmente archiviati fuori dal nodo di produzione. Altrimenti un problema infrastrutturale può trasformarsi in diverse telefonate scomode.
Per un'app SaaS con database attivi, gli snapshot da soli non bastano, a meno che non siano strettamente coordinati con l'applicazione e supportati da un progetto di ripristino più ampio. Backup consapevoli del database, log delle transazioni dove rilevanti e procedure di ripristino testate contano qui più di una semplice immagine point-in-time.
Per sviluppo e staging, gli snapshot possono essere quasi perfetti per un rollback rapido. La tolleranza alla perdita di dati è di solito più alta e la velocità è il valore principale. Per la produzione, sono uno strato, non l'intero piano.
La risposta migliore di solito è usarli entrambi
Questa è la parte che evita problemi: usa gli snapshot per un rollback rapido e i backup giornalieri per un ripristino durevole. Questi strumenti non sono in competizione. Risolvono problemi di ripristino diversi.
Uno schema sensato è questo. Crea snapshot prima di modifiche rischiose, aggiornamenti di sistema, migrazioni o deployment. Mantienili di breve durata e intenzionali. Esegui backup giornalieri secondo pianificazione con conservazione basata sulle esigenze aziendali. Archivia i dati di backup separatamente dal server live. Testa i ripristini abbastanza spesso da evitare che qualcuno debba tirare a indovinare durante un incidente.
Se il carico di lavoro è più sensibile, aggiungi backup più frequenti o replica per i dati che cambiano più rapidamente. Database, dati degli ordini, upload dei clienti e registri transazionali di solito meritano attenzione extra. Non ogni sistema ha bisogno di complessità di livello enterprise, ma ogni sistema di produzione ha bisogno di un piano che corrisponda al costo di sbagliare.
Come scegliere la combinazione giusta
Parti da due domande. Quanti dati puoi permetterti di perdere e quanto velocemente devi ripristinare il servizio? Queste risposte definiscono il tuo obiettivo del punto di ripristino e il tuo obiettivo del tempo di ripristino, anche se non usi mai questi termini in riunione.
Se puoi tollerare tempi di inattività molto ridotti ma puoi ricostruire da uno stato recente, gli snapshot aiutano. Se hai bisogno di protezione da eliminazione, ransomware, corruzione nascosta o perdita dell'infrastruttura, i backup non sono negoziabili. Se la risposta è entrambi, allora sì, la configurazione dovrebbe includerli entrambi.
Per molte piccole e medie imprese, la base pratica è semplice: backup giornalieri automatizzati con conservazione, più snapshot on-demand prima di modifiche rischiose. Non è over-engineering. È normale igiene operativa, solo con meno drammi.
Un provider di hosting gestito può rendere tutto questo molto più semplice occupandosi della pianificazione, monitorando i job non riusciti e aiutando con le richieste di ripristino quando la giornata prende una brutta piega. È qui che il supporto operativo conta. Il linguaggio sofisticato sui backup è utile, ma un ripristino tranquillo lo è ancora di più.
In Kodu.cloud, questa è la parte che prendiamo sul serio perché il ripristino è il momento che i clienti ricordano. Il rollback rapido ha valore. Anche una reale profondità di backup ha valore. Uno ti tira fuori da un aggiornamento andato male. L'altro ti fa superare una brutta settimana.
Se stai scegliendo tra backup giornalieri e snapshot, non scegliere quello che sembra più semplice. Scegli la combinazione che funziona ancora dopo eliminazione, corruzione, compromissione ed errore umano. I sistemi si comportano bene fino al momento in cui non lo fanno più, ed è esattamente per questo che esiste la pianificazione del ripristino.
Andres Saar Ingegnere dell'assistenza clienti