Strategie di disaster recovery efficaci per PMI

Un gestionale che non risponde, un e-commerce irraggiungibile o un database corrotto non sono soltanto problemi tecnici. Bloccano ordini, assistenza, fatturazione e lavoro interno. Le strategie di disaster recovery efficaci servono a riportare i sistemi in funzione entro tempi compatibili con l'operatività dell'azienda, senza affidarsi a procedure improvvisate quando il danno è già avvenuto.

Per una PMI, disaster recovery non significa costruire una seconda infrastruttura identica per ogni applicazione. Significa conoscere le dipendenze reali dei propri servizi, stabilire quali dati e processi sono prioritari, predisporre copie recuperabili e verificare che il ripristino funzioni davvero. La differenza è rilevante: avere dei backup non equivale ad avere un piano di ripartenza.

Da quali rischi deve ripartire l'azienda

Il disaster recovery viene spesso associato a eventi eccezionali, come l'incendio di una sede o il guasto completo di un data center. Nella pratica, le interruzioni più frequenti hanno cause molto meno spettacolari: un aggiornamento applicativo con effetti non previsti, la cancellazione accidentale di dati, un disco pieno, una configurazione errata di Nginx, una credenziale compromessa o un ransomware che cifra file e database.

Un piano utile non parte quindi dalla tecnologia scelta, ma dagli scenari plausibili. Un CRM può essere disponibile ma contenere dati incoerenti. Un server può essere raggiungibile mentre l'applicazione Laravel non riesce più a collegarsi al database. Un e-commerce può rimanere online, ma non elaborare pagamenti o aggiornare le giacenze. In tutti questi casi, il ripristino dell'infrastruttura da solo non basta.

Occorre mappare i servizi che sostengono le attività aziendali e le loro dipendenze: applicazione, database, storage dei documenti, code, servizi di posta, DNS, API di terze parti, sistemi di autenticazione e integrazioni con gestionali o corrieri. Senza questa visione, si rischia di ripristinare componenti tecnicamente sane ma inutilizzabili dal punto di vista operativo.

RTO e RPO: le due decisioni che guidano il piano

Ogni piano di disaster recovery dovrebbe definire due parametri prima di parlare di backup o cloud. L'RTO, Recovery Time Objective, stabilisce quanto tempo può passare prima che un servizio torni operativo. L'RPO, Recovery Point Objective, definisce quanti dati l'azienda può accettare di perdere, misurati rispetto all'ultimo punto di recupero disponibile.

Se un e-commerce gestisce ordini durante tutto il giorno, un RPO di 24 ore può essere inaccettabile: in caso di incidente, potrebbero mancare ordini, pagamenti e aggiornamenti di magazzino di un'intera giornata. Per un archivio documentale aggiornato raramente, lo stesso RPO potrebbe invece essere sostenibile. Allo stesso modo, un RTO di quattro ore può essere realistico per un portale interno, ma non per un sistema che supporta la vendita al pubblico.

Questi valori devono essere concordati con chi conosce le conseguenze operative, non decisi esclusivamente dal reparto IT. Un RTO molto basso richiede ridondanza, procedure automatizzate, monitoraggio e infrastrutture che hanno un costo. Un RPO vicino allo zero richiede replica o backup molto frequenti e introduce ulteriori aspetti da governare. Non esiste un valore corretto in assoluto: esiste un equilibrio tra impatto del fermo, rischio accettabile e investimento necessario.

Una classificazione pratica delle priorità

Per evitare piani troppo generici, è utile dividere i servizi in livelli. I sistemi critici sono quelli che fermano vendite, produzione, assistenza o obblighi normativi. I sistemi importanti rallentano l'attività ma consentono procedure temporanee. I sistemi differibili possono essere recuperati in un secondo momento senza un danno immediato.

La classificazione deve includere anche i dati. In un'applicazione gestionale, ad esempio, database e file allegati potrebbero avere priorità diverse ma essere indispensabili insieme per completare una pratica. In un e-commerce, il catalogo può essere ripristinato da una sorgente nota, mentre ordini, clienti e transazioni richiedono protezioni più strette. Considerare tutto critico porta a costi inutili; considerare tutto recuperabile con calma espone a fermate che l'azienda non può assorbire.

Backup: copia, isolamento e verificabilità

Il backup è la base del disaster recovery, ma diventa affidabile solo quando rispetta alcune condizioni concrete. Deve essere sufficientemente frequente rispetto all'RPO, conservato per un periodo coerente con il rischio e disponibile anche se il sistema principale viene compromesso.

La regola 3-2-1 resta una buona base operativa: almeno tre copie dei dati, su due tipi di supporto o ambienti distinti, con una copia esterna. In presenza di ransomware o accessi compromessi, è opportuno aggiungere immutabilità o protezioni equivalenti: una copia che un attaccante può cancellare o cifrare con le stesse credenziali dell'ambiente di produzione non è una reale garanzia.

Per applicazioni web e gestionali, non basta esportare il database. Vanno considerati anche file caricati dagli utenti, configurazioni, chiavi e segreti gestiti in modo sicuro, versioni dell'applicazione, job pianificati, code e istruzioni di deploy. Non tutti questi elementi devono finire nello stesso archivio, ma il team incaricato del ripristino deve sapere dove recuperarli e in quale ordine usarli.

