Cosa è il Recovery Time Objective?
RTO (Recovery Time Objective) ed RPO (Recovery Point Objective) sono due parametri fondamentali quando si vuole valutare la capacità di Disaster Recovery di una rete informatica.
In questo articolo andrò ad analizzare l’RTO.
Si dice spesso che dovremmo dare le risposte giuste ai nostri Clienti…
Pochi però si concentrano sulle domande giuste da porre ai clienti, dimenticandosi che abbiamo due orecchie ma una sola bocca.
Oggi voglio quindi regalarti una delle prime domande fondamentali su cui devi riflettere per valutare l’efficienza della tua informatica aziendale.
La domanda è questa:
Se tu avessi un problema grave agli strumenti informatici (cioè computer, server, storage di rete o NAS che usi per lavorare tutti i giorni) in quanto tempo devi tornare operativo?
Le cause che potrebbero portarti a questo punto sono diverse:
- un furto
- un incendio
- una perdita d’acqua
- o a causa di un criminale informatico
considerando sempre che la speranza non è una tattica.
Questo parametro è chiamato RTO
Recovery Time Objective
RTO indica, quindi, per quanto tempo posso accettare che “rimanga giù” la mia rete.
Potresti pensare che la risposta a questa domanda debba essere data da un tecnico, da un sistemista, da un programmatore…
Invece si tratta di una domanda a cui DEVI DARE RISPOSTA TU, Imprenditore di una PMI.
Solo l’imprenditore può sapere per quanto tempo possono rimanere “fuori linea” i sistemi informatici della sua azienda.
Ti faccio due esempi concreti, di miei clienti:
- Impresa di pulizia → RTO di qualche giorno
- Azienda di logistica, ma potrebbe essere anche il Giornale di Brescia → RTO prossimo allo zero!
Trovare la soluzione tecnica di Disaster Recovery (DR) non sarà mai un problema. A patto di avere chiari gli obiettivi che si vogliono raggiungere in termini di RTO ed RPO ed il giusto budget.
Come si può migliorare?
Il Recovery Time Objective (RTO) può essere migliorato ridondando i sistemi, creando dei cluster.
Facendo in modo che un problema grave (un disastro) su un singolo componente NON provochi l’indisponibilità di tutto il sistema.
Facciamo un esempio pratico:
Se il server gestionale “gira” su un SOLO server questo vuol dire che se quel singolo server ha un problema grave la tua azienda rimane senza gestionale.
Se invece si fa in modo che il gestionale posso girare su due server e non solo su uno otterrò che in caso di disastro su uno dei server il gestionale continuerà comunque ad essere disponibile.
Nel prossimo articolo ti parlerò della seconda domanda fondamentale:
Sempre in caso di disastro quanti dati puoi accettare di perdere?
Cioè quanto lavoro fatto puoi permetterti di perdere?
Affronteremo quindi l’argomento del Recovery Point Objective (RPO).
Insieme alla regola del Backup 3-2-1 sono indicazioni preziose su come mettere al sicuro i vostri “gioielli della Corona” informatici!
