Durante il design della propria strategia di backup, RPO e RTO sono i parametri più importanti da definire per un piano di protezione dati efficace, ma RTO vs RPO qual è la differenza?
Nonostante RTO e RPO sono sempre menzionati durante il design del piano di disaster recovery, non sempre il loro scopo, utilizzo e la differenza è così chiara.
- Cosa significano RTO e RPO?
- RTO vs RPO, qual è la differenza?
- Perchè sono così importanti nel design della strategia di backup?
Prima di cominciare il design della strategia di backup, è fondamentale capire pienamente cosa sono i parametri RTO e RPO e la differenza tra i due in un design di backup.
RPO
RPO sta per Recovery Point Objective e definisce l'“età” dei propri dati dall'ultimo backup.
Per rendere il concetto semplice da capire anche per i non addetti ai lavori, in parole semplici l'RPO può essere definito come “quanti dati un'azienda è disposta a perdere in seguito ad un disastro”.
L'RPO viene tipicamente misurato in unità di tempo: secondi, minuti, ore, giorni o settimane. Se si verifica in questo momento un disastro e l'ultimo backup è stato fatto due ore fa, significa che l'RPO è di due ore e il proprio business ha perso i dati delle ultime due ore.
Questo articolo è stato scritto per il blog Vembu e può essere consultato in questa pagina. Viene spiegato cosa sono i parametri RTO e RPO e la differenza tra i due.
RTO vs RPO, qual è la differenza?
Mentre l'RTO (Recovery Time Objective) è il periodo di tempo necessario ad effettuare il ripristino della normale operatività nel caso di inattività di un servizio IT, l'RPO (Recovery Point Objective) definisce la frequenza con cui viene fatto il backup, quindi quanti dati vengono persi al verificarsi di un disastro.
Meglio un basso RPO o un basso RTO?
E' da tenere presente che RPO e RTO lavorano insieme e vanno bilanciati attentamente:
- Un basso RPO con un alto valore di RTO = cattivo design, il ripristino da un disastro richiede diverso tempo e quindi una significativa non disponibilità dei servizi IT.
- Un alto RPO con un basso valore di RTO = cattivo design, anche se l'operazione di restore è veloce la quantità di dati persa può essere inaccettabile per il business.
- Un buon bilanciamento tra RPO e RTO = buon design, la perdita di dati e l'inattività di applicazioni e servizi sono molto limitai con un impatto minore sul business.
Tenere in considerazione che valori rigorosi di RTO e RPO incrementano i costi per ottenerli perchè sono necessarie più risorse (computazionali e di banda) e spazio storage. Per tenere i costi sotto controllo, bisogna identificare i valori di RTO vs RPO appropriati in base alla criticità e trovare il miglior bilanciamento per rendere il design della strategia di backup il più economico possibile.
Consultare l'intero articolo RTO vs RPO, what’s the difference? nel blog Vembu.
