O que é RPO?

RPO em uma tradução livre significa Objetivo do Ponto de Recuperação, resumidamente engloba o volume de dados perdidos nos casos de tempo de inatividade do serviço. Se a recuperação de um sistema com erro foi feita rapidamente (em minutos), isso não significa que a empresa perderá apenas esses minutos de trabalho pois os dados recuperados poderiam ter sido capturados há uma semana, de modo que a perda real de dados nesse caso seria de uma semana.

Ilustrando com um exemplo para ficar mais claro: a empresa possui um software que grava solicitações de atendimento dos clientes em um banco de dados, por um defeito no servidor inesperadamente às 11:30 da manhã o banco de dados é corrompido necessitando retornar um backup:

• Se o último backup do banco de dados ocorreu à 01:00 da manhã, a empresa perderá todas as solicitações de atendimento criadas entre 01:00 e o momento do erro no banco de dados (11:30).
• Agora, se o último backup foi feito há apenas um minuto, a empresa perderá somente os dados gerados nesse último minuto, isso não é muito melhor?

Obviamente, qualquer empresa que implementa estratégias de backup ou recuperação de desastres tende a minimizar a RPO para o menor valor possível. Mas é importante entender que RPOs mais baixas podem exigir uma solução de backup mais cara. O resultado geral da configuração de uma RPO baixa depende do volume de dados, das soluções de backup disponíveis e da capacidade de toda a sua infraestrutura de TI. Por isso, é crucial medir o custo real de perda de dados potencial que uma empresa pode pagar, com essa RPO em mente é possível tomar a melhor decisão sobre o backup ou as soluções de recuperação de desastre necessárias.

O que é RTO?

RTO em uma tradução livre significa Objetivo de Tempo de Recuperação, definido como o período de tempo desejado necessário para realizar todas as tarefas de recuperação antes que um aplicativo ou serviço possa executar solicitações normalmente novamente, resumidamente quanto tempo um serviço ou estrutura de TI pode ficar parada aguardando recuperação?

Da perspectiva da infra-estrutura de TI, é influenciado pelo período de tempo entre o caos (tudo parado inesperadamente) e o momento que tudo é recuperado e restaurado, ou downtime não planejado.

RTO para departamentos de TI é influenciada pelas tecnologias utilizadas, mas para as empresas, ela é muito mais importante. Se a empresa usa os serviços de TI como base de suas atividades financeiras ou para suporte de back-office, cada minuto de tempo de inatividade custará muito, senão tudo. Quanto maior a empresa – mais dinheiro jogado fora em casos de tempo de inatividade não planejados. É por isso que os empresários estão mais interessados ​​no objetivo de tempo de recuperação ao criar planos de backup e recuperação.

Diferenças

RTO e RPO são métricas de negócios que podem ajudar a calcular com que frequência executar backups de dados. No entanto, existem algumas diferenças importantes:

Base de avaliação

A RTO reflete as necessidades comerciais globais do negócio, é uma medida de quanto tempo a empresa pode sobreviver com a infra-estrutura de TI e serviços interrompidos. Em contraste, RPO é apenas sobre dados, ele determina com que frequência fazer backup de dados e não reflete outras necessidades de TI.

Automação

Conhecer as metas RPO exige a execução de backups de dados no intervalo certo. Os backups de dados podem ser facilmente automatizados, e uma estratégia de RPO automática é, portanto, fácil de implementar. A RTO, por outro lado, é mais complicada porque envolve a restauração de todas as operações de TI. É praticamente impossível atingir os objetivos de RTO de forma completamente automática, embora deve-se automatizar o máximo do processo de recuperação possível.

Relevância do custo

Os custos associados à manutenção de uma RTO exigente podem ser superiores aos de uma RPO granular. Isso porque RTO envolve toda a infraestrutura comercial, não apenas dados.

Facilidade de cálculo

De certa forma, a RPO é mais fácil de implementar porque o uso de dados é relativamente consistente e há menos variáveis. Já os tempos de restauração envolvem toda a operação, não apenas dados, por isso o cálculo é mais complicado, podendo inclusive mudar com base em fatores como a hora do dia ou o dia da semana em que ocorre um desastre. Além disso, a RTO deve ser alinhada junto à área de TI, se o tempo de restauração mínimo  de um sistema for de 2 horas, então uma RTO de 1 hora nunca será cumprida. Os administradores devem ter uma boa compreensão das velocidades com as quais diferentes tipos de restauração podem ocorrer, só então uma RTO pode ser devidamente negociado e cumprida com base nas necessidades do negócio.

Veja na segunda e última parte, as aplicações desses conceitos.

Atualizado em 01/12/2017 às 16:15.