Mais de 72% das empresas não conseguem atender às suas expectativas de recuperação de TI relacionadas aos seus objetivos de ponto de recuperação (RPO) e objetivos de tempo de recuperação (RTO).
Para ajudá-lo a criar um plano de recuperação eficiente, é essencial que você compreenda completamente o RTO e o RPO e conheça as diferenças entre eles. Este post explica tudo o que você precisa saber sobre esses dois parâmetros para uma estratégia de recuperação de desastres confiável. Continue lendo para descobrir como você pode alcançar RPO e RTO mais rígidos para minimizar a perda de dados e retomar as operações comerciais normais o mais rápido possível após um desastre.
O que é RTO?
O objetivo do tempo de recuperação (RTO) refere-se ao tempo máximo de inatividade que uma organização pode tolerar após um evento disruptivo. Em outras palavras, o RTO é o período entre a ocorrência de um desastre e a recuperação das cargas de trabalho críticas afetadas.
O cálculo do RTO geralmente depende do seu plano de recuperação de desastres, dos recursos disponíveis e do orçamento. Enquanto sua infraestrutura de TI estiver indisponível, você precisa de algum tempo para identificar o(s) motivo(s) da falha e tomar as medidas necessárias para corrigir o problema. No entanto, as etapas de recuperação de desastres devem estar em vigor para garantir que os sistemas críticos e as cargas de trabalho estejam acessíveis e disponíveis enquanto o problema de produção é resolvido. Seu RTO é o tempo entre a falha e a disponibilidade dos sistemas por meio de backups ou cargas de trabalho de réplica.
O que é RPO?
O objetivo do ponto de recuperação (RPO) representa a quantidade máxima de dados que uma organização pode suportar perder em um desastre sem consequências críticas. Esta métrica é medida em horas/minutos desde os últimos processos de backups/replicação. Use-a para determinar com que frequência você precisa criar backups de dados e réplicas para reduzir a perda de dados após um evento disruptivo.
Em uma situação ideal, um trabalho de backup ou replicação é concluído logo antes da falha da máquina original. No entanto, isso é raro na vida real, então você tem uma lacuna entre o momento em que o último backup bem-sucedido foi criado e o momento em que a máquina original falha. Durante este tempo, a VM estava realizando operações e armazenando dados, e é muito provável que esses dados serão perdidos.
O que é RTO e RPO em Recuperação de Desastres
O objetivo final da proteção de dados é claro: você deseja ter certeza de que os dados críticos não serão perdidos se algo der errado e de que você pode atender aos SLAs da sua organização em termos de tempo de atividade e disponibilidade. No entanto, é bastante custoso espelhar todas as mudanças no seu ambiente virtual para um site de recuperação de desastres (DR) em tempo real. É por isso que você precisa aceitar a ideia de que perderá alguns dados e seus serviços de TI serão interrompidos em caso de falha. Assim, sua tarefa é minimizar essas perdas e interrupções.
Vamos ilustrar os conceitos de RPO e RTO em um diagrama simples:
O diagrama mostra um cenário comum: uma máquina virtual falha por algum motivo. A linha amarela representa o RPO, que é o tempo entre o último backup e a interrupção. A linha laranja é o RTO e reflete o tempo necessário para restaurar a VM.
Diferenças Entre RTO e RPO
Para entender como determinar o RTO e o RPO, você deve observar suas diferenças e seu papel no processo de DR.
Avaliação
- RTO diz respeito principalmente ao período de tempo dentro do qual se espera que as operações comerciais sejam retomadas durante um desastre. Os pontos a considerar são:
- Avalie as necessidades e prioridades da sua organização, pois são únicas para cada organização.
- Considere quais aplicativos são os mais críticos para os serviços e aplicativos críticos para a sobrevivência da organização, bem como quais podem ser as repercussões se esses aplicativos falharem.
- Determine a ordem na qual cada sistema/aplicativo deve ser restaurado para garantir uma recuperação de desastres bem-sucedida com perdas mínimas de tempo de inatividade.
- RPO está mais focado na quantidade de dados que podem ser perdidos durante o tempo de inatividade sem causar danos graves ao resultado final de uma organização. Os pontos a considerar são:
- Identifique a frequência de backup/replicação e quanto de dados pode ser perdido entre o backup VM mais recente e um desastre real.
- Considere a quantidade de dados que sua organização pode se dar ao luxo de perder para cada tipo de carga de trabalho.
Custos
A principal diferença entre RTO e RPO é que o primeiro leva em consideração todos os aspectos da estrutura de negócios e o processo de recuperação de desastres como um todo, enquanto o último considera apenas a criticidade dos dados e aplicativos para a continuidade dos negócios. Portanto, atender aos valores de RTO pode ser uma tarefa exigente e cara para garantir uma recuperação rápida. Da mesma forma, ter RPOs menores significa que você precisa realizar mais backups e criar pontos de recuperação adicionais, o que pode aumentar seus custos de armazenamento.
Automação
- Como o RPO está focado em dados e na resiliência do seu sistema à perda, é recomendável que você faça backups frequentes de dados. Muitas soluções modernas de backup permitem que você faça backups de VM automatizados, o que significa que suas estratégias de backup podem ser adaptadas de forma a atender eficientemente seus objetivos de RPO, com o mínimo de intervenção de sua parte.
- Alcançar o RTO é um processo mais complexo de gerenciar, pois leva em consideração todos os processos de negócios e componentes do sistema que precisam ser recuperados durante um evento de recuperação de desastres. Dito isso, é recomendável automatizar e orquestrar todo o processo de recuperação de desastres do início ao fim para garantir que seus objetivos de RTO possam ser atendidos.
Facilidade de cálculo
- A métrica de RPO é fácil de calcular, pois abrange apenas um aspecto do processo de recuperação – os dados.
- RTO considera todos os aspectos da sua organização, incluindo a importância dos seus dados e serviços, o custo do tempo de inatividade, investimento em atividades de DR, etc. Ao calcular o RTO, você deve levar em consideração os diferentes tipos de cargas de trabalho e aplicativos, pois podem ter processos de recuperação variados. É aconselhável calcular o RTO com base em um plano de continuidade de negócios, que descreve possíveis riscos e ameaças comerciais e descreve as etapas a serem tomadas para retomar as operações comerciais.
Para definir o RTO aplicável às diferentes cargas de trabalho em suas organizações, responda à seguinte pergunta:
Por quanto tempo um aplicativo/sistema/máquina específico pode ficar inativo sem ter um impacto significativo nas operações principais da sua organização?
Depois de responder a esta pergunta para diferentes máquinas, considere se os resultados esperados podem atender às suas necessidades comerciais atuais. Se não, pense em como poderia melhorar suas estratégias de backup e DR para manter os dados de backup o mais atualizados possível.
Como alcançar RPO e RTO mais rigorosos com a NAKIVO
O NAKIVO Backup & Replication permite que você crie backups de máquinas virtuais e físicas com mais frequência, melhorando o RPO. Basta agendar backups regulares com um intervalo que não seja superior ao seu objetivo.
A solução também ajuda a reduzir o RTO com recuperação instantânea de VM e funcionalidade de replicação para VMware vSphere, Microsoft Hyper-V e Amazon EC2. Integre seus serviços de monitoramento de rede e acione imediatamente um processo de recuperação após uma VM ficar indisponível. Você também pode criar réplicas offsite (cópias exatas) de VMs críticas. Se a VM original falhar, as réplicas serão ativadas automaticamente. Se manter réplicas requer mais recursos do que você pode arcar, você pode optar pelo recurso de inicialização instantânea de VM a partir do backup.
Para alcançar os RTOs mais rigorosos, o NAKIVO Backup & Replication introduziu a funcionalidade de orquestração de recuperação do site. Automatize completamente a falha e o retorno da VM para diferentes cenários de DR e realize testes não disruptivos para garantir a recuperação dentro do prazo esperado.