Un backup immutabile vs tradizionale non è una scelta tra due semplici tecnologie di archiviazione. È una scelta sul livello di controllo che l'organizzazione mantiene quando un ransomware, un errore umano, un guasto o un accesso non autorizzato colpiscono dati e sistemi essenziali. Se la copia di sicurezza può essere modificata o cancellata insieme ai dati di produzione, il piano di ripristino rischia di fallire proprio nel momento in cui serve.
Per un'impresa, uno studio professionale, un ente o un'associazione, il problema non è solo perdere file. Significa poter fermare fatturazione, prenotazioni, gestione clienti, produzione, servizi ai cittadini o attività amministrative. Proteggi i tuoi dati. Proteggi la tua azienda.
Che cos'è un backup tradizionale
Il backup tradizionale crea una copia di dati, applicazioni, macchine virtuali o database su un supporto differente rispetto all'ambiente principale. Può risiedere su NAS, disco esterno, server remoto, cloud o nastro. È una componente necessaria della continuità operativa e, se progettato correttamente, consente di ripristinare informazioni cancellate, versioni precedenti di documenti e sistemi danneggiati.
Il suo limite dipende dalle autorizzazioni. In molti contesti la copia è gestita con account amministrativi che possono riscrivere, cifrare o eliminare i dati di backup. È una condizione pratica, spesso accettata per ragioni di semplicità, ma espone a un rischio rilevante: un attaccante che ottenga privilegi elevati può tentare di colpire prima le copie e poi i sistemi produttivi.
Non significa che ogni backup tradizionale sia inefficace. Un repository ben separato, con credenziali dedicate, segmentazione di rete e procedure di verifica, può offrire una protezione concreta. Tuttavia, la sua resistenza dipende dalla corretta configurazione e dalla capacità di impedire modifiche indesiderate durante un incidente.
Backup immutabile vs tradizionale: la differenza decisiva
Un backup immutabile introduce un vincolo tecnico: per un periodo definito, i dati salvati non possono essere modificati né eliminati, nemmeno da chi dispone di normali privilegi amministrativi. Il meccanismo può essere realizzato con tecnologie WORM, con blocco degli oggetti nel cloud, con repository protetti o con supporti progettati per rispettare regole di conservazione.
L'immutabilità non rende i dati invulnerabili in senso assoluto. Rende però più difficile per un ransomware cancellare o cifrare le copie già consolidate. Se l'infrastruttura principale viene compromessa, l'organizzazione può disporre di un punto di ripristino affidabile, precedente all'attacco e non alterato dall'aggressore.
La distinzione è quindi operativa. Nel backup tradizionale ci si domanda se una copia esista e sia accessibile. Nel backup immutabile occorre verificare anche se la copia possa essere alterata prima della scadenza della retention. Questa seconda garanzia è particolarmente rilevante quando l'attacco rimane nascosto per giorni o settimane, contaminando copie successive senza essere rilevato.
Perché il ransomware prende di mira le copie di sicurezza
Gli attacchi ransomware più dannosi non si limitano a cifrare i documenti condivisi. Cercano credenziali amministrative, esplorano la rete, individuano console di backup e repository, disattivano servizi o cancellano punti di ripristino. L'obiettivo è aumentare la pressione economica: senza una copia recuperabile, il pagamento del riscatto può apparire come l'unica alternativa, pur senza alcuna certezza di recupero o riservatezza dei dati sottratti.
Un backup immutabile modifica questo scenario, ma deve essere inserito in un disegno più ampio. Se le credenziali sono deboli, se l'accesso remoto è esposto, se non esiste monitoraggio o se la rete è priva di segmentazione, l'incidente può comunque fermare l'operatività. La copia immutabile è una difesa di recupero, non sostituisce la prevenzione.
Per le organizzazioni soggette a obblighi di riservatezza o che trattano dati personali, il danno può essere doppio: indisponibilità dei servizi e possibile violazione dei dati. La capacità di ricostruire sistemi e informazioni in modo documentato riduce tempi, incertezza e impatto reputazionale, ma non elimina gli obblighi di valutazione e gestione dell'eventuale data breach.
I vantaggi concreti dell'immutabilità
Il primo vantaggio è la maggiore affidabilità del ripristino. Una copia bloccata secondo una retention definita offre un riferimento tecnico che un errore, una cancellazione accidentale o un attacco non dovrebbe poter modificare. Il secondo è la riduzione del rischio negoziale durante un incidente: disporre di alternative verificabili consente di decidere con maggiore lucidità e di concentrare le risorse sul contenimento e sul recupero.
Il terzo vantaggio riguarda la governance. Definire tempi di conservazione, ruoli di accesso, repository e test porta l'organizzazione a chiarire quali dati siano davvero critici. Spesso questa analisi fa emergere archivi non censiti, dipendenze da fornitori, software privi di esportazione o procedure manuali che rendono il ripristino più lento del previsto.
Esistono però anche costi e vincoli. L'immutabilità richiede capacità di archiviazione pianificata, perché non è possibile liberare anticipatamente lo spazio occupato dalle copie bloccate. Una retention troppo lunga può aumentare costi e complessità; una retention troppo breve potrebbe non coprire un attacco scoperto in ritardo. La durata deve derivare da una valutazione del rischio, non da un'impostazione predefinita.
Quando il backup tradizionale può essere sufficiente
Per dati non critici, ambienti di test o archivi facilmente ricostruibili, un backup tradizionale ben gestito può essere proporzionato. Anche una piccola organizzazione con budget limitato può ottenere un miglioramento significativo separando le copie dal sistema operativo, usando account dedicati e verificando periodicamente i ripristini.
La scelta cambia quando sono presenti database gestionali, posta elettronica, documentazione sanitaria o legale, dati contabili, applicazioni su misura, file di progetto, sistemi di prenotazione o servizi che non possono restare inattivi a lungo. In questi casi la domanda non è soltanto quanto costa conservare una copia immutabile, ma quanto costa un giorno, una settimana o un mese di fermo operativo.
La soluzione più efficace è spesso ibrida. Le copie locali possono garantire velocità di ripristino per incidenti ordinari, mentre una copia immutabile esterna o logicamente separata protegge dagli eventi più gravi. Non esiste un unico prodotto adatto a tutti: contano il volume dei dati, la connettività, i tempi accettabili di fermo, le applicazioni coinvolte e le competenze disponibili per la gestione.
Progettare una strategia che possa essere davvero ripristinata
Una progettazione seria parte da due parametri. Il Recovery Point Objective, o RPO, definisce quanta perdita di dati è tollerabile: un'ora, un giorno, una settimana. Il Recovery Time Objective, o RTO, stabilisce invece entro quanto tempo un servizio deve tornare operativo. Un database di prenotazioni può richiedere un RPO molto basso; un archivio storico potrebbe tollerare copie meno frequenti.
Un riferimento utile è la regola 3-2-1-1-0: almeno tre copie dei dati, su due tipologie di supporto, con una copia esterna, una copia offline o immutabile e zero errori verificati nei controlli di ripristino. Non è una formula da applicare meccanicamente, ma un criterio efficace per evitare che tutte le copie dipendano dallo stesso dispositivo, dallo stesso edificio o dalle stesse credenziali.
Una strategia completa dovrebbe considerare almeno questi elementi:
- inventario dei dati, dei sistemi e delle dipendenze realmente critiche;
- frequenza delle copie coerente con RPO e operatività;
- retention differenziata per dati operativi, archivi e obblighi documentali;
- account separati, autenticazione forte e accessi amministrativi tracciati;
- test documentati di ripristino di file, database, macchine e servizi completi;
- procedure di incident response che indichino chi decide, chi comunica e come isolare l'ambiente compromesso.
Il test merita particolare attenzione. Un backup completato con esito positivo non prova che un'applicazione tornerà a funzionare. Occorre verificare integrità dei dati, tempi effettivi, dipendenze di rete, licenze software, configurazioni e credenziali. Nei sistemi più importanti, il test deve simulare il ripristino dell'intero servizio, non solo l'apertura di un singolo file.
Immutabilità, GDPR e tempi di conservazione
Il blocco tecnico delle copie deve essere compatibile con una politica di conservazione definita. L'immutabilità non autorizza a trattenere dati personali senza limiti: impone piuttosto di stabilire prima tempi, finalità, misure di sicurezza e procedure per gestire le richieste interessate, tenendo conto delle particolarità delle copie di backup.
In pratica, i backup non sono un archivio operativo da consultare liberamente. Devono essere accessibili a personale autorizzato, protetti da cifratura quando appropriato e inclusi nel registro delle misure organizzative e tecniche. Quando una copia raggiunge la scadenza prevista, la sua eliminazione deve avvenire secondo il ciclo definito dalla tecnologia adottata. Per contesti regolati o con dati sensibili, la progettazione va coordinata con le responsabilità privacy e con l'analisi del rischio.
La scelta corretta parte dall'analisi, non dal prodotto
Acquistare spazio cloud o un appliance di backup non equivale a costruire una capacità di recupero. Prima occorre capire quali processi sostenere, quali dati proteggere, quali scenari affrontare e quali risorse attivare durante un'emergenza. Solo dopo ha senso selezionare tecnologia, retention, collocazione delle copie e modalità di gestione.
Un approccio ingegneristico consente di collegare la protezione dei dati alla continuità operativa, alla cybersecurity e alla conformità, evitando soluzioni isolate che funzionano sulla carta ma non durante un incidente. Per molte realtà, il passaggio più utile non è sostituire immediatamente tutto: è misurare il rischio, verificare le copie esistenti e correggere con priorità ciò che oggi impedirebbe un ripristino affidabile.
La domanda da porre al proprio sistema non è «abbiamo un backup?», ma «domani mattina, dopo un attacco, quale servizio possiamo ripristinare, con quali dati e in quanto tempo?». Da quella risposta nasce una protezione concreta.