RTO e RPO a confronto: qual è la differenza?

RPO vs RTO Blog banner

Gli MSP hanno il dovere di ridurre al minimo i tempi di inattività dei clienti e di mantenere la loro attività online pienamente operativa. A tal fine, una parte del mantenimento dei tempi di inattività è la preparazione agli imprevisti. Il processo di definizione degli obiettivi per la risoluzione dei problemi e il ritorno in linea è fondamentale per ridurre i tempi di inattività dei clienti.

L’Obiettivo del tempo di recupero (RTO) e l’Obiettivo del punto di recupero (RPO) sono concetti che svolgono un ruolo fondamentale nel processo di pianificazione del disaster recovery. I fornitori di servizi gestiti dovrebbero esaminare ciascuna di queste metriche, definire il loro ruolo nel processo di recupero e lavorare per inserire questi obiettivi nei piani di resilienza dei loro clienti.

Questo articolo tratterà i seguenti argomenti:

  • Cosa sono RTO e RPO?
  • Differenze tra obiettivi di tempo di recupero e obiettivi di punto di recupero
  • Perché RTO e RPO sono importanti per i fornitori di servizi gestiti
  • Come calcolare RTO e RPO
  • In che modo gli strumenti IT aiutano a raggiungere gli obiettivi di recupero

Che cos’è un RTO?

L’Obiettivo del tempo di recupero (RTO) definisce i parametri relativi alla velocità con cui un’azienda deve recuperare i propri sistemi dai tempi di inattività dopo un incidente. Questo viene calcolato per ogni singolo cliente ed è unico per la sua attività.

La definizione di un RTO consente di prendere decisioni più informate sulle soluzioni e sull’implementazione di backup e disaster recovery (BDR). I numeri concreti permettono più facilmente di rimanere realistici e oggettivi, piuttosto che affidarsi a un’idea astratta e ambigua come “rimettere tutto in funzione il più rapidamente possibile”. Tali generalizzazioni sono difficili da definire negli accordi sul livello di servizio.

È facile visualizzare un RTO in azione. Si tratta semplicemente di un obiettivo fissato analizzando i costi e i rischi associati ai tempi di inattività (è bene definire cosa significhi “tempo di inattività” per il cliente specifico), determinando quanto tempo ciascun cliente possa aspettare per il recupero prima che le perdite diventino significative.

Alcuni fattori che possono influenzare l’RTO di un utente sono:

  • Quanti ricavi perderà l’azienda per ogni ora di inattività?
  • Che perdite finanziarie può/potrà assorbire in caso di emergenza?
  • La disponibilità delle risorse necessarie per ripristinare le operazioni
  • La tolleranza dei propri clienti ai tempi di inattività

Se un cliente ha bisogno che i suoi sistemi funzionino entro tre ore, questo è il suo RTO. Se il tempo medio calcolato per il recupero effettivo è di cinque ore, l’azienda ha superato l’RTO di due ore. Poiché si tratta di un calcolo preparatorio, indica che è necessario investire maggiormente nel BDR per ridurre il tempo effettivo di recupero.

Che cos’è un RPO?

L’Obiettivo del punto di recupero (RPO) è una soglia di rischio/perdita simile. Mentre l’RTO definisce la quantità di tempo che può essere persa, l’RPO definisce la quantità di dati che il cliente può perdere senza risultati significativi o catastrofici.

Questo aspetto è in gran parte incentrato sulla cadenza del backup dei dati, ovvero la frequenza dell’ultimo punto di backup. Se il vostro cliente dovesse perdere tutto in questo momento e non avesse altro che l’ultimo backup, di quanti dati mission-critical disporrebbe ancora?

Molti utilizzano i servizi sanitari come esempio di RPO. Mentre alcune aziende possono permettersi di perdere tutti i dati inseriti per una settimana (in quanto possono essere in grado di reinserirli a partire da documenti cartacei), gli ospedali in genere non hanno questo margine di errore. Con decine di professionisti del settore medico che dispensano migliaia di farmaci ogni giorno, è molto improbabile che il personale ricordi tutto ciò che ha fatto o deve fare in merito a un trattamento.

