Un backup completato non dimostra, da solo, che i dati siano pronti per essere utilizzati dopo un incidente. Per capirlo occorre scegliere gli scenari critici, eseguire prove di ripristino e verificarne risultati, tempi e responsabilità. Ecco un metodo pratico per passare dall’esistenza delle copie alla possibilità concreta di recuperare il lavoro.
Milano, 29 ottobre 2026
Un backup aziendale è verificato rispetto a uno scenario concreto quando una prova di ripristino recupera i dati previsti, questi risultano utilizzabili e il tempo impiegato viene registrato. Il messaggio «backup completato» indica che un’operazione di copia è terminata; da solo, non dimostra che l’azienda possa riprendere il lavoro nel modo e nei tempi di cui ha bisogno.
La distinzione diventa chiara quando qualcosa va storto. Recuperare una cartella cancellata è diverso dal riavviare il gestionale dopo il guasto di un server. Nel secondo caso potrebbero servire, oltre ai dati, l’applicazione, le configurazioni, gli accessi e le connessioni con altri sistemi. Una prova riuscita per la cartella non verifica automaticamente il recupero del gestionale.
Che cosa bisogna verificare, oltre all’esito del backup?
- La copia è stata eseguita? Si osservano stato dei processi, errori, avvisi e data dell’ultima copia disponibile.
- Il dato si può recuperare? Si seleziona un punto di ripristino e si esegue una prova nel perimetro previsto.
- Il risultato serve davvero a lavorare? Si controllano integrità, accessi e funzionalità dei dati o del servizio recuperato, misurando il tempo impiegato.
Tutti e tre contano. Un file può essere stato recuperato ma non aprirsi; un database può avviarsi ma non essere coerente con l’applicazione che lo usa. Viceversa, un test su un singolo file non autorizza a dichiarare verificata l’intera infrastruttura.
Come eseguire un test di ripristino del backup aziendale
1. Parti dal processo aziendale, non dallo strumento
Scegli un’attività che non può fermarsi a lungo: per esempio evadere ordini, accedere ai documenti di progetto o gestire la posta. Elenca quali dati, applicazioni e servizi le servono. Chiedi anche dove si trovano: server locali, cloud o applicazioni SaaS possono richiedere modalità di protezione e recupero diverse.
Questo passaggio rende il test utile per il business. La domanda non è soltanto «possiamo recuperare un file?», ma «quali elementi ci servono per tornare a svolgere questa attività?».
2. Definisci lo scenario e gli obiettivi
Indica che cosa deve essere recuperato e da quale evento: cancellazione accidentale, modifica errata, guasto di un sistema o indisponibilità di un ambiente. Per i servizi più importanti chiarisci quanta perdita di dati è accettabile e quanto tempo di interruzione può essere tollerato. In ambito tecnico questi obiettivi sono spesso chiamati RPO e RTO; sono requisiti da valutare rispetto alla soluzione adottata, non tempi garantiti dalla sola presenza di un backup.
Un esempio illustrativo: se il gestionale è necessario per preparare le spedizioni, verificare il solo recupero di un documento condiviso lascia senza risposta la domanda principale.
3. Esegui una prova controllata
Un referente autorizzato seleziona la copia e svolge il ripristino secondo una procedura concordata, preferibilmente in una destinazione separata quando lo scenario lo consente. Prima del test vanno chiariti l’eventuale impatto sui sistemi in uso, la protezione dei dati trattati e chi può autorizzare una sovrascrittura.
La prova deve corrispondere allo scenario scelto. Se il problema è un file eliminato, può bastare recuperarne una versione. Se riguarda un’applicazione, occorre verificare anche le sue dipendenze essenziali. La granularità possibile dipende dalla soluzione implementata e dalla sua configurazione.
4. Fai validare il risultato a chi usa il servizio
Il team tecnico può confermare che il ripristino è terminato. Chi conosce il processo deve poter dire se il risultato è utilizzabile: i documenti si aprono, i dati attesi sono presenti, i permessi funzionano e l’applicazione consente le operazioni necessarie. Registra l’ora del punto recuperato e il tempo effettivamente impiegato. Confrontali con gli obiettivi definiti, spiegando eventuali scostamenti.
5. Documenta le lacune e ripeti quando serve
Per ogni test conserva almeno scenario, data, dati e sistemi inclusi, punto di ripristino scelto, esito tecnico, verifica funzionale, tempi osservati e azioni correttive con un responsabile. Un risultato parziale è un’informazione utile: mostra che cosa sistemare prima di un incidente reale.
La frequenza delle prove va stabilita secondo criticità, modifiche dell’ambiente e perimetro del servizio. Dopo il cambio di un’applicazione, della struttura dei dati o della soluzione di backup, un vecchio test potrebbe non descrivere più la situazione attuale.
Chi decide e chi verifica
L’azienda definisce quali processi contano di più, chi può autorizzare un recupero e quale risultato è accettabile. Il referente IT o il partner esegue i controlli e le prove comprese nel perimetro concordato, segnala le criticità e documenta l’esito. La verifica funzionale richiede anche il coinvolgimento di chi utilizza i dati.
È la stessa domanda di governo affrontata nel nostro approfondimento su chi governa l’IT quando non c’è un reparto dedicato: avere un fornitore o uno strumento non basta se responsabilità ed evidenze restano implicite.
Le tre domande da fare oggi sui backup
- Quali dati e servizi critici sono inclusi nelle copie? Un elenco aggiornato evita di scoprire troppo tardi che una nuova applicazione è fuori perimetro.
- Quando è stato provato l’ultimo ripristino pertinente? Chiedi quale scenario è stato testato e che cosa è stato effettivamente recuperato.
- Chi ha verificato l’esito e quali problemi restano aperti? Un report utile distingue il completamento tecnico dalla possibilità di usare il dato per lavorare.
Per rendere sistematici questi controlli, si possono definire attività, responsabilità e prove periodiche all’interno del servizio di gestione. Scopri come C.A.R.E. di Lucient affronta la protezione e la disponibilità dei dati..
