O que são RPO e RTO na recuperação de desastres?

O RTO (recovery time objective) é o tempo máximo que um sistema pode ficar parado depois de uma interrupção. O RPO (recovery point objective) é a maior quantidade de dados que pode perder, medida como o tempo desde a última cópia utilizável. Um RTO de 4 horas e um RPO de 15 minutos significam: voltar a estar em linha em 4 horas, perdendo no máximo 15 minutos de dados.

Pontos principais

• O RTO olha em frente a partir da falha (quanto tempo até o serviço voltar). O RPO olha para trás (que idade tem a última boa cópia dos dados).
• Ambos são decisões de negócio. Defina-os por sistema através de uma análise de impacto no negócio e só depois escolha a tecnologia que os cumpre.
• A frequência das cópias de segurança limita o RPO: com cópias de 4 em 4 horas, a perda de dados no pior caso é de cerca de 4 horas.
• Objetivos mais exigentes custam mais. Um RTO/RPO quase nulo exige replicação e capacidade de reserva num segundo local.
• Os objetivos no papel valem pouco até um teste medir o tempo de recuperação e a perda de dados reais.

O que é o RTO na recuperação de desastres?

O RTO é o tempo máximo aceitável entre a paragem de um serviço e o seu regresso. A AWS define-o como "o atraso máximo aceitável entre a interrupção do serviço e o restabelecimento do serviço" no seu whitepaper Disaster Recovery of Workloads on AWS. O NIST enquadra-o do lado do negócio: o tempo que um sistema pode estar em recuperação "antes de afetar negativamente a missão da organização ou os seus processos de missão/negócio".

O RTO abrange toda a recuperação, não apenas o restauro técnico. A deteção, a decisão de acionar o plano de DR, o restauro dos dados, a validação da aplicação e a migração dos utilizadores contam todos para ele. As equipas que cronometram apenas o restauro costumam falhar o RTO num evento real.

O que é o RPO na recuperação de desastres?

O RPO é a perda de dados máxima aceitável, expressa em tempo. A AWS descreve-o como "a quantidade máxima de tempo aceitável desde o último ponto de recuperação de dados". Se o seu RPO for de 1 hora, então, após uma falha, tem de conseguir restaurar dados com no máximo 1 hora.

O RPO depende da frequência com que copia os dados. Cópias de segurança noturnas dão um RPO de cerca de 24 horas no pior caso. Cópias dos registos de transações da base de dados de 15 em 15 minutos dão aproximadamente 15 minutos. A replicação contínua pode aproximá-lo de zero, com uma ressalva abordada mais abaixo: a replicação copia também a corrupção e as eliminações.

RTO vs RPO: a diferença num relance

Exemplos práticos

Exemplo 1: um sistema de encomendas. Uma loja online define um RTO de 4 horas e um RPO de 15 minutos. A base de dados falha às 10:00. A loja tem de voltar a aceitar encomendas até às 14:00, e podem faltar no máximo as encomendas feitas entre as 09:45 e as 10:00. Cópias de segurança noturnas não chegam; a loja precisa de cópias dos registos de transações ou de replicação, pelo menos de 15 em 15 minutos, e de uma forma automatizada de reconstruir a camada aplicacional em menos de 4 horas.

Exemplo 2: verificar um calendário de cópias de segurança. Um sistema financeiro tem cópias de 6 em 6 horas e um restauro completo demora 3 horas. Se o negócio pedir um RPO de 1 hora e um RTO de 2 horas, ambos os objetivos falham: a perda de dados no pior caso é de cerca de 6 horas e só o restauro excede o RTO. A solução passa por cópias mais frequentes e um método de recuperação mais rápido, ou por uma decisão de negócio de aceitar objetivos menos exigentes.

Exemplo 3: classificar um portefólio por camadas. A maioria das empresas agrupa os sistemas em camadas em vez de definir objetivos um a um. Os valores abaixo são ilustrativos, não uma norma.

A coluna da estratégia segue as quatro abordagens do whitepaper da AWS, em que a cópia de segurança e restauro permite recuperar em horas e o multi-site ativo/ativo em tempo quase real. O nosso guia sobre o plano de recuperação de desastres explica cada estratégia e como escolher.

Como se relacionam o RTO e o RPO com o tempo máximo tolerável de indisponibilidade?

O tempo máximo tolerável de indisponibilidade (MTD) é o tempo que um processo de negócio pode ficar interrompido antes de os danos se tornarem graves. A NIST SP 800-34 explica que o RTO "tem normalmente de ser inferior ao MTD", porque, depois de os sistemas voltarem, as equipas ainda precisam de tempo para recuperar o atraso acumulado e reintroduzir os dados perdidos. O RPO não faz parte do MTD. Descreve a quantidade de dados que o processo pode perder (NIST SP 800-34 Rev. 1).

Na prática: se o processo de encomendas aguentar 8 horas sem sistemas e recuperar o atraso demorar 2 horas, o RTO de TI tem de ser de 6 horas ou menos.

