RPO (Recovery Point Objective) é a métrica utilizada para identificar a disponibilização de dados que atendam os RTOs definidos para cada processo de negócio.
Não entendeu nada? Fique tranquilo, é o que eu mais vejo por aí!
Em poucas palavras o RTO é quanto o processo suporta de perda de dados. Não confunda isto com o último backup realizado, equívoco bastante comum entre os profissionais de contingência, infra-estrutura.
O último backup realizado pode servir como métrica para desenvolver uma estratégia para garantir a continuidade de processos de negócios, mas o RTO consiste em um objetivo, como o acrônimo RPO (Recovery Point Objective) deixa claro.
Vamos tentar clarear as coisas. Aconteceu um incidente, preciso restabelecer um processo dentro do objetivo de recuperação que eu identifiquei (RTO). Para restabelecer este processo eu preciso de dados, ai entra o RPO. Se eu preciso de dados de 2 horas (meu RPO) antes do incidente e meu último backup é de 24 horas atrás, tenho um problema sério.
Para atender o meu RPO de duas horas preciso alterar a minha estratégia de backup ou fazer uma reengenharia no processo.
Porque reengenharia no processo?
Porque não é sempre que o meu problema é apenas com dados digitalizados. Se o problema é backup, eu posso mudar minha solução de backup, alterar a estratégia. Agora se o processo depende de informações "não digitais"? Ai só uma reengenharia no processo pode resolver ou minimizar os impactos.
Um comentário:
[...] recuperação caso aconteça algum incidente. Caro leito você pode saber, mas sobre o RTO E RPO no blog do Wagner [...]
Postar um comentário