Backup dei dati del Magazzino: 2/2 RTO e RPO

Nella puntata precedente abbiamo parlato delle strategie per il backup dei dati; oggi esaminiamo le criticità ed i parametri della fase di ripristino.

 

 

 

Si è verificato un “evento inatteso” ed i nostri preziosissimi dati sono inutilizzabili; il responsabile segnala il fatto al responsabile IT che, dopo aver trovato la causa dell’evento ed aver messo in sicurezza il sistema, accederà ad una delle copie di backup tra quelle che sono state create.

 

 

 

Uno degli eventi che – purtroppo – accadono spesso è che la copia cui si accede è corrotta o parzialmente danneggiata; questo succede quando i parametri di archiviazione contengono degli errori oppure quando il supporto stesso è difettato (pensiamo ai sistemi di archiviazione a nastro). Abbiamo un altro scenario quando la copia di backup è integra ma non è leggibile dal server perché i software, un tempo compatibili, non “dialogano” perché un programma è stato aggiornato “dimenticandosi” di aggiornare l’altro.

 

In questi casi le soluzioni sono:

 

-          in caso di dati corrotti: ripristino utilizzando una o più versioni meno recenti; molti programmi di archiviazione offrono un automatismo che permette di avere lo storico dei dati.

 

-          In caso di file danneggiato: ci sono dei software che un bravo specialista IT può utilizzare per riparare il programma

 

-          Negli altri casi: occorre portare l’hardware fisicamente presso un centro specializzato dove potranno effettuare le operazioni necessarie

 

 

 

Atteso che nessun sistema di backup può ripristinare perfettamente ed immediatamente la mole dei dati, al momento di scegliere la strategia di protezione la Direzione Aziendale valuterà il livello di tolleranza dell’inconveniente tramite 2 parametri che diventano i pilastri del Disaster Recovery Plan del settore IT; vediamoli:

 

 

 

RPO (acronimo di Recovery Point Objective) misura la perdita massima accettabile di dati, misurata in unità di tempo. Ad esempio la Direzione Aziendale decide per un RPO massimo di 8 ore.

 

Il concetto base è che i dati dall’ultimo backup sino all’evento catastrofale possono essere ricostruiti facilmente perché sono “freschi”. La direzione aziendale deciderà il livello accettabile di RPO ovvero quanti dati possono essere persi dall’ultimo backup e quindi andranno ricostruiti manualmente.

 

Visto il valore di RPO richiesto dalla Direzione, i tecnici IT imposteranno la frequenza delle operazioni di backup. Ovviamente accorciare gli intervalli di salvataggio impiegherà più risorse con costi maggiori.

 

 

 

RTO (acronimo di Recovery Time Objective) invece è il tempo massimo accettabile entro il quale i dati devono essere stati recuperati dal backup ed il sistema deve riprendere a funzionare; non include i tempi per l’imputazione manuale dei dati persi (vedi paragrafo precedente) ma solo il tempo massimo in cui il sistema deve di nuovo in piedi e funzionale al 100% dopo un evento catastrofale.

 

 

Ovviamente è espresso un unità temporali può variare da un paio giorni, ad esempio per la piccola azienda con produzione su commessa, a pochi secondi per i colossi dell’e-commerce dove il sistema riceve centinaia di ordini ogni secondo. Questo risultato, impensabile fino a pochi anni fa, si ottiene con architetture sofisticate che comportano notevoli investimenti ma anche costi di manutenzione molto alti.

 

 

 

Come decidere RPO e RTO ?

 

Nello stendere il Disaster Recovery Plan la Direzione Aziendale dovrà esaminare i diversi scenari e valutare l’accettabilità dei dati persi / tempo in cui il sistema resta inoperativo dal punto di vista dei clienti e delle normative ma anche valutando i costi per la riduzione di RPO / RTO ai livelli richiesti.

 

Le esigenze di una Banca sulla perdita di dati saranno più stringenti rispetto a quelle di una PMI; il sistema che controlla il traffico aereo avrà un RTO molto più breve rispetto a quello di un centro logistico.

 

 

 

In tutti i casi RPO e RTO non devono rimanere dei numeri scritti in un manuale ma devono essere verificati periodicamente con stress test completi in condizioni reali e non ideali; ogni deviazione va analizzata e corretta immediatamente.

 

Cause ricorrenti di fallimento degli stress test: la larghezza di banda per il trasferimento dei dati si rivela inadeguata, procedure non aggiornate o “dipendenze non conosciute”, dove emerge che nel suo funzionamento il software attinge a processi o variabili esterne e questo influenza negativamente il suo funzionamento.

 

C.B. luglio 2026