Un punto spesso trascurato riguarda la coerenza. Un dump del database e una copia dei file eseguiti in momenti diversi possono produrre un'applicazione apparentemente funzionante ma con riferimenti mancanti o stati non allineati. In alcuni casi servono snapshot coordinati, backup applicativi o procedure che mettano temporaneamente in sicurezza le scritture. La scelta dipende dall'architettura e dal volume di transazioni.

Le strategie di disaster recovery efficaci non si limitano al backup

La modalità di recupero deve essere proporzionata al servizio. Per una piccola applicazione non critica, può essere sufficiente ricreare un VPS da configurazioni documentate, ripristinare il database e distribuire l'ultima versione stabile. Per un portale ad alta disponibilità, potrebbe essere necessario predisporre un ambiente secondario pronto a ricevere traffico, con replica dei dati e procedure di failover controllate.

Le opzioni più comuni hanno costi e tempi diversi. Il cold site riduce i costi, ma richiede più attività durante l'emergenza. Il warm site mantiene un ambiente parzialmente pronto e abbrevia il recupero. L'hot site punta a una continuità quasi immediata, ma comporta maggiore complessità, costi ricorrenti e più componenti da monitorare. Una PMI non deve adottare automaticamente l'opzione più avanzata: deve scegliere quella che soddisfa gli RTO e RPO definiti.

Anche Docker può aiutare, perché rende ripetibile il rilascio dei servizi, ma non elimina il problema dei dati, delle variabili di ambiente, della rete e delle dipendenze esterne. Un container si ricrea rapidamente; un processo di ripristino completo richiede che ogni elemento essenziale sia disponibile, documentato e verificato.

Il piano operativo deve indicare persone e decisioni

Durante un incidente, una documentazione tecnica dispersa tra chat, repository e appunti non è un piano. Serve un documento operativo accessibile anche in caso di indisponibilità dei sistemi principali, con istruzioni chiare e aggiornate.

Il piano dovrebbe chiarire chi può dichiarare un incidente, chi coordina le attività tecniche, chi comunica con direzione e utenti, chi valida il ritorno in esercizio e quali fornitori devono essere coinvolti. Deve inoltre contenere contatti aggiornati, accessi di emergenza custoditi in modo sicuro, procedure di escalation e una sequenza di ripristino basata sulle priorità aziendali.

La comunicazione merita attenzione specifica. Dire che il sistema è offline senza indicare impatto, prossima verifica e canale di aggiornamento genera confusione. D'altra parte, promettere tempi non verificati è un errore. Un messaggio efficace distingue i fatti dalle ipotesi e mantiene un ritmo di aggiornamento definito fino alla chiusura dell'incidente.

Testare il ripristino prima che serva

Il test è la parte che separa un piano plausibile da un piano affidabile. Ripristinare un backup in un ambiente isolato permette di verificare integrità, tempi effettivi, dipendenze dimenticate e istruzioni poco chiare. È anche l'unico modo per capire se RTO e RPO dichiarati sono realmente rispettabili.

Non tutti i test devono avere la stessa profondità. Un controllo periodico può verificare che backup e alert siano stati eseguiti correttamente. A intervalli pianificati, è utile effettuare un restore completo di database e file, avviare l'applicazione e validare le funzioni essenziali. Per i servizi più critici, un'esercitazione di failover o una simulazione di incidente coinvolge anche le persone, non solo i server.

Dopo ogni test, vanno registrati tempi, anomalie e azioni correttive. Se il ripristino richiede una modifica manuale non documentata, il piano non è ancora pronto. Se un backup risulta integro ma mancano credenziali, configurazioni o autorizzazioni per rimettere online il servizio, il risultato è lo stesso: il recupero rallenta quando ogni minuto conta.

Sicurezza e disaster recovery devono procedere insieme

Un piano di recupero non sostituisce la prevenzione. Patch applicative e di sistema, controllo degli accessi, autenticazione a più fattori, segmentazione, monitoraggio e gestione delle vulnerabilità riducono la probabilità che il piano debba essere attivato. Tuttavia, nessuna misura preventiva elimina completamente il rischio di errore umano, guasto o compromissione.

In caso di sospetto ransomware o accesso illecito, il ripristino deve essere preceduto dall'analisi della causa e dal contenimento. Rimettere online una macchina dalla copia sbagliata o con credenziali già compromesse può reintrodurre il problema. Occorre individuare un punto di recupero affidabile, ruotare le credenziali esposte e verificare che la vulnerabilità sfruttata sia stata corretta prima del ritorno in produzione.

Per aziende che affidano a un unico partner sviluppo, server e sicurezza, questo coordinamento riduce i passaggi tra fornitori e rende più chiara la responsabilità operativa. Noventra lavora proprio su questa continuità tra codice, infrastruttura e manutenzione: il vantaggio non è avere più tecnologia, ma sapere come ripristinarla in modo controllato.

Un piano di disaster recovery ben costruito non deve impressionare per numero di pagine. Deve consentire a persone competenti di prendere decisioni rapide, recuperare dati verificati e far ripartire prima ciò che mantiene l'azienda operativa. Il momento giusto per scoprire se funziona è una prova pianificata, non il primo giorno di fermo.