Backup e Disaster Recovery: RTO, RPO e o Backup Que Você Nunca Testou

Existe uma verdade desconfortável sobre backups: quase todo mundo faz, e quase ninguém testa. O resultado é que o momento em que você descobre se o backup presta é exatamente o pior momento possível — durante o desastre, com o sistema fora, o chefe no telefone e a percepção súbita de que o dump das últimas três semanas está corrompido. Backup que nunca foi restaurado não é backup; é uma aposta que você faz sem conhecer as chances.

Backup e disaster recovery (DR) são a disciplina de garantir que, quando o pior acontecer — falha de hardware, erro humano, ataque, exclusão acidental, catástrofe no data center — você consegue recuperar os dados e o serviço em um tempo aceitável, com uma perda de dados aceitável. As duas palavras-chave são "aceitável", e é sobre defini-las que começa qualquer estratégia séria.

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

Antes de escolher ferramenta, tecnologia ou frequência, você precisa responder a duas perguntas de negócio. Elas se traduzem em dois números que orientam todas as decisões técnicas.

RTO — Recovery Time Objective#

Quanto tempo o serviço pode ficar fora antes que o impacto se torne inaceitável? É o tempo máximo de recuperação. Um RTO de quatro horas significa: do momento do desastre até o serviço voltar, no máximo quatro horas. Um RTO de cinco minutos é uma exigência muito mais cara, que muda toda a arquitetura.

RPO — Recovery Point Objective#

Quanto de dado você pode perder, medido em tempo? É a janela de perda aceitável. Um RPO de uma hora significa: você aceita perder, no máximo, a última hora de dados. Se seu backup roda uma vez por dia, seu RPO é de até 24 horas — você pode perder um dia inteiro de transações. Se isso é inaceitável, você precisa de backups mais frequentes ou replicação contínua.

``text desastre | ....dados.........X.........serviço fora.........serviço volta <--- RPO ---> <---- RTO ----> (perda máxima (tempo máximo até de dados) recuperar) ``

O ponto crucial: RTO e RPO menores custam exponencialmente mais. Um RPO de 24 horas se resolve com um dump diário barato. Um RPO de segundos exige replicação síncrona, infraestrutura redundante e complexidade considerável. Definir esses números com o negócio — e não a partir do que a tecnologia entrega por acaso — é o que impede tanto o sub-investimento (descobrir tarde que a perda é grande demais) quanto o super-investimento (pagar por um RPO de segundos onde 6 horas bastavam).

A regra 3-2-1: o mínimo civilizatório#

A regra mais conhecida de backup, e ainda válida décadas depois, é a 3-2-1:

• 3 cópias dos dados (a original mais dois backups).
• 2 mídias ou tipos de armazenamento diferentes.
• 1 cópia fora do local (off-site).

A lógica é sobre correlação de falhas. Se suas três cópias estão no mesmo disco, um disco morto leva tudo. No mesmo data center, um incêndio ou uma enchente leva tudo. A cópia off-site existe porque desastres físicos são reais. Extensões modernas acrescentam o 1 de "uma cópia imutável ou offline" — porque ransomware que criptografa seus dados também tenta criptografar os backups conectados. Um backup que o atacante consegue apagar não protege contra o cenário mais comum de hoje.

Tipos de backup: full, incremental e diferencial#

Não existe um só jeito de fazer backup, e a escolha impacta diretamente o custo de armazenamento e a velocidade de restauração.

• Full: uma cópia completa de tudo. Simples de restaurar (é só uma), mas caro

em espaço e lento de gerar se feito toda vez.

• Incremental: copia só o que mudou desde o último backup (full ou

incremental). Econômico e rápido de gerar, mas a restauração precisa do full mais toda a cadeia de incrementais na ordem — e se um elo da cadeia corrompe, você perde tudo dali para frente.

• Diferencial: copia tudo que mudou desde o último full. Fica entre os

dois: cada diferencial cresce com o tempo, mas a restauração precisa só do full mais o último diferencial.

```text Full (domingo) + incrementais diários: restaurar quinta = full + inc-seg + inc-ter + inc-qua + inc-qui (5 peças)

Full (domingo) + diferenciais diários: restaurar quinta = full + dif-qui (2 peças) ```

A estratégia comum combina: um full periódico (semanal) com incrementais ou diferenciais entre eles, equilibrando espaço e tempo de restauração. Para bancos de dados, há ainda o backup contínuo via log de transações (WAL, binlog), que permite recuperação a um ponto no tempo (PITR) — restaurar o banco ao estado exato de "hoje às 14h32", segundos antes de alguém rodar o DELETE fatídico.

Backup não é disaster recovery#

Uma confusão comum: backup e DR não são sinônimos. Backup é a cópia dos dados. Disaster recovery é o plano completo para voltar a operar — que inclui os backups, mas também a infraestrutura, a rede, a configuração, os segredos, o DNS e o procedimento de quem faz o quê.

Ter o dump do banco não adianta se você não tem para onde restaurá-lo, como reconstruir os serviços, como reapontar o tráfego. É por isso que infraestrutura como código é uma aliada tão poderosa de DR: se toda a infraestrutura está descrita em código versionado, recriá-la em outra região é executar o código, não reconstruir tudo na mão de memória. O dado vem do backup; o ambiente vem do IaC.

