Ogni azienda, prima o poi, si trova a dover affrontare un imprevisto informatico: un guasto hardware, un errore umano, un ransomware, un blackout elettrico o più semplicemente un aggiornamento andato storto.
Eppure, ancora oggi, molte PMI italiane continuano a confondere il backup con il disaster recovery, credendo che avere una copia dei dati significhi automaticamente poter ripartire in tempi rapidi. Purtroppo non è così.
Secondo il rapporto Cyber Index PMI 2025, soltanto una parte delle piccole e medie imprese italiane dispone di piani realmente evoluti di ripristino dei servizi, mentre molte organizzazioni adottano ancora procedure manuali o non hanno definito una strategia strutturata di disaster recovery. Parallelamente, l’Agenzia per la Cybersicurezza Nazionale continua a sottolineare l’importanza della business continuity come elemento fondamentale della resilienza digitale delle organizzazioni.
Per progettare una strategia efficace esistono alcune parole chiave che ogni imprenditore e responsabile IT dovrebbe conoscere bene.
Disaster Recovery
Il Disaster Recovery (DR) è l’insieme di processi, tecnologie e procedure che consentono di riportare operativi sistemi, applicazioni e dati dopo un evento critico.
Non coincide con il backup.
Un backup rappresenta semplicemente una copia dei dati; il disaster recovery comprende invece tutto ciò che serve per far ripartire l’azienda: infrastrutture, server, reti, applicazioni, configurazioni, verifiche e procedure operative.
In altre parole:
- Backup = “salvo una copia dei dati”.
- Disaster Recovery = “rendo di nuovo operativa l’azienda”.
Business continuity
La Business Continuity è un concetto ancora più ampio.
Non riguarda soltanto l’informatica, ma la capacità dell’organizzazione di continuare a fornire prodotti e servizi anche durante una crisi.
Il disaster recovery rappresenta quindi uno dei pilastri della business continuity, insieme agli aspetti organizzativi, logistici, comunicativi e procedurali.
RTO (Recovery Time Objective)
L’RTO indica il tempo massimo di inattività accettabile.
In pratica risponde alla domanda:
“Quanto tempo posso permettermi di restare fermo?”
Alcuni esempi:
- Un e-commerce che fattura migliaia di euro all’ora potrebbe richiedere un RTO di 15 minuti.
- Un gestionale amministrativo potrebbe tollerare 2 ore.
- Un archivio storico consultato raramente potrebbe avere un RTO di 24 ore.
Definire un RTO realistico è fondamentale perché influenza direttamente l’architettura tecnica e il costo della soluzione.
RPO (Recovery Point Objective)
L’RPO rappresenta invece la quantità massima di dati che l’azienda è disposta a perdere, espressa come intervallo temporale.
La domanda è:
“Se succede un disastro, quanto lavoro posso accettare di perdere?”
Se il backup viene eseguito una volta al giorno, l’RPO è pari a 24 ore: nel peggiore dei casi potrebbero andare persi tutti i dati prodotti dall’ultimo salvataggio.
Se invece viene effettuata una replica continua dei dati, l’RPO può ridursi a pochi minuti o addirittura avvicinarsi allo zero.
MTD (Maximum Tolerable Downtime)
Il Maximum Tolerable Downtime (MTD) rappresenta il tempo massimo oltre il quale l’interruzione dell’attività provoca danni economici, organizzativi o reputazionali non più sostenibili.
È un parametro di business, non tecnico.
L’RTO dovrebbe sempre essere inferiore al MTD: se il sistema impiega più tempo a riprendersi rispetto alla soglia massima tollerabile, il piano di disaster recovery non è adeguato.
RTA (Recovery Time Actual)
Mentre l’RTO è un obiettivo teorico, il Recovery Time Actual (RTA) misura il tempo realmente impiegato durante un incidente o un test di ripristino.
Confrontare RTA e RTO permette di capire se il piano funziona davvero o se esiste uno scostamento da correggere.
Failover
Il failover consiste nel trasferimento automatico dei servizi da un sistema principale a uno secondario quando viene rilevato un guasto.
L’utente spesso non si accorge nemmeno del passaggio.
Questa tecnica è utilizzata nei sistemi ad alta disponibilità e nei servizi mission-critical, dove anche pochi minuti di inattività possono avere conseguenze economiche rilevanti.
Failback
Terminata l’emergenza, il failback è il processo inverso: il ritorno controllato dei servizi dall’infrastruttura temporanea a quella principale.
Anche questa fase richiede pianificazione e test accurati per evitare ulteriori interruzioni.
Replica dei dati
Molti moderni sistemi di disaster recovery utilizzano meccanismi di replica, sincronizzando continuamente dati e configurazioni verso una sede secondaria.
La replica può essere:
- sincrona, con perdita di dati praticamente nulla ma costi elevati;
- asincrona, più economica ma con un RPO maggiore.
La scelta dipende sempre dalle esigenze operative dell’azienda.
Cold Site, Warm Site e Hot Site
Quando si parla di sito alternativo di ripristino, si distinguono generalmente tre livelli.
Cold Site. È uno spazio predisposto ma sostanzialmente vuoto, da allestire in caso di emergenza. Costa poco ma richiede tempi di ripartenza lunghi.
Warm Site. Dispone già di parte delle infrastrutture necessarie, consentendo un ripristino relativamente rapido. Rappresenta spesso un buon compromesso per molte PMI.
Hot Site. È un ambiente completamente operativo e costantemente sincronizzato con quello principale. Permette tempi di ripristino molto ridotti ma comporta investimenti decisamente superiori.
Immutable Backup
Negli ultimi anni si è diffuso il concetto di backup immutabile, cioè una copia che non può essere modificata né cancellata per un determinato periodo.
Questa tecnologia è diventata fondamentale contro gli attacchi ransomware, che spesso tentano di cifrare anche i backup tradizionali prima di colpire i sistemi di produzione.
Test di Disaster Recovery
Un piano non testato è poco più di un documento.
Le aziende più mature effettuano simulazioni periodiche per verificare che:
- i backup siano realmente ripristinabili;
- i tempi dichiarati di RTO siano rispettati;
- il personale conosca le procedure;
- le applicazioni funzionino correttamente dopo il recupero.
Molte organizzazioni scoprono solo durante un incidente reale che il proprio backup era inutilizzabile o incompleto.
La domanda più importante non è “Li facciamo i backup?”
Quando incontro un nuovo cliente, raramente chiedo se esegue copie di sicurezza. La risposta è quasi sempre sì.
La domanda davvero importante è un’altra: “Quanto tempo possiamo permetterci di restare fermi e quanti dati siamo disposti a perdere?”
Da quella risposta nascono tutte le decisioni tecniche successive: frequenza dei backup, replica geografica, infrastrutture ridondate, test periodici, monitoraggio e automazione.
Perché un backup senza una strategia di disaster recovery è come avere una ruota di scorta senza il cric: il giorno in cui servirà davvero, potrebbe non bastare per rimettere in moto il vostro business.
