Quando um sistema para, duas perguntas aparecem rapidamente: quanto de dado a empresa pode perder e por quanto tempo consegue operar sem aquele serviço? RPO e RTO ajudam a transformar essas perguntas em metas de continuidade — e a evitar que o plano de backup seja definido apenas por conveniência técnica.
O que significam RPO e RTO
RPO (Recovery Point Objective), ou objetivo de ponto de recuperação, é a quantidade máxima de dados que a organização aceita perder, expressa como intervalo de tempo. Um RPO de quatro horas significa que, em um cenário de recuperação, a empresa admite que as alterações mais recentes desde o ponto recuperável possam não estar disponíveis. Não é uma promessa de que isso ocorrerá: é um limite de tolerância a estabelecer.
RTO (Recovery Time Objective), ou objetivo de tempo de recuperação, é o prazo-alvo para restabelecer um sistema ou serviço após uma interrupção. O relógio deve incluir etapas reais — identificar o incidente, obter acesso ao ambiente limpo, restaurar dados, validar integridade e reconectar dependências — não apenas o tempo de cópia dos arquivos.
Defina metas a partir do impacto, não do palpite
- Liste serviços e processos. Inclua site institucional, loja virtual, banco de dados, emissão de documentos e ferramentas internas. Relacione cada serviço às dependências técnicas e às áreas que o utilizam.
- Estime o impacto da interrupção. Pergunte às áreas responsáveis o que deixa de funcionar, quais prazos ou compromissos são afetados e quais alternativas manuais existem. Considere períodos de pico e diferenças entre operação e horário comercial.
- Escolha tolerâncias justificáveis. Defina o RPO conforme o volume e o impacto de dados que seria necessário reconstruir. Defina o RTO considerando o tempo máximo de indisponibilidade aceitável, incluindo recuperação e validação.
- Priorize por dependência. Uma aplicação pode depender de DNS, identidade, rede ou banco de dados. Recuperar a interface antes de sua base ou autenticação pode não devolver o serviço ao usuário.
- Compare as metas com a capacidade real. Frequência de backup, retenção, acessos, tamanho dos dados, largura de banda e equipe disponível influenciam o resultado. Se a meta não for viável, registre a lacuna e decida como reduzi-la ou aceite formalmente o risco.
Exemplo simples
Uma loja pode considerar o catálogo e as páginas institucionais menos urgentes que o checkout e os pedidos. O negócio pode definir metas diferentes por serviço, desde que as dependências sejam mapeadas. Se o banco de pedidos tiver um RPO de uma hora, por exemplo, a estratégia precisa produzir e preservar pontos recuperáveis com essa frequência e demonstrar que é possível restaurá-los. Esse número é apenas ilustrativo: a meta correta depende do impacto, da arquitetura e dos recursos disponíveis.
Backup não prova recuperação
Uma tarefa marcada como concluída não demonstra que os dados estão íntegros, que as credenciais de restauração continuam acessíveis ou que a aplicação volta a funcionar. A CISA recomenda manter backups críticos offline e criptografados e testar regularmente sua disponibilidade e integridade em cenários de recuperação. Testes em ambiente isolado ajudam a validar arquivos, banco, permissões, dependências e sequência de retorno sem colocar o serviço de produção em risco.
Registre em cada exercício: cenário, horário de início e fim, ponto dos dados restaurado, erros encontrados, responsáveis e diferença entre o resultado e as metas. Atualize o procedimento após mudanças importantes na aplicação ou infraestrutura.
Checklist para começar
- Nomeie um responsável de negócio e um responsável técnico por serviço.
- Documente RPO, RTO, dependências e ordem de recuperação.
- Confirme que cópias e credenciais não dependem exclusivamente do ambiente comprometido.
- Faça um teste de restauração e cronometre o processo completo, incluindo validação.
- Revise as metas quando mudarem dados, volume, integrações ou requisitos operacionais.
Como a HAD Cloud pode ajudar
Ao planejar hospedagem, VPS ou infraestrutura em nuvem, a equipe precisa conhecer requisitos de disponibilidade, proteção de dados e recuperação. Converse com a HAD Cloud sobre o ambiente e as necessidades do seu negócio para avaliar opções adequadas; disponibilidade de recursos, serviços e condições deve ser confirmada conforme a solução contratada. Nenhuma infraestrutura substitui um plano de continuidade testado.
Perguntas frequentes
RPO zero é sempre necessário?
Não. RPO zero implica não aceitar perda de dados entre falha e recuperação e pode exigir arquitetura e operação específicas. O custo e a complexidade precisam ser comparados ao impacto de perder essas alterações.
RTO é igual ao tempo de restaurar o backup?
Não necessariamente. O RTO deve considerar o tempo total para recuperar e validar o serviço, incluindo infraestrutura, dependências, acessos e testes funcionais.
Com que frequência devo testar a restauração?
Não existe uma frequência universal adequada a todas as empresas. Defina-a conforme criticidade, mudanças no ambiente, requisitos aplicáveis e capacidade de detectar falhas antes de uma crise. Testes menores e recorrentes podem complementar exercícios mais abrangentes.
Fontes consultadas
- CISA — #StopRansomware Guide (orientações sobre backups offline, criptografia e testes regulares de disponibilidade e integridade).
- NIST SP 800-34 Rev. 1 Update 1 — Contingency Planning Guide for Federal Information Systems (planejamento de contingência e recuperação).
