RTO vs RPO - Compreendendo a principal diferença

Embora as duas métricas possam parecer semelhantes, o Objetivo de Tempo de Recuperação (RTO) e o Objetivo de Ponto de Recuperação (RPO) desempenham funções totalmente diferentes no backup e na recuperação de desastres (BDR). Compreender as diferenças entre essas métricas (e como elas funcionam em conjunto) é fundamental para sobreviver a incidentes que ameaçam a receita sem tempo de inatividade dispendioso ou perda de dados.

Este artigo oferece uma comparação detalhada entre RTO e RPO que explica a função distinta de cada métrica no planejamento de continuidade de negócios (BC). Continue lendo para saber o que esses parâmetros envolvem (tanto no sentido técnico quanto comercial) e veja por que não há como manter os ativos de negócios seguros sem um RTO e RPO bem definidos.

Principais diferenças entre RTO e RPO

Aqui está o que RTO e RPO significam:

• RTO (Recovery Time Objective) é o período de tempo dentro do qual um ativo (produto, serviço, rede, etc.) deve voltar a ficar online caso fique inativo.
• RPO (Recovery Point Objective) é a quantidade aceitável de dados (medida pelo tempo) que uma empresa está disposta a perder em caso de incidente.

Ambas as métricas são medidas de tempo e são vitais para uma recuperação eficaz de desastres. Ambos exigem um planejamento abrangente e uma mentalidade de segurança proativa, mas há diversas diferenças notáveis entre RTOs e RPOs:

• O RTO concentra-se na recuperação de aplicativos e infraestrutura, enquanto o RPO se concentra exclusivamente na frequência de backup e nas perdas de dados aceitáveis.
• A RTO considera todos os aspectos da estrutura do negócio e todo o processo de DR. O RPO avalia apenas a criticidade dos dados e o custo da replicação.
• O RTO é o processo mais complexo dos dois, pois envolve mais partes e variáveis móveis (locais quentes e frios, failovers, equipes de resposta direta, etc.).
• Um RPO depende muito da automação para fazer backup e restaurar dados, enquanto os RTOs envolvem tarefas mais manuais e uma abordagem mais prática para recuperação.
• O RPO é mais fácil de calcular porque a métrica cobre apenas um aspecto do processo de recuperação: os dados.
• RPOs baixos são muito mais baratos que RTOs baixos devido à diferença significativa no escopo.

Juntos, RTOs e RPOs permitem que uma empresa saiba por quanto tempo ela pode ficar inativa e quão recentes serão os dados após a recuperação. A maioria das empresas prefere se recuperar das interrupções o mais rápido possível, mas quanto mais curto for o RTO ou RPO, o custo da recuperação aumenta (e vice-versa).

O que é RTO

Um Objetivo de Tempo de Recuperação (RTO) representa o período de tempo dentro do qual um recurso de TI deve se recuperar totalmente de um evento perturbador. Por exemplo, um sistema pode ter um RTO de 30 minutos. Nesse caso, a equipe de resposta a incidentes tem meia hora para colocar tudo de volta em funcionamento após um incidente.

O “relógio” do RTO começa a funcionar quando o sistema afetado fica inativo e termina quando o sistema está totalmente operacional novamente. Alguns RTOs começam quando a equipe responsável recebe uma notificação sobre o incidente, uma abordagem mais comum para sistemas que não são de missão crítica.

Qualquer sistema com um RTO definido também deve medir o Tempo de recuperação real (RTA). O RTA representa a duração real do processo de recuperação. RTAs e RTOs raramente são idênticos, mas o objetivo é manter o RTA dentro do prazo esperado do RTO (RTA ≤ RTO).

Se o RTA ultrapassar a marca RTO, você poderá:

• Revisite o cálculo do RTO e reduza o limite de recuperação (uma abordagem que muitas vezes leva a reduções de custos de TI).
• Atualize seu plano de recuperação de desastres para garantir respostas mais rápidas no futuro.

Um RTO normalmente é igual ao tempo de inatividade máximo que um sistema pode tolerar sem afetar a continuidade dos negócios. Cada sistema tem um nível de tolerância diferente para ficar offline, portanto não há necessidade de ter um RTO baixo para cada ativo. Por exemplo, um banco de dados de RH não requer a mesma velocidade de recuperação que seu servidor primário ou firewall.

Como calcular o RTO

Não existe uma fórmula matemática para calcular um RTO que funcione para cada empresa ou tipo de sistema. Descobrir um prazo de recuperação ideal começa com uma análise aprofundada de risco e impacto nos negócios (BIA) que examina as características exclusivas de cada ativo, incluindo:

• Consequências da queda do sistema (monetárias, regulatórias, reputacionais, etc.).
• Criticidade geral da missão (ou seja, qual seria o impacto do tempo de inatividade do sistema para outros sistemas e usuários finais).
• O custo estimado de uma interrupção (normalmente calculado em minutos ou horas)
• Período máximo tolerável de interrupção (MTPD).
• Vulnerabilidades avaliadas atualmente no sistema.
• As medidas e recursos de segurança atuais que protegem o ativo.
• Ameaças potenciais (quedas de energia, desastres naturais locais, tipos específicos de ataques cibernéticos, etc.).
• A probabilidade de o sistema apresentar problemas.
• Implicações de conformidade específicas do setor.

