Devo eseguire il backup dei miei backup? Sì, solitamente

Pubblicato il 22 aprile 2026

Se ti sei mai chiesto: "Devo eseguire il backup dei miei backup?", la risposta breve è sì, ma non sempre nello stesso modo, e non per ogni tipo di dato. La vera domanda è quanto danno puoi tollerare se il tuo set di backup primario fallisce, si corrompe o diventa indisponibile proprio quando ne hai bisogno.

Questo scenario è più comune di quanto molti team si aspettino. Un'attività di backup può segnalare successo mentre memorizza file incompleti. Un account di archiviazione può essere eliminato per errore. Il ransomware può diffondersi nei repository di backup montati. Un account di hosting può sopravvivere a un'interruzione, ma il punto di ripristino potrebbe essere troppo vecchio per essere utile. Il backup esisteva. Semplicemente non era sufficiente.

Per le aziende che gestiscono siti web, app SaaS, progetti cliente o negozi online, la strategia di backup non riguarda solo la conservazione di copie. Riguarda la sopravvivenza. Se la tua attività dipende dai dati, un singolo livello di backup potrebbe lasciarti ancora esposto.

Quando ha senso eseguire il backup dei backup

Un backup di secondo livello ha senso quando il tuo primo backup rappresenta un singolo punto di fallimento. Ciò potrebbe significare un unico provider di archiviazione, una regione, un server di backup o un account amministrativo che controlla tutto. Se uno qualsiasi di questi elementi si guasta, anche il tuo piano di recupero può fallire.

Questo è più importante quando i tempi di inattività sono costosi. Un sito e-commerce che perde dati d'ordine, un'agenzia che perde ambienti cliente o una piattaforma SaaS che non può ripristinare i record dei clienti affrontano più di un semplice inconveniente. Affrontano perdita di entrate, pressione del supporto e danni alla reputazione.

In questi casi, il tuo backup necessita della sua protezione. Ciò non significa sempre duplicare tutto altre tre volte. Significa identificare cosa deve sopravvivere anche se il primo percorso di ripristino fallisce.

Una buona regola è semplice: se perdere il tuo backup creerebbe un'emergenza aziendale, allora sì, dovresti proteggere quel backup con un'altra copia indipendente.

Il vero rischio è il fallimento condiviso

La maggior parte dei problemi di backup non è causata dall'assenza totale di backup. Si verificano perché il backup e il sistema originale falliscono insieme, o il backup fallisce per lo stesso motivo.

Ad esempio, se il tuo server di produzione e i backup risiedono nello stesso account provider, un problema di fatturazione, un compromesso dell'account o un'eliminazione accidentale possono interessare entrambi. Se gli snapshot del tuo server sono archiviati sulla stessa piattaforma e gestiti dalle stesse credenziali, è conveniente a livello operativo, ma non è una separazione completa.

Lo stesso vale per il ransomware. Se lo spazio di archiviazione dei backup è sempre montato e scrivibile, il malware può crittografare sia i dati di produzione che i repository di backup. Se un backup del database viene eseguito ogni notte ma nessuno testa i ripristini, la corruzione può avanzare in silenzio per settimane.

Questo è il motivo per cui una pianificazione di backup matura si concentra sull'isolamento. Non solo copie, ma copie che falliscono diversamente.

Cosa significa effettivamente "eseguire il backup dei backup"

La frase può sembrare eccessiva, ma in pratica di solito significa una delle tre cose.

Innanzitutto, potresti copiare i backup in una seconda posizione di archiviazione. Potrebbe trattarsi di un altro provider cloud, un'altra regione o un sistema di archiviazione separato con controlli di accesso diversi.

In secondo luogo, potresti creare immutabilità o protezione di conservazione attorno al set di backup stesso. Ciò significa che i backup non possono essere alterati o eliminati per un periodo definito, nemmeno da un account amministratore in condizioni normali.

In terzo luogo, potresti mantenere diversi tipi di backup per diversi obiettivi di recupero. Ad esempio, snapshot locali veloci per ripristini rapidi e copie di archivio più lente offsite per il recupero in caso di disastro.

Queste sono tutte forme valide di backup dei backup. Il punto non è la duplicazione fine a sé stessa. Il punto è ridurre la possibilità che un singolo fallimento annulli tutte le opzioni di recupero.

Devo eseguire il backup dei miei backup per ogni server?

Non necessariamente. La risposta corretta dipende dagli obiettivi di recupero, dal valore dei dati e da come viene utilizzata la tua infrastruttura.

Se gestisci una macchina di sviluppo usa e getta che può essere ricostruita dal codice in un'ora, un backup di secondo livello potrebbe non valere il costo o la complessità. Se ospiti un sito vetrina con modifiche rare e copie esterne del contenuto esistono già, un sistema di backup affidabile potrebbe essere sufficiente.

Ma se il server contiene database transazionali, caricamenti cliente, configurazioni personalizzate, dati di posta elettronica o carichi di lavoro di produzione che cambiano costantemente, allora affidarsi a un unico target di backup è rischioso. In questi ambienti, un unico punto di ripristino errato può trasformare un incidente gestibile in un lungo periodo di inattività.

La domanda migliore è questa: cosa succederebbe se il tuo repository di backup principale diventasse inutilizzabile oggi? Se la risposta è "saremmo nei guai veri", allora sai già che il backup di secondo livello è giustificato.

L'idea 3-2-1 regge ancora

C'è un motivo per cui il modello di backup 3-2-1 è ancora ampiamente rispettato. Mantieni tre copie dei dati, su due diversi supporti o sistemi, con una copia offsite. Non è appariscente, ma affronta i modelli di guasto comuni meglio di una singola destinazione di backup.