E dato che stiamo parlando di prodotti farmaceutici, perdere anche solo un giorno di dati potrebbe significare sbagliare le dosi o mescolare i farmaci. Si tratta di problemi potenzialmente pericolosi per la vita di un paziente, per cui i servizi sanitari devono eseguire frequentemente il backup dei dati. L’esigenza di dati aggiornati è alla base del loro RPO.

Gli RPO sono importanti per gli MSP perché aiutano a orientare le loro raccomandazioni per le soluzioni di backup dei dati, soprattutto per quanto riguarda lo spazio di archiviazione e le modalità. Backup più frequenti significano un maggiore utilizzo di dati. È importante che i clienti capiscano perché il loro RPO è importante quando si spiega il valore di questo costo aggiuntivo.

Tra i fattori che possono influenzare l’RPO di un cliente vi sono:

  • Complessità e numero di applicazioni e sistemi critici
  • Volume dei dati e requisiti di accesso
  • La frequenza con cui i dati cambiano (cioè la frequenza con cui vengono aggiunte o modificate informazioni importanti in un file)
  • Frequenza e metodo di back-up dei dati

Qual è la differenza tra RTO e RPO?

Entrambe le metriche sono importanti quando si formulano piani di backup e recupero dei dati. L’RPO e l’RTO vi aiuteranno a decidere le caratteristiche chiave del backup e del recupero e a formulare raccomandazioni sulle soluzioni BDR dei clienti. In definitiva, il vostro obiettivo è garantire che i dati e i sistemi critici siano disponibili quando necessario e questi calcoli possono aiutarvi a raggiungere questo obiettivo.

Sebbene entrambi siano funzionali alla pianificazione del recupero, nella pratica sono diversi. Gli RTO attivi sono tipicamente designati dopo il verificarsi di un evento (esclusi quelli utilizzati teoricamente durante la pianificazione). Gli RPO sono sempre determinati prima che sia necessario il recupero.

In alcuni casi, la pianificazione del recupero è incentrata sui sistemi e non sui dati. In queste situazioni, l’unica preoccupazione è il RTO. Non appena i dati entrano a far parte dell’equazione, l’MSP dovrà calcolare e inserire l’RPO. Vale la pena notare che quando le due cose sono combinate, un RTO breve di solito richiede un RPO altrettanto breve.

Calcolo di RPO e RTO

Di solito si determinano gli obiettivi RTO e RPO pertinenti durante un’analisi dell’impatto aziendale (Business Impact Analysis o BIA) o un’analisi generale dei rischi.

Quando si utilizza una BIA, l’obiettivo è identificare i processi aziendali mission-critical e individuare le tecnologie e i dati necessari per supportare tali operazioni. Questi rapporti spesso considerano le implicazioni finanziarie dei tempi di inattività o delle interruzioni e illustrano i potenziali rischi di inattività.

In genere, l’MSP chiede il contributo della dirigenza del cliente o del senior management pertinente per identificare gli obiettivi e assegnare valori numerici agli scenari di recupero. Si può iniziare esplorando gli scenari migliori e peggiori e procedendo a ritroso per trovare cifre ragionevoli e raggiungibili.

Non esiste una formula standard per calcolare i valori RTO/RPO, poiché si tratta di valori temporali numerici unici per ogni organizzazione. Un server critico potrebbe avere un RTO di un’ora, mentre l’RTO di un sistema meno critico potrebbe essere di 24 ore. Lo scopo della BIA è trovare obiettivi ragionevoli basati sulla necessità dei vari sistemi per l’utente.

Con una diminuzione dell’RTO e dell’RPO, è probabile che i costi legati al raggiungimento di tali obiettivi aumentino. A questo proposito, i calcoli RTO/RPO forniscono le informazioni necessarie per la ricerca di soluzioni e prezzi: una pianificazione essenziale al fine di garantire la redditività dei contratti.

I dati BIA e RTO/RPO possono essere utili anche durante il processo di vendita. Spesso nascono conflitti in merito ai costi, quindi è importante essere in grado di dimostrare il valore dei servizi BDR. È più facile quando si fa notare ai clienti che soluzioni meno costose potrebbero non soddisfare le loro esigenze RTO/RPO e comporterebbero costi maggiori in caso di disastro.

In che modo NinjaOne aiuta gli MSP a rispettare RTO e RPO