Assim que houver um entendimento profundo do sistema, a equipe de análise define um RTO ideal do ponto de vista de TI. O próximo passo é consultar os líderes das unidades de negócios e a alta administração para determinar se o RTO sugerido é viável do ponto de vista orçamentário.

No caso de RTOs, mais rápido sempre significa mais caro. Qualquer RTO que espera que o sistema esteja online novamente em menos de uma hora requer um grande investimento, portanto, não defina RTOs baixos para cada ativo. Determinar RTOs requer um equilíbrio entre:

• Consequências do sistema sofrer tempo de inatividade.
• O risco de algo dar errado com o sistema.
• O preço de configurar o processo de recuperação.

O que é RPO

O objetivo do ponto de recuperação (RPO) é a quantidade máxima de dados que uma empresa está disposta a perder durante um incidente. As equipes medem os RPOs em horas ou minutos desde o último backup de dados em funcionamento. Depois que o período de RPO passa em um cenário de desastre, a quantidade de dados perdidos excede o limite máximo permitido.

Por exemplo, se um sistema tiver um RPO de 3 horas, a equipe deverá ter sempre uma cópia de trabalho dos dados com no máximo 3 horas. Em caso de desastre, o sistema afetado pode perder até 3 horas de dados sem causar problemas de longo prazo.

RPOs normalmente não se aplicam a dados arquivados e históricos. Essa métrica se concentra em arquivos transacionais e atualizações que entraram recentemente em um sistema.

O RPO determina a frequência com que uma empresa deve criar backups para garantir que a perda de dados não exceda o limite de tolerância. Quanto mais curto o RPO, menos dados correm risco de perda (permanente ou temporária).

Tal como acontece com os RTOs, os RPOs mais curtos requerem um investimento mais significativo do que os mais longos. RPOs zero ou quase zero normalmente exigem:

• Tecnologia de backup de alta velocidade (como replicação contínua e espelhamento de dados).
• Grandes quantidades de largura de banda de rede para transmitir dados.

Essas medidas são caras para configurar e manter, portanto, determinar os RPOs exige que a equipe encontre o meio-termo entre:

• O impacto da perda de dados.
• O custo de configuração de medidas de backup e recuperação.

Qualquer conjunto de dados com um RPO também deve medir o Ponto de recuperação real (RPA). Esta métrica representa a quantidade exata de dados perdidos durante um incidente, portanto seu RPA deve ser menor ou igual ao RPO definido.

Como calcular o RPO

Assim como acontece com os RTOs, não existem fórmulas para determinar um RPO que funcione para todas as empresas. Descobrir RPOs requer uma análise aprofundada de cada conjunto de dados. Aqui estão os principais fatores:

• As consequências financeiras e operacionais da perda de dados.
• Probabilidade de incidentes.
• O número de aplicativos que dependem do conjunto de dados.
• O custo de implementação da estratégia RPO.
• Regulamentos de armazenamento relevantes.

A maioria das empresas faz backup de seus dados em intervalos fixos (uma vez por hora, por dia, por semana, etc.). Aqui estão os quatro prazos de RPO mais comuns e alguns casos de uso comuns:

• RPOs contínuos ou nulos: conjuntos de dados que não podem arcar com perdas devido à missão crítica, regulamentações ou dificuldade de recriação. Os exemplos incluem informações de gateway de pagamento, registros de pacientes e atividades de negociação no mercado de ações.
• Uma a quatro horas: esse período é padrão para unidades de negócios semicríticas com tolerância limitada a perdas. Exemplos são registros de bate-papo de clientes, painéis de produtos e sistemas de autenticação de senha.
• Quatro a doze horas: Este RPO é a opção ideal para conjuntos de dados que têm pouco impacto em um negócio se algo der errado, como bancos de dados de estatísticas de marketing ou vendas.
• Entre 13 e 24 horas: RPOs mais longos são adequados para dados não críticos, como pedidos de compra ou arquivos de controle de estoque.

A maioria dos conjuntos de dados que não se enquadram em nenhuma das categorias acima exige backups semanais. Você tem duas opções ao escolher como fazer backup de seus dados:

• No local: você armazena réplicas em um computador ou sala de servidores diferente em seu escritório. Esses backups são vulneráveis a eventos localizados que afetam o armazenamento primário e secundário.
• Fora do local: manter backups de dados em uma instalação secundária ou em um data center de terceiros elimina o perigo de perder todas as soluções de armazenamento devido a um único incidente. A maioria das empresas que possuem backups externos depende do armazenamento em nuvem.

RTO vs RPO: limites vitais para tempo de inatividade e perda de dados

Prever exatamente quando os incidentes ocorrerão é impossível, mas preparar-se para eventos infelizes não é. RTOs e RPOs confiáveis garantem que você controle as consequências dos problemas e que as interrupções não afetem significativamente seus resultados financeiros. Esses benefícios fazem com que reservar tempo e recursos para preparar RTOs e RPOs seja uma decisão óbvia para a maioria das empresas.