Un fermo di produzione, un gestionale non disponibile o una distinta base compromessa possono bloccare una PMI molto prima che il danno informatico sia quantificato. Le best practice backup per PMI non riguardano quindi il semplice salvataggio dei file: definiscono la capacità concreta di ripartire, con dati affidabili, tempi controllati e impatti limitati su clienti, fornitori e reparti produttivi.
Per un'azienda manifatturiera, il backup deve proteggere molto più delle cartelle condivise. ERP, MES, configurazioni di macchine, progetti CAD, database qualità, documentazione tecnica, posta elettronica e dati di log sono elementi interdipendenti. Se uno solo manca o viene ripristinato in una versione incoerente, la ripartenza può diventare lenta, manuale e rischiosa.
Best practice backup per PMI: partire dalla continuità operativa
La domanda corretta non è "dove copiamo i dati?", ma "quali processi dobbiamo riportare in funzione e in quanto tempo?". È questo cambio di prospettiva a separare un backup presente da un backup realmente utilizzabile.
Il primo passo consiste nel classificare dati e sistemi in base al loro impatto operativo. Un file marketing perso può essere recuperato con tempi più ampi rispetto al database dell'ERP, ai programmi PLC, agli ordini di produzione o alle informazioni che alimentano il magazzino. Ogni asset deve avere un proprietario interno, una frequenza di copia definita e una modalità di ripristino documentata.
Due parametri rendono questa valutazione misurabile. Il Recovery Time Objective, o RTO, indica entro quanto tempo un servizio deve tornare disponibile. Il Recovery Point Objective, o RPO, definisce invece quanta perdita di dati l'azienda può accettare. Un ERP con RPO di 24 ore può essere insufficiente se nell'arco della giornata vengono registrati ordini, avanzamenti e movimentazioni critiche. Al contrario, pretendere un RPO di pochi minuti per ogni archivio può generare costi e complessità non giustificati.
La scelta dipende dai processi reali, non da uno standard astratto. Una PMI con vendita internazionale, filiali negli Stati Uniti o assistenza post-vendita distribuita dovrà considerare anche fusi orari, disponibilità del personale e obblighi contrattuali verso i clienti.
La regola 3-2-1-1-0 come base progettuale
La regola 3-2-1-1-0 resta un riferimento concreto, purché venga adattata all'infrastruttura aziendale. Significa mantenere almeno tre copie dei dati, su due supporti differenti, con una copia conservata fuori sede, una copia immutabile o isolata e zero errori verificati nei backup.
La copia locale consente ripristini rapidi per cancellazioni accidentali, guasti limitati o recupero di singoli file. La copia off-site protegge invece da incendio, furto, allagamento e indisponibilità della sede. La copia immutabile è decisiva contro il ransomware: se i backup possono essere modificati o eliminati con le stesse credenziali che hanno subito una compromissione, non rappresentano un reale piano di recupero.
Immutabilità non significa solo archiviare dati nel cloud. Occorre definire un periodo di conservazione durante il quale nessun utente, nemmeno un amministratore compromesso, possa alterare le copie. In alcuni scenari può essere utile integrare anche una copia air-gapped, logicamente o fisicamente separata dalla rete di produzione. Il compromesso da valutare è tra costo, velocità di recupero e livello di protezione richiesto.
Proteggere applicazioni, non soltanto file
Uno degli errori più frequenti è trattare il backup come una copia generica del file system. Questa scelta può funzionare per documenti e archivi semplici, ma non garantisce la coerenza di database, macchine virtuali, applicazioni gestionali e ambienti industriali.
Un database copiato mentre è in uso potrebbe non essere ripristinabile o potrebbe contenere dati incompleti. Per ERP, MES, CRM e software custom servono procedure application-aware, in grado di acquisire copie consistenti e di gestire log, snapshot e dipendenze applicative. Lo stesso vale per le macchine virtuali: ripristinare una VM non basta se mancano configurazioni di rete, credenziali di servizio, certificati o licenze necessarie all'avvio.
Negli ambienti OT, la prudenza deve essere ancora maggiore. Backup di configurazioni PLC, HMI, SCADA, ricette e parametri di linea vanno gestiti con versionamento, accessi limitati e controlli di compatibilità. Un ripristino errato su un impianto produttivo può creare non solo un fermo, ma anche problemi di sicurezza e qualità. La collaborazione tra IT, responsabili di produzione e fornitori delle macchine è parte integrante del progetto.
Sicurezza del backup: identità, rete e monitoraggio
Il backup è un bersaglio prioritario per gli attacchi ransomware. Per questo deve avere controlli di sicurezza propri, non ereditare passivamente quelli della rete aziendale.
L'accesso alla console di backup va protetto con autenticazione a più fattori e account amministrativi separati da quelli utilizzati quotidianamente. Le credenziali di servizio devono essere limitate al minimo necessario, ruotate secondo policy e monitorate. Un account di dominio con privilegi eccessivi può trasformare un incidente circoscritto in una compromissione estesa delle copie di sicurezza.
Anche la segmentazione conta. Repository, server di backup e sistemi di gestione non dovrebbero essere liberamente raggiungibili da ogni postazione o server. Log centralizzati e alert devono segnalare anomalie come cancellazioni massive, modifiche alle retention policy, fallimenti ricorrenti o picchi insoliti di dati trasferiti.
La cifratura è necessaria sia durante il trasferimento sia nella conservazione, soprattutto quando sono presenti dati personali, progetti proprietari, informazioni commerciali o documentazione soggetta a requisiti contrattuali. Tuttavia, cifrare senza governare le chiavi può rendere impossibile il ripristino. La gestione delle chiavi deve prevedere ruoli, procedure di recupero e custodia adeguata.
Il test di ripristino è la prova che il backup funziona
Un job di backup completato con successo dimostra soltanto che una copia è stata creata. Non prova che l'azienda possa utilizzarla. La validazione reale avviene durante il restore.
Le PMI dovrebbero pianificare test periodici con livelli diversi. Il recupero di un file o di una casella email può essere verificato con frequenza elevata. Il ripristino di un database critico va svolto in un ambiente isolato, controllando integrità, applicazione e disponibilità dei dati. Almeno una volta all'anno, oppure dopo cambiamenti rilevanti dell'infrastruttura, è utile simulare il ripristino di un servizio prioritario secondo gli RTO e RPO stabiliti.
Ogni test deve produrre evidenze: tempi effettivi, problemi incontrati, dipendenze non documentate e azioni correttive. Questa documentazione è utile per audit, polizze cyber, requisiti dei clienti e decisioni di investimento. Soprattutto, evita che la conoscenza resti concentrata in una sola persona del reparto IT o presso un fornitore esterno.
Retention, compliance e costi: trovare il giusto equilibrio
Conservare tutto per sempre non è una strategia. Aumenta i costi, amplia la superficie da proteggere e rende più difficile individuare le informazioni rilevanti. Una retention efficace distingue tra copie operative a breve termine, archivi mensili o annuali e conservazioni richieste da norme, contratti o procedure qualità.
La policy deve considerare dati personali, obblighi fiscali, proprietà intellettuale e requisiti specifici del settore. Per le aziende che lavorano con clienti statunitensi o su commesse internazionali, possono entrare in gioco clausole contrattuali su localizzazione del dato, tempi di notifica, disponibilità dei sistemi e conservazione dei documenti. Non esiste una durata universale: serve allineamento tra direzione, IT, compliance e funzioni operative.
Il costo va analizzato sul ciclo di vita, non solo sul prezzo per terabyte. Una soluzione economica ma lenta da ripristinare può risultare molto più onerosa quando un fermo blocca produzione, fatturazione o spedizioni. Il valore è dato dalla capacità di recuperare ciò che serve, nel momento in cui serve, con procedure governate.
Dalla policy alla responsabilità operativa
Una buona policy di backup deve essere leggibile anche da chi non gestisce l'infrastruttura. Deve indicare quali sistemi sono inclusi, con quale frequenza vengono copiati, dove risiedono le copie, chi riceve gli alert, chi autorizza modifiche e come viene gestita un'emergenza.
È utile definire una matrice di responsabilità tra IT interno, provider cloud, software house e partner di cybersecurity. Il fatto che un'applicazione sia in cloud non elimina automaticamente l'obbligo di backup: molti servizi garantiscono disponibilità della piattaforma, ma non il recupero granulare o la conservazione richiesta dall'azienda. Verificare il modello di responsabilità condivisa evita zone grigie proprio quando serve intervenire.
INGENIA affronta questi progetti collegando analisi dei processi, sicurezza, integrazione applicativa e test di continuità. L'obiettivo non è aggiungere un altro strumento, ma costruire una capacità di recovery coerente con la produzione e con la crescita dell'impresa.
Un backup ben progettato non si misura dal numero di copie create durante la notte. Si misura dalla certezza che, di fronte a un incidente, persone, dati e processi possano ripartire senza lasciare il business in attesa.