As estratégias de DR se organizam por custo e velocidade, espelhando o trade-off do RTO:

• Backup e restore: a mais barata e lenta. Guarda backups e, no desastre,

provisiona tudo do zero e restaura. RTO de horas.

• Pilot light: mantém o núcleo mínimo rodando na região secundária (o banco

replicando, por exemplo) e liga o resto sob demanda. RTO de dezenas de minutos.

• Warm standby: uma versão reduzida do ambiente inteiro já rodando, que se

escala no desastre. RTO de minutos.

• Multi-site ativo/ativo: tráfego em duas regiões ao mesmo tempo; uma cai e a

outra absorve. RTO próximo de zero, mas o mais caro e complexo.

Você escolhe pela combinação de RTO/RPO exigidos e o quanto pode gastar. Nem tudo precisa de ativo/ativo — muitas cargas vivem bem com backup e restore, e gastar em multi-site para elas é desperdício.

A parte que todo mundo pula: testar a restauração#

Chegamos ao ponto central deste guia. Um backup não testado não existe. Você não tem um backup até ter restaurado com sucesso a partir dele. Tudo antes disso é fé.

As formas pelas quais backups falham silenciosamente são muitas e cruéis:

• O job de backup falhava havia semanas, mas ninguém monitorava o resultado — só

o "iniciou", não o "terminou com sucesso".

• O backup rodava, mas estava corrompido, e ninguém verificou a integridade.
• O backup capturava o banco, mas esquecia um volume, um bucket, um segredo — e na

hora da restauração faltava uma peça essencial.

• A restauração funcionava, mas levava doze horas, quando o RTO prometido era de

duas. O backup existia; o plano não cumpria o RTO.

• A documentação de restauração estava desatualizada e apontava para um comando ou

um caminho que não existiam mais.

A única defesa contra tudo isso é o teste de restauração periódico e real: regularmente, restaure o backup em um ambiente isolado, valide que os dados estão íntegros e completos, e cronometre quanto tempo levou. Esse exercício responde às três perguntas que importam: o backup restaura? os dados estão certos? cabe no RTO? Um simulado de DR — derrubar (em ambiente controlado) e recuperar de verdade — é o teste definitivo, e revela lacunas que nenhuma revisão de documento pega.

Monitoramento e retenção#

Duas peças finais que os backups esquecidos ignoram.

Monitore o resultado, não a intenção. Um backup agendado que ninguém observa é um backup que vai falhar em silêncio. Você precisa de alerta quando um job de backup falha, quando a idade do último backup bem-sucedido ultrapassa o esperado, e quando o tamanho do backup foge do padrão (um dump que de repente ficou minúsculo é sinal de que copiou vazio). O sucesso do backup é uma métrica de primeira classe, com alerta próprio.

Defina a retenção conscientemente. Quanto tempo guardar cada backup? Retenção demais custa armazenamento; de menos, e você não consegue voltar a um ponto antigo quando descobre uma corrupção que começou semanas atrás. Um esquema comum é o avô-pai-filho: diários mantidos por uma ou duas semanas, semanais por alguns meses, mensais por um ou mais anos. E cuidado com a automação de expiração: já houve caso de rotina de limpeza que nunca rodava (backups crescendo sem fim) e de rotina que apagava demais. A retenção também precisa ser monitorada.

Backup consistente: o detalhe que corrompe silenciosamente#

Um erro técnico específico merece destaque porque produz backups que parecem bons e não são: o backup inconsistente. Se você copia os arquivos de um banco de dados enquanto ele está escrevendo, sem coordenação, pode capturar um estado intermediário — metade de uma transação, um índice fora de sincronia com os dados. O backup termina "com sucesso", ocupa o tamanho esperado, e só revela a corrupção na hora da restauração, quando o banco se recusa a subir.

A defesa é usar mecanismos de backup cientes da aplicação: as ferramentas nativas do banco (que garantem um snapshot consistente), snapshots de volume coordenados com uma pausa de escrita, ou o backup contínuo via log de transações, que por natureza captura um ponto consistente. A regra geral: para dados com estado transacional, nunca confie em "copiar os arquivos" cru. E, de novo, o teste de restauração é o que expõe esse problema antes que ele te pegue de surpresa — um backup inconsistente passa em toda verificação, menos na única que importa, que é subir de verdade.

O resumo que salva o dia ruim#

Backup e DR não são glamorosos. Ninguém ganha promoção por um backup que funcionou — só se lembra deles quando falham. Mas quando o desastre chega, essa disciplina é a diferença entre um dia difícil e o fim do negócio.

Guarde os pilares: defina RTO e RPO com o negócio, antes da tecnologia. Siga a 3-2-1 com uma cópia imutável e off-site. Combine tipos de backup pelo equilíbrio de custo e velocidade. Trate DR como o plano completo, não só o dump — e use IaC para recriar o ambiente. E, acima de tudo, teste a restauração de verdade, periodicamente, cronometrando contra o seu RTO. O backup que você nunca restaurou é o backup em que você não deveria confiar — e o único jeito de saber é tentando, com calma, antes que a vida obrigue você a tentar com pressa.