Un fermo di produzione non inizia sempre in reparto. Può partire da un ransomware che cifra il gestionale, da un guasto elettrico nel data center, da una configurazione cloud errata o da un collegamento indisponibile tra sede, magazzino e stabilimento. Per una PMI manifatturiera, scegliere le migliori soluzioni disaster recovery significa definire in anticipo come ripristinare persone, dati, applicazioni e processi critici prima che un incidente diventi una perdita di fatturato, clienti e credibilità.
Il punto non è possedere una copia dei dati. Il punto è tornare operativi nei tempi che il business può sostenere, con dati sufficientemente aggiornati e con procedure che funzionino anche sotto pressione. Questo richiede una progettazione basata sui flussi reali dell’azienda: ordini, pianificazione della produzione, MES, ERP, distinte base, tracciabilità, documenti tecnici, sistemi di qualità e piattaforme di relazione con clienti e fornitori.
Migliori soluzioni disaster recovery: partire dall’impatto operativo
Una soluzione di disaster recovery efficace non si sceglie confrontando soltanto capacità di storage, prezzi per gigabyte o promesse di ripristino. Si sceglie valutando il costo di ogni ora di indisponibilità per ciascun processo aziendale.
Un ERP non disponibile può bloccare l’emissione di ordini, fatture e documenti di trasporto. Un MES fermo può interrompere l’avanzamento della produzione o rendere incompleta la raccolta dati. Se non sono accessibili file tecnici, versioni di disegni e specifiche di lavorazione, l’operatività può rallentare anche quando le macchine sono tecnicamente disponibili. La priorità, quindi, non coincide sempre con il sistema più costoso o più visibile.
La prima attività utile è una Business Impact Analysis. Per ogni applicazione e dipendenza tecnologica, l’azienda deve stabilire quali conseguenze produce il fermo, quali reparti coinvolge, quali procedure manuali temporanee sono realistiche e dopo quanto tempo il danno diventa non accettabile. Da qui derivano due parametri decisivi.
Il Recovery Time Objective, o RTO, indica entro quanto tempo un servizio deve essere nuovamente disponibile. Il Recovery Point Objective, o RPO, definisce invece quanta perdita di dati è tollerabile, misurata nel tempo. Un RPO di quattro ore, per esempio, implica che dopo un incidente potrebbero andare persi fino a quattro ore di modifiche, registrazioni o transazioni.
RTO e RPO non possono essere uguali per tutto. Un file server di reparto, un ERP e un sistema di acquisizione dati di linea hanno priorità e costi di ripristino diversi. Trattare ogni carico di lavoro come critico porta a investimenti sproporzionati. Trattarli tutti allo stesso modo con backup notturni crea invece un rischio che emerge solo quando è troppo tardi.
Le architetture da valutare per una PMI industriale
Non esiste una soluzione universale. La scelta dipende dall’architettura esistente, dai vincoli di connettività, dalla criticità degli impianti e dai tempi di ripartenza richiesti. Nella maggior parte delle PMI, la scelta migliore è un modello ibrido: dati e applicazioni locali dove servono prestazioni, integrazione con macchinari o continuità di fabbrica, affiancati da risorse cloud per replica, ripristino e scalabilità.
Backup immutabile e ripristino verificato
Il backup resta il primo livello di difesa, ma deve essere progettato per resistere agli incidenti moderni. Una copia collegata in modo permanente alla rete e modificabile con le stesse credenziali dell’ambiente produttivo può essere cifrata o cancellata da un attaccante.
Per questo, una strategia solida combina copie locali per recuperi rapidi, una copia esterna o nel cloud e almeno una copia immutabile, non alterabile per un periodo definito. È un’applicazione concreta del principio 3-2-1-1-0: tre copie dei dati, su due supporti diversi, una copia fuori sede, una immutabile e zero errori rilevati attraverso verifiche.
Il backup, da solo, non garantisce il disaster recovery. Occorre sapere se i dati sono leggibili, se le macchine virtuali si avviano, se le dipendenze applicative vengono rispettate e se il ripristino dell’ERP include database, configurazioni, integrazioni e autorizzazioni. Un backup mai testato è un’ipotesi, non una garanzia operativa.
Disaster recovery in cloud e DRaaS
Il Disaster Recovery as a Service, o DRaaS, replica sistemi selezionati in un ambiente cloud pronto a ospitare temporaneamente i carichi di lavoro in caso di indisponibilità della sede primaria. Può offrire un buon equilibrio tra velocità di ripristino e investimento iniziale, soprattutto per aziende che non vogliono sostenere i costi di un secondo data center proprietario.
Il vantaggio è la possibilità di attivare risorse di calcolo quando servono davvero. Il limite è che il progetto deve considerare banda disponibile, tempi di replica, configurazione delle reti, accessi remoti, licenze software e prestazioni richieste. Un ambiente di emergenza poco dimensionato può rendere disponibili le applicazioni senza consentire al personale di lavorare a ritmi accettabili.
Per un’azienda con sedi negli Stati Uniti e in Italia, o con clienti e filiere internazionali, è inoltre necessario verificare dove risiedono dati e repliche, quali requisiti contrattuali o normativi si applicano e come vengono gestiti accessi, identità e tracciabilità delle operazioni.
Secondo sito e replica ad alta disponibilità
Quando il fermo tollerabile è molto breve e i processi non possono dipendere esclusivamente dalla connettività internet, un secondo sito può essere una scelta appropriata. La replica dei sistemi su infrastruttura separata riduce la dipendenza da un singolo edificio, da un singolo cluster o da una singola area geografica.
È una soluzione indicata per carichi molto critici, ma comporta costi e complessità maggiori: hardware, gestione, patching, controlli di sicurezza, aggiornamento delle procedure e test di failover. Non è automaticamente la scelta migliore per tutte le applicazioni. Spesso conviene riservarla ai sistemi che incidono direttamente su produzione, sicurezza, tracciabilità o obblighi contrattuali.
Proteggere anche le dipendenze invisibili
Nei progetti di disaster recovery, il rischio più frequente è concentrarsi sul singolo server anziché sul servizio completo. Un’applicazione può essere ripristinata, ma restare inutilizzabile se mancano DNS, Active Directory, VPN, certificati, database, storage condiviso, code di integrazione o collegamenti con sistemi esterni.
In ambito manifatturiero, questa valutazione deve estendersi all’intersezione tra IT e OT. PLC e macchinari non vanno trattati come normali server, ma possono dipendere da postazioni di supervisione, historian, gateway industriali, configurazioni di rete e software proprietari. La protezione delle configurazioni, delle versioni software e delle procedure di riavvio è essenziale quanto la copia dei dati amministrativi.
Un piano concreto deve definire l’ordine di ripristino. Prima identità e rete, poi servizi di base, database e applicazioni critiche, infine integrazioni e servizi accessori. Questo ordine riduce gli interventi improvvisati e aiuta il management a comunicare con precisione cosa sarà disponibile, per chi e in quali tempi.
Come scegliere le migliori soluzioni disaster recovery
La selezione dovrebbe partire da quattro criteri operativi:
- criticità del processo e costo orario del fermo;
- RTO e RPO richiesti per ogni gruppo di applicazioni;
- dipendenze tra sistemi, sedi, utenti remoti e tecnologie di stabilimento;
- capacità dell’organizzazione di gestire, testare e aggiornare il piano nel tempo.
A questi elementi vanno aggiunti cybersecurity e governance. La segmentazione di rete, l’autenticazione a più fattori, il controllo degli account privilegiati e il monitoraggio degli eventi sono parte della capacità di recupero. Se un attaccante mantiene l’accesso all’ambiente, ripristinare i sistemi senza rimuovere la causa dell’incidente può significare compromettere nuovamente l’operatività in poche ore.
La documentazione deve essere utilizzabile, non solo conforme. Contatti di escalation, responsabilità, runbook tecnici, criteri per dichiarare il disastro, comunicazioni a clienti e fornitori, procedure per il lavoro temporaneo: tutto deve essere accessibile anche se i sistemi principali sono indisponibili. Una copia offline e ruoli chiaramente assegnati fanno una differenza sostanziale durante le prime ore dell’emergenza.
Il test è il vero indicatore di affidabilità
Un piano di disaster recovery produce valore solo quando viene provato. I test non devono limitarsi a controllare che una copia esista: devono verificare il recupero di un’applicazione completa, l’accesso degli utenti, l’integrità dei dati e la continuità delle integrazioni più rilevanti.
Un approccio progressivo è spesso il più sostenibile. Si può iniziare con test di restore periodici, proseguire con esercitazioni su applicazioni prioritarie e arrivare a simulazioni di failover controllato. Ogni test deve produrre evidenze: tempi reali di recupero, problemi rilevati, decisioni prese e azioni correttive con un responsabile e una scadenza.
INGENIA affronta questi progetti collegando infrastruttura, cybersecurity, applicazioni e processi industriali. L’obiettivo non è aggiungere una piattaforma isolata, ma costruire un percorso di ripristino coerente con ERP, software custom, dati di produzione e priorità economiche dell’impresa.
La domanda più utile non è quale tecnologia acquistare, ma quale capacità di ripartenza l’azienda vuole poter dimostrare. Quando RTO, RPO, ruoli e test sono definiti sui processi reali, il disaster recovery smette di essere un costo difensivo e diventa una condizione concreta per crescere senza esporre l’operatività a rischi evitabili.