Como definir o RTO e o RPO

1. Liste os processos de negócio e as suas dependências. Associe cada processo às aplicações, bases de dados, serviços de identidade e terceiros de que precisa.
2. Estime o impacto da indisponibilidade e da perda de dados ao longo do tempo. Receitas, penalizações contratuais, exposição regulamentar, segurança e reputação. A AWS salienta que o impacto pode depender do momento: uma falha no processamento de salários mesmo antes do dia de pagamento pesa muito mais do que uma logo a seguir.
3. Proponha objetivos por camada e peça ao responsável do negócio que os aprove. A área de TI não deve escolhê-los sozinha.
4. Calcule o preço das opções. A AWS aconselha que, se a estratégia de recuperação custar mais do que a falha que protege, "não deve ser implementada, a menos que exista um fator secundário, como requisitos regulamentares".
5. Conceba e teste. Construa os mecanismos de cópia de segurança, replicação e failover, execute um teste e registe o tempo e o ponto de recuperação alcançados.
6. Reveja anualmente e após alterações importantes. Os sistemas mudam de camada à medida que o negócio muda.

Que tecnologias cumprem que objetivos?

• Cópias de segurança e snapshots agendados adequam-se a RPO de horas. Protegem bem contra corrupção e eliminação, porque cada cópia é um ponto fixo no tempo.
• A recuperação para um ponto no tempo (cópias dos registos de transações) reduz o RPO a minutos nas bases de dados.
• A replicação assíncrona para outra região dá um RPO de segundos a minutos, consoante o atraso de replicação.
• A replicação síncrona entre Availability Zones dá um RPO próximo de zero, à custa da latência de escrita. As orientações do Azure Well-Architected sobre recuperação de desastres, da Microsoft, sugerem replicação síncrona entre zonas para dados de alta prioridade e replicação assíncrona entre regiões para dados de menor prioridade.
• Ambientes de reserva e automatização (pilot light, warm standby, infraestrutura como código, failover de DNS automatizado) reduzem o RTO.

Cuidado com a armadilha da replicação. A AWS observa que a replicação contínua "pode não proteger contra eventos de desastre, como corrupção de dados ou ataques maliciosos", tão bem como as cópias para um ponto no tempo. Uma base de dados encriptada por ransomware replica-se tão depressa como uma saudável, por isso mantenha cópias para um ponto no tempo a par das réplicas.

Como provar que cumpre os seus objetivos

Meça, não presuma. Em cada teste de DR, registe quando a falha começou, quando o plano foi acionado, quando o serviço voltou e a hora da última transação recuperada. Isso dá-lhe o RTO e o RPO alcançados. As orientações da Microsoft recomendam uma combinação de exercícios de mesa, ensaios em ambientes que não são de produção e simulacros ao nível da produção. Acompanhe os resultados ao longo do tempo e corrija primeiro o passo mais lento.

Como a Opsio ajuda

A Opsio realiza workshops de impacto no negócio, define o RTO/RPO por camada com os responsáveis do negócio e constrói e testa o desenho de recuperação correspondente na AWS e no Azure através do seu serviço de recuperação de desastres na cloud. Para a plataforma SaaS de recrutamento WorkBuster, uma abordagem de indisponibilidade quase nula foi um requisito obrigatório quando a Opsio migrou a plataforma para a AWS. O desenho utiliza uma base de dados MySQL multi-AZ de alta disponibilidade no Amazon RDS, com a infraestrutura definida em modelos CloudFormation.

Perguntas frequentes

Qual é a diferença entre RTO e RPO?

O RTO é o tempo que um sistema pode ficar indisponível depois de uma interrupção. O RPO é a quantidade de dados, medida em tempo, que pode perder. O RTO diz respeito à indisponibilidade; o RPO, à perda de dados.

O que são bons valores de RTO e RPO?

Não existe um número universal. Um sistema de pagamentos pode precisar de minutos em ambos, enquanto uma ferramenta interna de reporting pode aceitar 24 horas. Derive os objetivos do custo da indisponibilidade e da perda de dados de cada processo de negócio e verifique depois o custo de os cumprir.

O RPO pode ser zero?

Perto de zero, sim, com replicação síncrona ou desenhos multi-site ativo/ativo. Garantir uma perda de dados verdadeiramente nula entre regiões é difícil, devido à distância e à latência, e a replicação por si só não protege contra a corrupção.

O RTO é o mesmo que um SLA?

Não. Um SLA é uma promessa aos clientes sobre disponibilidade ou resposta. O RTO é um objetivo interno de recuperação para um cenário de desastre. O o seu RTO deve apoiar os seus SLA, mas medem-se de forma diferente.

Com que frequência se devem rever os objetivos de recuperação?

Pelo menos uma vez por ano e após alterações importantes aos sistemas, aos fornecedores ou ao negócio. Volte a medi-los em cada teste de DR, pois o que conta são os valores alcançados.