RPO e RTO – objetivo de ponto de recuperação e objetivo de tempo de recuperação – são métricas vitais ao desenvolver planos e estratégia de recuperação de desastres (DR).
Eles são fundamentais para descobrir os detalhes de como você se recuperará de uma interrupção não planejada, seja técnica ou, cada vez mais, como resultado de intenções maliciosas, como ransomware.
Isso ocorre porque os requisitos de sua organização, em termos de quantos dados você pode perder e por quanto tempo você pode permitir que os sistemas fiquem indisponíveis, ditam as técnicas e produtos de armazenamento e proteção de dados que você deve especificar.
Este artigo examinará como definimos RPO e RTO, por que eles são importantes e como calculá-los para sua organização e as funções dentro dela.
Definir RTO e RPO
RTO é definido pelo padrão global de TIC para recuperação de desastres, ISO/IEC 27031:2011, como: “O período de tempo dentro do qual os níveis mínimos de serviços e/ou produtos e os sistemas, aplicativos ou funções de suporte devem ser recuperados após a ocorrência de uma interrupção.”
RPO, por sua vez, é definido como: “O ponto no tempo até o qual os dados devem ser recuperados após a ocorrência de uma interrupção.”
Em linguagem simples, RTO é a quantidade de tempo que você pode permitir que sistemas e dados fiquem indisponíveis. É medido no tempo e é o período dentro do qual você requer que os sistemas sejam restaurados após uma interrupção.
RPO é a quantidade de dados que você pode perder. Ele também é medido no tempo, mas visto através das lentes de quantos dados você pode perder. Portanto, será regido por quanto tempo passou até o último backup e/ou instantâneo ou quão recentes os dados estão em um site para o qual você fez o failover.
Assim, por exemplo, uma organização pode determinar que pode trabalhar com um RTO de uma hora e um RPO de duas horas de dados.
No entanto, é provável que a imagem seja menos simples do que isso.
Diferentes RTOs e RPOs para diferentes aplicativos?
Mas o cenário de aplicativos dentro de uma organização não se presta a métricas gerais que cobrem tudo.
A realidade é que RTOs e RPOs granulares são provavelmente o que é necessário para responder a situações do mundo real.
Assim, por exemplo, se todos os seus sistemas caíssem, a prioridade seria restaurar aqueles voltados para o público e geradores de receita, o que pode incluir aplicativos transacionais altamente críticos.
Estes seriam da mais alta prioridade e ocupariam o extremo oposto do continuum de, digamos, dados arquivados armazenados há muito tempo e não utilizados ou dados não estruturados sem restrições de tempo críticas para os negócios.
No que diz respeito às consequências práticas, essas diferenças serão refletidas no uso de diferentes classes de armazenamento e proteção de dados.
Cálculo de RTO e RPO
O ponto de partida é determinar o nível de risco para a organização de sistemas indisponíveis e por quanto tempo isso pode ser tolerado.
Faz sentido categorizar e priorizar sistemas e fazer perguntas como:
Exemplos de RPO e RTO
Os RPOs e RTOs ideais seriam zero. Mas quanto mais perto você chega de zero, mais custa.
Portanto, zero não é uma opção para a maioria dos sistemas, mas alguns precisarão dele – ou seja, sistemas transacionais bancários que quase não suportam perda de dados ou indisponibilidade do sistema.
De forma mais realista, você provavelmente categorizaria aplicativos e sistemas por camada. Assim, por exemplo:
Camada RTO/RPO e método de proteção de dados
A camada, em grande parte, determina o nível de proteção de dados. Assim, por exemplo, os sistemas Tier 1 precisam de gravações duplas e/ou replicação frequente de dados para proteção contra problemas localizados. Ele provavelmente também precisará da capacidade de fazer failover rapidamente para um local remoto em caso de ameaças no nível do site.
Os sistemas de nível 2 precisariam de cópias de dados menos frequentes, mas também precisariam ser capazes de fazer failover para sistemas remotos. Todas as camadas seriam sustentadas por backups diários, bem como preparação para arquivos em nuvem e/ou fita conforme os dados envelhecem.
A capacidade da sua organização de cumprir os acordos de nível de serviço (SLAs) RTO e RPO será determinada pelo escopo da interrupção, portanto, precisa ser trabalhada em conjunto com uma avaliação de risco e análise de impacto nos negócios que analisa o intervalo provável de possíveis causas de tempo de inatividade e as classifica em termos de probabilidade e efeito. Uma falha de disco é obviamente menos impactante do que um site inundado, por exemplo.
Armazenamento em nuvem e RTO/RPO
Ao definir os tipos de armazenamento e proteção de dados adequados à sua organização e aos vários sistemas que ela deve operar e proteger, é cada vez mais provável que você precise usar a nuvem armazenamento em conta.
O uso da nuvem junto com o datacenter é bastante comum, com pesquisas revelando que quase metade dos clientes usam a nuvem para recuperação de desastres de alguma forma.
A dificuldade que traz os requisitos e cálculos de RPO e RTO é que agora você depende de um provedor externo. Portanto, certifique-se de discutir minuciosamente seus requisitos de RPO e RTO para diferentes classes de dados e amarrar o provedor o máximo possível com SLAs claros. Pode haver outras complexidades ao trabalhar com um provedor de nuvem e sites remotos.
Portanto, você pode até considerar que alguns sistemas e dados não podem ser regidos por SLAs de terceiros e descobrir que deseja trazê-los de volta para casa.