Per gli ambienti di hosting moderni, ciò si traduce spesso in dati di produzione live, una piattaforma di backup primaria per ripristini rapidi e una copia offsite separata per incidenti gravi. Gli strumenti esatti possono variare, ma il principio di progettazione rimane valido.

Ciò che conta è l'indipendenza. Se la copia offsite utilizza le stesse credenziali, lo stesso percorso di gestione e le stesse autorizzazioni di eliminazione della copia primaria, hai ancora un rischio di sovrapposizione. La separazione dovrebbe essere reale, non solo teorica.

Configurazioni comuni che funzionano bene

Per molte aziende, il modello più pratico è quello stratificato. Mantieni backup a breve termine vicini alla produzione per la velocità, quindi replicali altrove per la resilienza. Ciò ti offre un rapido recupero operativo senza fidarti per sempre di un unico ambiente di archiviazione.

Un VPS gestito o un server dedicato potrebbe utilizzare snapshot giornalieri per le esigenze di rollback recenti, backup consapevoli del database per la coerenza delle applicazioni e una copia di archiviazione offsite mantenuta con una conservazione più lunga. Un team più avanzato potrebbe anche conservare archivi mensili in un account separato con regole di conservazione rigorose.

Questo approccio stratificato funziona perché le esigenze di recupero non sono tutte uguali. Ripristinare un file di configurazione eliminato è diverso dal ricostruire dopo un guasto di archiviazione o un evento di sicurezza. Un metodo di backup raramente fa bene ogni lavoro.

Compromessi che dovresti considerare

Eseguire il backup dei backup aggiunge costi. Aggiunge costi di archiviazione, tempo di trasferimento, pianificazione della conservazione e altre cose da monitorare. Se fatto male, può anche creare una falsa sicurezza. Due catene di backup interrotte non sono meglio di una.

C'è anche un aspetto di prestazioni e gestione. Alcuni team conservano troppo tutto, archiviano dati ridondanti inutili per sempre e rendono i ripristini più difficili perché il catalogo di backup diventa disordinato. Altri creano così tanti livelli di recupero che nessuno sa quale copia sia autorevole.

Quindi sì, aggiungi ridondanza, ma mantienila organizzata. Definisci cosa viene sottoposto a backup, ogni quanto, per quanto tempo viene conservato e chi lo verifica. Più critico è il sistema, meno vuoi che la logica di backup viva solo nella testa di una persona.

Come decidere senza complicare troppo le cose

Inizia con l'impatto aziendale, non con gli strumenti. Chiedi quanta perdita di dati è accettabile e per quanto tempo il servizio può rimanere interrotto. Poi considera se la tua attuale configurazione di backup può effettivamente soddisfare quel target se un livello fallisce.

Se il tuo sito web può tollerare un giorno di modifiche perse, la tua progettazione di backup può essere più semplice rispetto a un'app SaaS che necessita di un recupero del database quasi in tempo reale. Se la tua azienda farebbe fatica a superare un'interruzione di diverse ore, allora la velocità di ripristino è importante quanto l'esistenza del backup.

Successivamente, verifica l'indipendenza. Il tuo backup è archiviato da qualche parte veramente separato? È protetto da eliminazione accidentale? Puoi ripristinare senza fare affidamento sullo stesso ambiente compromesso? Se la risposta è no, i tuoi backup probabilmente necessitano del loro percorso di backup.

Infine, testa il recupero. È qui che molti piani falliscono. Una strategia di backup è affidabile solo dopo che un test di ripristino reale conferma che i dati sono intatti, sufficientemente aggiornati e utilizzabili sotto pressione.

Uno standard semplice per la maggior parte delle aziende

Per le piccole e medie imprese, una base sensata è questa: mantieni backup primari automatizzati per un recupero rapido, mantieni una seconda copia offsite per scenari di disastro, proteggi lo spazio di archiviazione dei backup con accesso limitato e controlli di conservazione, e testa i ripristini secondo una pianificazione.

Ciò è sufficiente per coprire la maggior parte dei rischi pratici senza trasformare la gestione dei backup in un progetto di ingegneria a tempo pieno. Si adatta anche alla realtà di aziende in crescita che desiderano una protezione robusta senza un onere operativo inutile.

I team che utilizzano infrastrutture gestite spesso beneficiano di avere ciò integrato nell'impostazione dell'hosting piuttosto che aggiunto in seguito. Questo è uno dei motivi per cui provider come kodu.cloud pongono tanta enfasi sul supporto operativo, sulla gestione dei backup e sulla riduzione dei punti di guasto prima che diventino incidenti stressanti.

Quindi, dovresti eseguire il backup dei tuoi backup?

Se i dati sono importanti, se l'inattività costa denaro, o se il tuo backup attuale risiede in un singolo dominio di guasto, allora sì. Non hai bisogno di copie infinite. Hai bisogno di un percorso di recupero indipendente in più rispetto a quello attuale.

Un backup non dovrebbe essere trattato come una casella da spuntare. È parte della continuità operativa. La configurazione più sicura non è quella con il maggior numero di copie. È quella che funziona ancora quando il primo piano fallisce.

Quando rivedi la tua infrastruttura, non fermarti a chiedere se esistono dei backup. Chiedi se questi backup possono sopravvivere a errori, attacchi, interruzioni e tempi sfortunati. È qui che solitamente emerge la vera risposta.

Andres Saar, Ingegnere Assistenza Clienti