Backup non è Disaster Recovery (e qui spieghiamo perché)
Il backup è una condizione necessaria ma non sufficiente per il DR. Le otto cose che servono dopo il backup per chiamare un sistema realmente "Disaster Recovery".
TL;DR
Avere il backup è il 30% del lavoro DR. Senza replica, runbook, test, automazione e capacità di failover, il backup è solo storage. Ecco le otto cose che separano un backup da un vero Disaster Recovery.
Backup e DR sono cose diverse
Un backup è una copia dei dati in un momento dato. Un DR è la capacità di tornare operativi dopo un disastro. La differenza è enorme:
- col backup hai i dati, ma non un sistema funzionante;
- col DR hai un sistema funzionante, ricostruito a partire dai dati di backup.
L'errore commerciale tipico è vendere "backup managed" e chiamarlo DR. Funziona finché non capita un evento reale.
Le 8 cose che mancano in un "solo backup"
1. Replica off-site cifrata
Il backup nello stesso CED del primario non sopravvive a incendio o ransomware. Off-site significa datacenter geograficamente separato, cifrato in transito e a riposo.
2. Verifica di integrità periodica
Un backup non verificato non esiste. Sefthy esegue DeepVerify automaticamente: ogni backup viene rimontato e validato.
3. Capacità di compute al ripristino
Se non hai dove far girare il sistema ricoverato, hai solo dati. Servono VM cloud (o hardware secondario) pronte all'uso.
4. Networking di failover
Senza un piano di rete (VPN, tunnel, routing) la VM ricoverata non parla con i client. È il problema che il tunnel L2 di Sefthy risolve.
5. Runbook scritti
Senza un documento che dice "in caso X, fare Y in ordine Z", chi gestisce l'emergenza improvvisa.
6. Automazione di restart con dipendenze
Restartare 12 VM nell'ordine corretto manualmente è una corsa contro il tempo. Strumenti di orchestration riducono RTO del 50-70%.
7. Gestione delle credenziali in emergenza
Le credenziali del DR (KMS, vault, certificati) devono essere accessibili anche quando il sistema primario è offline. Vault separato, copie d'emergenza con custodia.
8. Test trimestrali documentati
Il backup non testato non funziona. Il DR senza test trimestrali è una promessa, non un servizio.
Come riconoscere se hai backup o DR
Tre domande veloci:
- Quanto tempo ci metti a far ripartire il gestionale dal backup? Se la risposta è "non lo so" o "qualche ora", hai backup.
- Chi esegue il restore se il sistemista X è in ferie? Se la risposta è "non saprei", hai backup.
- Quando è stato l'ultimo test reale? Se è "un anno fa, due", hai backup.
Tre risposte corrette = hai DR. Una sola risposta confusa = hai backup glorificato.
Il livello minimo per chiamarlo DR
Per le PMI italiane, considerate "DR" un sistema che:
- ha replica off-site cifrata in un secondo cloud (idealmente sovrano);
- garantisce un RTO documentato per i 3-5 sistemi critici;
- include almeno un test parziale ogni trimestre;
- ha runbook scritti per ogni sistema critico.
Se tutto questo è presente, è DR. Altrimenti è backup managed.
FAQ
Posso usare il backup esistente come "base" per costruire il DR?
Sì, ed è la strada più rapida. Aggiungete replica off-site, capacità cloud e test, e in 60-90 giorni il backup diventa un DR.
Il restore di un singolo file conta come DR?
No. Il DR riguarda il ripristino di interi servizi. Il restore di un file è recovery di backup standard.
Il mio fornitore di backup mi dice di essere "DR-ready". Mi fido?
Verificate due cose: documenti SLA con RTO scritto e log di un test recente. Se entrambi mancano, è marketing.
Per capire come il tunnel L2 cambia il restart networking, leggi L2 tunnel per il DR. Per la cadenza dei test, Test di ripristino.
Vuoi vedere Sefthy in azione?
Stesso IP, stessa subnet, RTO in minuti. Provalo gratis per 7 giorni o parla con un nostro specialista.