Backup e disaster recovery: RTO, RPO e o plano que salva a empresa

Todo mundo concorda que backup é importante. Quase ninguém testa o seu. Essa distância entre a intenção e a prática é o que transforma um incidente contornável em uma crise existencial. Um ataque de ransomware, uma falha de hardware, um erro humano que apaga a tabela errada, uma região inteira de nuvem fora do ar: nada disso é hipótese, é questão de quando. E, na hora, a única coisa que importa é uma pergunta brutalmente simples: em quanto tempo você volta, e com quantos dados a menos?

Responder a essa pergunta com números, e não com esperança, é o trabalho de uma boa estratégia de backup e disaster recovery (DR). Este guia vai além do "faça backup": explica os dois indicadores que orientam todas as decisões (RTO e RPO), como construir backups que resistem a ataque, por que testar restauração é inegociável e quais estratégias de DR existem, com seus custos e seus tempos de recuperação.

Backup e disaster recovery não são a mesma coisa

Os termos são usados como sinônimos, mas resolvem problemas diferentes, e confundir os dois deixa lacunas perigosas.

• Backup é a cópia dos dados, guardada para poder ser restaurada. Responde à pergunta "perdi ou corrompi dados, como recupero?".
• Disaster recovery é o plano e a infraestrutura para colocar a operação inteira de volta no ar após um desastre. Responde à pergunta "meu ambiente caiu, como volto a funcionar?".

Ter backup sem plano de DR é ter as peças sem o manual de montagem. Você preserva os dados, mas ninguém sabe exatamente como, em qual ordem e em quanto tempo reconstruir os sistemas. DR é backup transformado em capacidade de retomar o negócio.

RTO e RPO: os dois números que definem tudo

Toda decisão de backup e DR se reduz a equilibrar custo contra duas métricas. Entendê-las é o coração do assunto.

• RTO (Recovery Time Objective): o tempo máximo aceitável para restaurar o serviço após uma interrupção. Um RTO de 4 horas significa "não podemos ficar fora do ar por mais de 4 horas".
• RPO (Recovery Point Objective): a quantidade máxima de dados que a empresa aceita perder, medida em tempo. Um RPO de 1 hora significa "podemos perder, no pior caso, a última hora de dados".

A diferença fica clara em um exemplo. Se o seu backup roda uma vez por dia, à meia-noite, e o desastre acontece às 23h, você perde quase 24 horas de dados. Seu RPO real é de 24 horas, mesmo que você desejasse que fosse de 1 hora. Querer um RPO menor exige backups mais frequentes ou replicação contínua.

Esses dois números não são técnicos, são decisões de negócio. Quanto menor o RTO e o RPO desejados, maior o custo da solução. Um sistema de faturamento crítico pode justificar RTO e RPO de minutos; um relatório interno tolera horas ou dias. O erro clássico é aplicar o mesmo padrão a tudo, gastando demais no que não importa e de menos no que importa.

A regra 3-2-1-1-0 para backups que resistem a ataque

A regra clássica de backup era a 3-2-1. A era do ransomware, em que os atacantes procuram e destroem os backups antes de cifrar, exigiu dois números a mais. A versão moderna é a 3-2-1-1-0:

• 3 cópias dos dados (a produção mais duas cópias).
• 2 tipos de mídia diferentes.
• 1 cópia fora do local (offsite), para sobreviver a um desastre físico.
• 1 cópia imutável ou offline, que não pode ser apagada nem cifrada por um atacante que comprometa o ambiente.
• 0 erros na restauração, comprovados por testes.

Os dois últimos são os que separam a resiliência real da falsa sensação de segurança. A imutabilidade (via object lock, WORM ou mídia offline) garante que existe uma cópia que nem um administrador comprometido consegue destruir. E o zero erros só se prova de um jeito: restaurando.

Testar restauração: o passo que quase todos pulam

Um backup que nunca foi restaurado não é um backup, é uma promessa não verificada. Backups falham de formas silenciosas: arquivos corrompidos, jobs que pararam sem alarme, dados incompletos, mídia ilegível, uma chave de criptografia perdida que torna a cópia inútil. Você só descobre no pior momento possível, a menos que teste antes.

Boas práticas de teste de restauração:

• Restaure de verdade, com regularidade, em um ambiente isolado, e verifique a integridade do que voltou.
• Cronometre o processo: o tempo real de restauração é o seu RTO de verdade, que costuma ser bem maior que o estimado no papel.
• Faça simulações de desastre (DR drills): ensaie o cenário completo, não só a volta de um arquivo. É o ensaio geral que revela o que falta no plano.
• Documente e melhore: cada teste expõe uma lacuna. Corrija e teste de novo.

Estratégias de disaster recovery na nuvem

A nuvem tornou o DR acessível ao permitir provisionar ambientes de recuperação sob demanda. As estratégias se organizam em um espectro que troca custo por velocidade de recuperação.

Estratégia	Como funciona	RTO típico	Custo	Quando usar
Backup e restauração	Restaurar dados e recriar a infra do zero	Horas a dias	Muito baixo	Sistemas não críticos, RTO folgado
Pilot light	Núcleo mínimo sempre ligado, resto sob demanda	Dezenas de minutos	Baixo	Bom equilíbrio custo/tempo
Warm standby	Ambiente reduzido sempre rodando, escala na hora	Minutos	Médio	Sistemas importantes
Multi-site ativo-ativo	Dois ambientes plenos operando em paralelo	Quase zero	Alto	Serviços críticos, zero downtime

A escolha vem direto do RTO e do RPO definidos para cada sistema. Não existe estratégia certa em abstrato; existe a estratégia adequada ao valor daquele serviço e ao que a empresa aceita perder.

O plano: pessoas, ordem e comunicação

Tecnologia é metade do DR. A outra metade é o plano que orquestra a recuperação sob estresse. Um plano eficaz define:

• Papéis e responsabilidades: quem declara o desastre, quem executa a recuperação, quem comunica.
• Ordem de recuperação: quais sistemas voltam primeiro. Restaurar na sequência errada trava a retomada.
• Runbooks passo a passo: procedimentos claros que qualquer pessoa treinada consiga seguir, sem depender de um único herói que talvez esteja indisponível.
• Comunicação: como avisar equipe, clientes e, quando envolver dados pessoais, a ANPD e os titulares, conforme a LGPD.
• Dependências externas: provedores, integrações e serviços de terceiros que precisam estar no radar.

Um plano guardado numa gaveta e nunca ensaiado falha justamente quando é necessário. O plano precisa ser um documento vivo, testado e conhecido.

Resiliência é o que você pratica, não o que você compra

Backup e disaster recovery não são um seguro que se contrata e se esquece. São uma capacidade que se constrói com decisões conscientes (qual RTO e RPO cada sistema merece), com cópias que resistem a ataque (imutáveis e offsite) e, acima de tudo, com a disciplina de testar a volta antes que o desastre force o teste por você. A empresa resiliente não é a que nunca sofre incidentes, é a que volta rápido e com o mínimo de perda, porque já ensaiou o pior dia muitas vezes.

Na ConstructorTI, ajudamos organizações a transformar backup em resiliência real: definição de RTO e RPO por sistema, desenho de estratégia de backup imutável, arquitetura de DR na nuvem no nível certo de custo, e construção e simulação do plano de recuperação com testes de restauração. Se você não tem certeza absoluta de que conseguiria voltar rápido depois de um ransomware ou de uma queda de região, converse com o nosso time de CyberSecurity antes que o próximo incidente responda por você.