Guida al backup aziendale sicuro per PMI
Un backup che non è stato ripristinato con successo è solo un'ipotesi. È il punto da cui dovrebbe partire ogni guida al backup aziendale sicuro: non dalla quantità di spazio acquistato o dal software scelto, ma dalla capacità concreta di tornare operativi quando un server, un database o un'intera sede diventano indisponibili.
Per una PMI, un fermo può bloccare ordini, produzione, amministrazione, logistica e assistenza. Il rischio non riguarda soltanto il ransomware. Un aggiornamento errato, una cancellazione accidentale, un guasto hardware, credenziali compromesse o una configurazione cloud modificata senza controllo possono produrre lo stesso risultato: dati non disponibili quando servono.
Il backup è quindi un processo operativo. Richiede architettura, responsabilità, verifiche periodiche e decisioni coerenti con il valore dei dati da proteggere.
Guida al backup aziendale sicuro: partire dai dati
La domanda corretta non è quanto spazio serve per il backup. È quali sistemi l'azienda può permettersi di perdere e per quanto tempo.
Un gestionale con ordini, fatture e disponibilità di magazzino ha priorità diversa rispetto a un archivio storico. Lo stesso vale per un e-commerce: perdere alcune immagini può essere gestibile, perdere transazioni, clienti o configurazioni di pagamento no. Applicazioni sviluppate su misura, database CRM, file condivisi, macchine virtuali e configurazioni infrastrutturali devono essere considerati separatamente.
Per ogni servizio è utile definire due parametri. L'RPO, Recovery Point Objective, stabilisce quanta perdita di dati è accettabile. Se l'RPO è quattro ore, il piano deve produrre copie utili almeno ogni quattro ore. L'RTO, Recovery Time Objective, indica invece entro quanto tempo il servizio deve tornare disponibile.
Questi valori non sono formule amministrative. Determinano frequenza delle copie, tecnologie, costi e procedure. Pretendere un ripristino in pochi minuti con copie notturne e infrastrutture non predisposte è un'incoerenza, non una strategia.
Inventario e dipendenze
Prima di configurare un job di backup, va costruito un inventario aggiornato. Non basta elencare i server: occorre includere database, storage, repository di codice, caselle di posta, servizi SaaS, configurazioni DNS, certificati, segreti applicativi e account con privilegi elevati.
Le dipendenze contano quanto i dati. Ripristinare un'applicazione Laravel senza database, variabili d'ambiente, file caricati dagli utenti e chiavi di cifratura non significa ripristinare il servizio. Analogamente, una macchina Docker recuperata senza volumi persistenti o file di configurazione può avviarsi senza essere realmente operativa.
La regola 3-2-1-1-0, applicata con criterio
La regola 3-2-1 resta una base utile: tre copie dei dati, su due supporti differenti, con una copia conservata fuori sede. Per scenari esposti a ransomware o attacchi mirati, conviene estenderla al modello 3-2-1-1-0: una copia offline o immutabile e zero errori verificati nei controlli di ripristino.
Non va interpretata come un acquisto automatico di quattro prodotti diversi. L'obiettivo è evitare un singolo punto di guasto. Se produzione, backup e credenziali amministrative vivono nello stesso ambiente, un attaccante che ottiene privilegi elevati può cancellare tutto con un'unica azione.
Una struttura concreta può prevedere backup locali per recuperi rapidi, una replica cifrata su storage esterno e una copia immutabile con retention definita. L'immutabilità impedisce la modifica o la cancellazione dei dati entro il periodo stabilito. È una protezione efficace, ma non sostituisce gli altri controlli: una retention configurata male può rendere irrecuperabili anche copie formalmente immutabili.
La copia offline è un'alternativa o un'integrazione utile in contesti specifici. Richiede però disciplina operativa: un supporto scollegato ma mai verificato non offre garanzie migliori di un backup cloud non controllato.
Copie di file, immagini e database
Non tutti i backup sono equivalenti. La copia dei file può bastare per documenti condivisi e asset statici. Per database transazionali, invece, servono dump consistenti, backup nativi o snapshot coordinati con il motore dati. Copiare file di database mentre sono in uso può produrre un archivio apparentemente completo ma non ripristinabile.
Le immagini delle macchine virtuali accelerano il disaster recovery, soprattutto se l'obiettivo è riportare online più servizi in tempi brevi. Hanno però dimensioni maggiori e non eliminano la necessità di backup applicativi granulari. Ripristinare una singola tabella o un file cancellato da un'immagine completa può essere lento e poco pratico.
La scelta dipende dall'RTO, dal volume dei dati e dalla complessità del servizio. In molti casi la soluzione corretta combina livelli diversi: backup del database frequente, copia dei file, snapshot infrastrutturali e configurazioni versionate separatamente.
Sicurezza del backup: identità, cifratura e separazione
Un backup contiene spesso più informazioni sensibili del sistema in produzione. Database clienti, documenti, dati personali, credenziali applicative e file amministrativi finiscono nello stesso archivio. Trattarlo come semplice storage è un errore.
La cifratura deve proteggere i dati sia durante il trasferimento sia a riposo. Le chiavi di cifratura non dovrebbero risiedere esclusivamente sul server protetto, né essere accessibili con lo stesso account usato dall'applicazione. Se un ransomware compromette server e credenziali di backup, la cifratura dell'archivio non cambia il risultato.
La separazione delle identità è altrettanto rilevante. L'account che esegue le copie deve avere solo i permessi necessari, mentre la cancellazione delle retention e la modifica delle policy dovrebbero richiedere privilegi distinti. L'autenticazione a più fattori va applicata agli account amministrativi dello storage e delle console di backup.
È utile conservare in modo protetto la documentazione per il recovery: procedure, contatti, chiavi, configurazioni e ordine di avvio dei servizi. Durante un incidente, l'assenza di queste informazioni genera ritardi che nessuna piattaforma può compensare.
Il test di ripristino è il controllo decisivo
Molte aziende ricevono ogni mattina una notifica verde dal software di backup e deducono che tutto funzioni. Quella notifica conferma di solito che un processo è terminato, non che l'applicazione sia ripristinabile e coerente.
Un test efficace parte da uno scenario realistico. Per esempio: ripristinare l'ultimo database disponibile in un ambiente isolato, avviare l'applicazione, verificare l'accesso degli utenti e controllare che ordini, allegati e report siano leggibili. Il test deve misurare il tempo effettivo, confrontandolo con l'RTO dichiarato.
La frequenza dipende dalla criticità. Sistemi che gestiscono operazioni quotidiane meritano prove regolari, almeno trimestrali, oltre a verifiche dopo modifiche rilevanti all'infrastruttura o al software. Un nuovo database, un cambio di provider, una migrazione Docker o l'introduzione di un servizio SaaS possono modificare le procedure di recovery.
Ogni test dovrebbe produrre un verbale essenziale: cosa è stato ripristinato, da quale copia, quanto tempo è servito, quali anomalie sono emerse e chi deve correggerle. Senza una chiusura delle anomalie, il test diventa un esercizio formale.
Definire ruoli, retention e piano di emergenza
Il backup fallisce spesso per responsabilità ambigue. L'area IT può gestire i job, ma il business deve definire priorità e tempi accettabili. La direzione deve approvare i livelli di rischio residuo e i responsabili operativi devono sapere cosa fare quando un servizio non è disponibile.
Una policy utile assegna proprietari ai dati, indica frequenza e durata delle copie, definisce i sistemi esclusi e descrive chi è autorizzato a richiedere o eseguire un ripristino. Va inclusa anche una retention coerente con esigenze operative, fiscali e contrattuali. Conservare tutto per sempre costa e aumenta la superficie esposta; eliminare troppo presto può impedire il recupero da una compromissione scoperta in ritardo.
Il piano di emergenza deve indicare l'ordine di ripartenza. Prima identità e rete, poi database, applicazioni critiche, integrazioni e servizi secondari. Questo ordine cambia da azienda ad azienda: un e-commerce potrebbe richiedere prima catalogo e ordini, un'impresa manifatturiera potrebbe dare precedenza al gestionale di produzione.
Per infrastrutture articolate, affidarsi a un unico partner che conosca applicazione, database, server e misure di sicurezza riduce i passaggi critici durante il ripristino. Noventra affronta questo lavoro collegando sviluppo e gestione infrastrutturale, perché un piano efficace non può fermarsi al livello dello storage.
Il momento migliore per verificare un backup è quando nessuno ne ha ancora bisogno. Programmare un ripristino di prova, misurarlo e correggere ciò che non torna costa molto meno di scoprire i limiti del sistema nel giorno in cui l'azienda è ferma.