Sulla base dei risultati dell’analisi dei rischi e della BIA, dovreste avere una buona idea di ciò che potrebbe mettere a rischio il vostro cliente. Parte dell’analisi complessiva consiste nel determinare la frequenza degli eventi, la probabilità del pericolo e i possibili effetti che potrebbero avere sul cliente.

Una volta quantificate queste metriche basate sul rischio, è possibile tradurre questi fattori in risorse e misure raccomandate. Un hub di monitoraggio e gestione remota centralizzato come NinjaOne semplifica notevolmente entrambi i processi. Aggregando i dati sulle risorse e sugli utilizzi importanti per i clienti, è possibile ottenere una visione più approfondita durante la determinazione di RPO e RTO.

Naturalmente, il fatto che il BDR sia fondamentale per l’utilizzo delle metriche RTO/RPO significa che la soluzione di backup integrata di NinjaOne vi aiuterà ad affrontare senza problemi la sfida, non solo a valutarla.

Conclusioni

Ci sono due metriche che aiutano gli MSP a ottenere i migliori risultati in materia di backup e recupero dei dati: Recovery Time Objective e Recovery Point Objective. Entrambe le metriche sono essenziali e correlate quando si lavora con soluzioni di backup e recupero dei dati, strategie di continuità aziendale e piani di disaster recovery.

Per un MSP che fornisce backup e recupero dei dati, queste metriche sono essenziali per pianificare e creare valore nella soluzione. Gli RTO/RPO aiutano a determinare la configurazione tecnologica e di backup dei dati ottimale per raggiungere i loro obiettivi. Questi dati possono essere importanti anche per la conformità e la revisione, in quanto i revisori potrebbero cercare prove di questi valori come controlli di backup/recupero dei dati.

NinjaOne può aiutarvi a ottenere, calcolare e utilizzare gli RPO/RTO per i vostri clienti, assicurandovi di fornire il miglior servizio e di soddisfare le aspettative in termini di uptime e continuità operativa.

Passi successivi

La creazione di un team IT efficiente ed efficace richiede una soluzione centralizzata che funga da principale strumento di erogazione dei servizi. NinjaOne consente ai team IT di monitorare, gestire, proteggere e supportare tutti i dispositivi, ovunque essi si trovino, senza la necessità di una complessa infrastruttura locale.

Scopri di più su NinjaOne Endpoint Management, fai un tour dal vivoinizia la tua prova gratuita della piattaforma NinjaOne.

Ti potrebbe interessare anche

Vuoi diventare un Ninja dell’IT?

Scopri come NinjaOne può aiutarti a semplificare le operazioni IT.
Guarda una demo×
×

Guarda NinjaOne in azione!

Inviando questo modulo, accetto La politica sulla privacy di NinjaOne.

Termini e condizioni NinjaOne

Cliccando sul pulsante “Accetto” qui sotto, dichiari di accettare i seguenti termini legali e le nostre condizioni d’uso:

  • Diritti di proprietà: NinjaOne possiede e continuerà a possedere tutti i diritti, i titoli e gli interessi relativi allo script (compreso il copyright). NinjaOne ti concede una licenza limitata per l’utilizzo dello script in conformità con i presenti termini legali.
  • Limitazione d’uso: Puoi utilizzare lo script solo per legittimi scopi personali o aziendali interni e non puoi condividere lo script con altri soggetti.
  • Divieto di ripubblicazione: In nessun caso ti è consentito ripubblicare lo script in una libreria di script appartenente o sotto il controllo di un altro fornitore di software.
  • Esclusione di garanzia: Lo script viene fornito “così com’è” e “come disponibile”, senza garanzie di alcun tipo. NinjaOne non promette né garantisce che lo script sia privo di difetti o che soddisfi le tue esigenze o aspettative specifiche.
  • Assunzione del rischio: L’uso che farai dello script è da intendersi a tuo rischio. Riconosci che l’utilizzo dello script comporta alcuni rischi intrinseci, che comprendi e sei pronto ad assumerti.
  • Rinuncia e liberatoria: Non riterrai NinjaOne responsabile di eventuali conseguenze negative o indesiderate derivanti dall’uso dello script e rinuncerai a qualsiasi diritto legale o di equità e a qualsiasi rivalsa nei confronti di NinjaOne in relazione all’uso dello script.
  • EULA: Se sei un cliente NinjaOne, l’uso dello script è soggetto al Contratto di licenza con l’utente finale (EULA) applicabile.