Immagina di arrivare in ufficio lunedì mattina. Accendi il server, ma lo schermo resta nero o, peggio, appare quel messaggio che ogni amministratore di sistema teme: i tuoi file sono criptati da un ransomware.

A questo punto, la prima domanda che ti poni è: "Ma io ho fatto il backup!". Molti imprenditori e IT manager dormono sonni tranquilli convinti che avere una copia dei dati su un disco esterno o in cloud sia sufficiente. Sbagliato.

Avere i dati non significa poter lavorare. Proprio così.

La trappola del "ho fatto il backup"

C'è un malinteso pericoloso che circola nelle aziende: pensare che il backup e il backup disaster recovery siano la stessa cosa. Non lo sono. Il backup è l'atto di copiare i dati. È una fotografia istantanea di file, database e configurazioni.

Il Disaster Recovery (DR), invece, è l'intera strategia per rimettere in piedi l'azienda dopo un disastro. Parliamo di tempi, processi, infrastrutture di riserva e persone che sanno esattamente cosa fare quando tutto va a rotoli.

Un dettaglio non da poco: se hai 10 Terabyte di backup ma ci vogliono tre giorni per scaricarli e configurarli sul nuovo hardware, la tua azienda è ferma per tre giorni. Puoi permettertelo?

Probabilmente no. Ed è qui che entra in gioco la differenza tra sopravvivere a un incidente e soccombere nonostante i backup.

RTO e RPO: le due metriche che decidono il tuo destino

Quando si progetta una strategia di backup disaster recovery, non si parla di "velocità", ma di parametri tecnici precisi. Se non li definisci, stai navigando a vista.

Il primo è l'RPO (Recovery Point Objective). In parole povere: quanta perdita di dati puoi accettare? Se fai il backup una volta al giorno alle 20:00 e il server crasha alle 17:00 del giorno dopo, hai perso quasi un'intera giornata di lavoro. Per alcuni è accettabile, per chi gestisce transazioni finanziarie in tempo reale è un suicidio.

Poi c'è l'RTO (Recovery Time Objective). Questo indica quanto tempo può stare ferma la tua attività prima che il danno diventi irreparabile. Un'ora? Quattro ore? Due giorni?

L'obiettivo di una strategia avanzata è spingere entrambi questi valori verso lo zero.

Le diverse strategie: dal nastro al Cloud IaaS

C'è chi usa ancora i nastri LTO. Hanno il loro fascino, sono sicuri (perché fisicamente staccati dalla rete), ma sono lenti come una tartaruga zoppa in un mondo che corre a gigabit al secondo.

Oggi si punta su soluzioni ibride. Il cloud è fondamentale, certo, ma non deve essere l'unica ancora di salvezza. La regola d'oro rimane il 3-2-1: tre copie dei dati, su due supporti diversi, di cui una off-site (fuori sede).

Ma andiamo oltre. Esistono diverse modalità di DR:

  • Cold Site: Uno spazio fisico con infrastruttura minima. Devi portarci l'hardware e i backup. È economico, ma lentissimo da attivare.
  • Warm Site: L'hardware c'è ed è configurato, ma i dati non sono aggiornati in tempo reale. Più veloce, ma richiede comunque un intervento manuale di sincronizzazione.
  • Hot Site: Una replica speculare della tua infrastruttura che gira in parallelo. Se il sito A cade, il sito B prende il comando in pochi secondi. Costoso? Sì. Indispensabile per i servizi critici? Assolutamente.

La scelta dipende dal valore del tuo tempo.

Ransomware: il nemico che mangia anche i backup

Oggi non parliamo più di incendi o alluvioni, anche se sono possibili. Il vero pericolo è il malware moderno. I ransomware intelligenti non criptano solo i tuoi server attivi; cercano attivamente le condivision'i di rete dove tieni i backup per distruggere anche quelli.

Se il tuo sistema di backup è collegato alla rete senza protezioni, non hai un backup: hai solo un altro file da far criptare all'hacker.

L'unica soluzione reale è l'immutabilità. I dati immutabili sono scritti in modo che nessuno, nemmeno l'amministratore di sistema (o il virus che ha rubato le sue credenziali), possa modificarli o cancellarli per un periodo prestabilito.

È come scrivere il cemento invece che usare la matita. Una volta scritto, resta lì. Questo è il vero cuore della cybersecurity moderna applicata al disaster recovery.

Perché testare il piano di ripristino (e perché quasi nessuno lo fa)

Scrivere un manuale di Disaster Recovery e riporlo in un cassetto non serve a nulla. È come avere un estintore scaduto: ti dà l'illusione della sicurezza finché non scoppia il fuoco.

Un piano di backup disaster recovery che non viene testato regolarmente è, per definizione, un piano che fallirà.

Cosa significa testare? Significa simulare un crash. Spegnere un server critico senza preavviso e cronometrare quanto tempo ci vuole per tornare operativi. Scoprire che il backup di quel database fondamentale non funziona è frustrante, ma farlo durante un test è un successo; scoprirlo durante un'emergenza è una tragedia.

I test rivelano i colli di bottiglia: password dimenticate, configurazioni di rete errate o, semplicemente, l'assenza di un driver aggiornato sul nuovo hardware.

L'approccio strategico per 428.it

Non esiste una soluzione universale che vada bene per tutti. Un piccolo studio professionale non ha le stesse esigenze di una fabbrica automatizzata con centinaia di nodi IoT.

La chiave è l'analisi dell'impatto aziendale (BIA - Business Impact Analysis). Bisogna mappare ogni singolo servizio: cosa succede se cade il CRM? E se sparisce l'accesso alla posta elettronica? Quale processo deve ripartire per primo?

Solo dopo questa analisi si può costruire un'architettura di backup che sia efficiente e non un semplice costo mensile pagato a un fornitore cloud.

La sicurezza non è un prodotto, ma un processo continuo.

Investire in una strategia di disaster recovery non significa spendere soldi per qualcosa che speri di non usare mai. Significa comprare l'assicurazione sulla vita della tua azienda. Perché i dati sono il sangue dell'impresa e, quando smettono di scorrere, tutto si ferma.