Il momento peggiore per scoprire che il backup non funziona
È un lunedì mattina. Il server principale è giù. Il database aziendale è corrotto. Apri la console di ripristino e scopri che l'ultimo backup valido risale a tre settimane fa. Oppure che c'è, ma non hai mai testato il ripristino e ora non riesci a montarlo.
Questo scenario non è raro. È la norma per le aziende che hanno un backup "di nome" ma non una strategia "di fatto". Prima di vedere come costruirla, vale la pena chiarire due termini che vengono usati spesso come sinonimi ma non lo sono.
Cos'è il backup
Il backup è una copia dei dati, conservata in un luogo separato dal sistema originale. Può essere una copia del database, dei file, delle configurazioni di sistema, o di un'intera macchina virtuale.
L'obiettivo del backup è semplice: se i dati originali vengono persi, corrotti, o cancellati, puoi recuperarli dalla copia. La qualità di un backup si misura su due dimensioni — quanto è recente (quanti dati potresti perdere?) e quanto velocemente puoi ripristinarlo (quanto tempo ci vuole per tornare operativo?).
Un backup che non è mai stato testato non è un backup — è una speranza.
Cos'è il disaster recovery
Il disaster recovery è il processo completo che permette a un'organizzazione di tornare operativa dopo un evento catastrofico. Non riguarda solo i dati — riguarda i sistemi, le applicazioni, le infrastrutture, e le procedure necessarie per riprendere il lavoro.
Un evento di disaster recovery può essere un attacco ransomware, un guasto hardware, un errore umano che cancella dati critici, un incendio nel datacenter, o un'alluvione. In tutti questi casi, avere i backup non basta se non hai un piano preciso per usarli.
Qual è la differenza tra backup e disaster recovery?
La distinzione è più sottile di quanto sembri.
Il backup risponde alla domanda "ho una copia dei dati?". Il disaster recovery risponde alla domanda "so tornare operativo, e in quanto tempo?".
Puoi avere backup perfetti e un disaster recovery disastroso — se non hai mai pianificato in quale ordine ripristinare i sistemi, chi è responsabile di cosa, e qual è il tempo massimo accettabile di inattività. Il backup è uno strumento. Il disaster recovery è una strategia che include quel backup, e molto altro.
I due numeri che definiscono la tua strategia: RPO e RTO
Ogni piano di disaster recovery si costruisce attorno a due parametri che devi definire prima di scegliere qualsiasi strumento.
RPO (Recovery Point Objective) è la risposta alla domanda "quanti dati posso permettermi di perdere?". Se fai backup ogni 24 ore, il tuo RPO è 24 ore — in caso di disastro, potresti perdere fino a un giorno di lavoro. Per alcune aziende è accettabile. Per chi lavora con ordini, transazioni, o dati sanitari, può essere catastrofico.
RTO (Recovery Time Objective) è la risposta alla domanda "in quanto tempo devo tornare operativo?". Un e-commerce che sta giù 8 ore perde decine di migliaia di euro. Un'agenzia di consulenza può tollerare qualche ora in più. L'RTO determina quanto devi investire nell'infrastruttura di ripristino.
Senza RPO e RTO definiti, non hai una strategia — hai solo un hard disk con dei file sopra.
La regola 3-2-1 (e perché oggi non basta più)
La regola classica dice: tieni 3 copie dei dati, su 2 supporti diversi, con 1 copia offsite.
È un buon punto di partenza, ma nell'era del ransomware serve aggiornare il modello. Gli attacchi moderni prendono di mira anche i backup, crittografandoli prima ancora di colpire i sistemi principali. Per questo si parla oggi di regola 3-2-1-1-0:
- 3 copie totali
- 2 supporti diversi
- 1 copia offsite
- 1 copia air-gapped (isolata dalla rete, non raggiungibile da un attacco remoto)
- 0 errori verificati nei test di ripristino
L'ultimo punto è il più ignorato — e il più importante.
Cosa deve rientrare nel piano di backup
Un errore comune è fare il backup solo del database e dimenticare il resto. Un piano completo deve coprire:
- Dati applicativi e database
- Configurazioni di sistema e file di ambiente
- Certificati SSL e chiavi crittografiche
- Immagini delle VM o snapshot dei container
- Documentazione e procedure operative
- Email e comunicazioni aziendali critiche
Se devi ricostruire un server da zero senza la sua configurazione, il backup dei dati da solo non ti salva.
Backup su cloud: opportunità e attenzioni
I servizi cloud hanno reso il backup offsite accessibile anche alle PMI. Soluzioni come AWS S3, Azure Blob Storage o Backblaze B2 offrono costi ridotti, scalabilità e alta disponibilità.
Versioning e retention policy
Abilita sempre il versioning degli oggetti. In caso di ransomware che sovrascrive i file, puoi tornare a una versione precedente. Definisci anche per quanto tempo conservare le versioni storiche — non è gratis.
Crittografia
I dati devono essere cifrati sia in transito che a riposo. Gestisci le chiavi con attenzione: perderle equivale a perdere il backup.
Costi di egress
Fare il backup è economico. Scaricare terabyte in caso di ripristino può costare molto di più del previsto. Pianifica l'architettura dei dati prima, non dopo.
Testa il ripristino — sempre
Un backup non testato non è un backup.
Stabilisci un piano di test periodico: almeno una volta al trimestre esegui un ripristino completo in ambiente isolato. Verifica che i dati siano integri, che i sistemi si avviino correttamente, e che i tempi rispettino il tuo RTO.
Documenta ogni test. Se qualcosa non funziona, è meglio scoprirlo durante un esercizio controllato che durante un'emergenza reale.
Da dove iniziare
Se stai partendo da zero o vuoi rivedere la tua strategia attuale:
- Fai un inventario di cosa hai e cosa proteggi oggi
- Definisci RPO e RTO per ogni sistema critico
- Scegli strumenti e destinazioni di backup in base a quei requisiti
- Automatizza e monitora — un backup manuale è un backup che prima o poi non viene fatto
- Testa e aggiorna il piano almeno ogni sei mesi
La domanda giusta non è "hai un backup?" ma "sei sicuro di poter tornare operativo, e in quanto tempo?"