Il backup ha una caratteristica sgradevole: funziona in silenzio per anni e si scopre rotto nell’unico momento in cui serve. Fino ad allora la spia è verde, il report notturno dice «completato», e tutti dormono tranquilli.
Questi sono i sette motivi più frequenti per cui, il giorno del ripristino, non si torna indietro. Sono in ordine di quanto spesso si incontrano, non di gravità — anche se il primo è pure il più grave.
1. I backup stanno dove sta il problema
È l’errore che trasforma un incidente in un disastro. Il backup gira su un NAS collegato alla stessa rete, raggiungibile con le stesse credenziali di dominio degli altri server. Funziona benissimo contro il guasto di un disco, che è lo scenario per cui è stato pensato.
Contro un ransomware non serve a niente: chi entra con credenziali di amministratore trova anche quello, e lo cifra insieme al resto. La difesa non è fare più copie, è fare copie che non siano raggiungibili dalla rete compromessa — immutabili, con credenziali separate, idealmente fuori sede.
2. Nessuno ha mai provato a ripristinare
«Il backup gira» e «il backup funziona» sono affermazioni diverse, e solo la seconda conta. Un job che termina senza errori garantisce che i dati siano stati scritti da qualche parte; non garantisce che siano leggibili, coerenti e sufficienti a rimettere in piedi un sistema.
La verifica seria non è aprire un file di prova. È prendere un server, ripristinarlo altrove, accenderlo e vedere se l’applicativo parte. Se non l’avete mai fatto, non sapete quanto tempo ci vuole — e il tempo è la variabile che conta di più.
3. Si salvano i dati, non i sistemi
Molti backup coprono le cartelle condivise e i database, che sono la parte a cui si pensa. Non coprono la configurazione: come era impostato il server, quali servizi girano, le regole del firewall, i certificati, le personalizzazioni del gestionale accumulate in dieci anni.
Il risultato è che i dati tornano ma nessuno sa più rimontarci intorno il sistema che li usava. Il ripristino diventa una reinstallazione, e la reinstallazione richiede giorni e le persone giuste — spesso quelle che nel frattempo hanno cambiato lavoro.
4. La finestra è più larga di quanto crediate
Se il backup gira una volta al giorno alle 22, e il guasto capita alle 21 del giorno dopo, avete perso ventitré ore di lavoro. È un conto banale che quasi nessuno ha fatto esplicitamente.
La domanda giusta non è «ogni quanto facciamo il backup» ma quante ore di lavoro possiamo permetterci di rifare. Per un ufficio amministrativo forse una giornata è tollerabile. Per chi emette bolle di trasporto o gestisce ordini in tempo reale, quasi mai. Da quella risposta discende la frequenza, non il contrario.
| Frequenza | Lavoro perso nel caso peggiore | Tipicamente adatto a |
|---|---|---|
| Giornaliera notturna | Fino a una giornata intera | Archivi, documentazione, dati che cambiano poco |
| Ogni 4 ore | Mezza giornata | Gestionali di aziende con ritmo d’ufficio |
| Sub-oraria | Meno di un’ora | Produzione, logistica, ordini, magazzino |
5. Nessuno legge i report
Il sistema di backup manda un’email ogni mattina. Le prime settimane qualcuno la guarda. Dopo sei mesi finisce in una cartella con una regola automatica, e nessuno se ne occupa più.
Così un job che fallisce da tre settimane non lo sa nessuno, finché non serve. La soluzione non è la disciplina — la disciplina si consuma — ma il rovesciamento della logica: non un messaggio quando va bene, un allarme quando va male, indirizzato a qualcuno il cui mestiere è occuparsene. È una delle cose che un monitoraggio centralizzato fa per costruzione.
6. Manca quello che è nato dopo
Il perimetro del backup viene definito una volta, quando il sistema viene installato. Poi l’azienda cambia: arriva un server nuovo, un applicativo passa in cloud, un reparto comincia a usare uno strumento diverso, la posta migra su Microsoft 365.
Quasi sempre nessuno torna a rivedere cosa viene salvato. Su Microsoft 365 in particolare c’è un equivoco diffuso: Microsoft garantisce la disponibilità del servizio, non il recupero dei vostri contenuti dopo una cancellazione o una cifratura. Posta, OneDrive e SharePoint vanno inclusi esplicitamente in una strategia di backup, e spesso non lo sono.
7. Il piano esiste solo nella testa di una persona
L’ultimo errore non è tecnico. La procedura di ripristino non è scritta da nessuna parte: la sa il tecnico che ha montato tutto. Se l’emergenza capita mentre quella persona è in ferie, irreperibile o non lavora più con voi, si improvvisa.
Il rimedio costa un pomeriggio: un documento che dica in che ordine si rimettono in piedi i sistemi, dove stanno le credenziali di emergenza, chi va avvisato, e quali fornitori vanno chiamati. Aggiornato una volta l’anno. È la parte meno tecnologica di tutta la faccenda ed è quella che nelle emergenze fa la differenza più visibile.
Come verificarlo in mezz’ora
Non serve un progetto per capire come state messi. Bastano cinque domande poste a chi gestisce i vostri sistemi:
- I backup sono raggiungibili con le credenziali di dominio? (Se sì, è il punto 1.)
- Qual è stata l’ultima volta che avete ripristinato qualcosa, e quanto ci è voluto?
- Quante ore di lavoro perderemmo nel caso peggiore?
- Chi ha letto il report di backup di stamattina?
- Microsoft 365 è incluso?
Se tre risposte su cinque sono vaghe, avete individuato la priorità del trimestre. Come si presenta uno scenario in cui tutto questo conta davvero l’abbiamo raccontato nell’articolo sulle prime 48 ore di un attacco ransomware.
Se volete che a quelle domande risponda qualcuno dall’esterno, l’assessment gratuito parte proprio da lì. E la pagina su backup e disaster recovery spiega come impostiamo la cosa quando è compito nostro.