Backup sem teste de restauração não é plano de continuidade

Quase toda empresa diz ter backup. Bem menos empresas sabem quanto tempo levariam para voltar a operar se o servidor principal parasse hoje, ou se a cópia mais recente realmente abre. A diferença entre essas duas situações é o teste de restauração, e é nela que um backup deixa de ser uma esperança e passa a ser parte de um plano de continuidade.

O backup que só existe no relatório

O cenário mais comum é conhecido: uma rotina de backup configurada há tempos, um painel com status "sucesso" todos os dias e nenhuma restauração feita desde a implantação. O status verde indica apenas que o processo de cópia terminou sem erro. Ele não diz se os arquivos estão íntegros, se o banco de dados estava consistente no momento da cópia, se as credenciais para acessar o repositório ainda existem ou se alguém sabe executar a recuperação.

Falhas típicas que só aparecem na hora da restauração:

• Banco de dados copiado como arquivo enquanto estava em uso, gerando uma cópia inconsistente.
• Diretórios novos que nunca entraram na política de backup.
• Chave de criptografia do backup guardada apenas no servidor que foi perdido.
• Retenção curta demais: quando o problema é descoberto, as cópias boas já foram sobrescritas.
• Repositório de backup acessível com as mesmas credenciais da produção, e por isso cifrado junto num ataque de ransomware.
• Restauração que funciona, mas leva muito mais tempo do que o negócio tolera.

Comece pelo que o negócio tolera: RPO e RTO

Antes de discutir ferramenta, defina dois números para cada sistema relevante.

O RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo. Se o RPO do ERP é de quatro horas, as cópias precisam acontecer pelo menos nesse intervalo.

O RTO (Recovery Time Objective) é o tempo máximo aceitável até o sistema voltar a funcionar. Um RTO de duas horas exige que a restauração, incluindo a validação, caiba nesse prazo.

Esses valores são decisões de negócio, não técnicas. A área técnica informa o custo de atingir cada nível; a direção decide quanto risco aceita. Sem esse acordo, a política de backup vira um palpite.

Os valores da tabela são pontos de partida para a conversa, não recomendações universais.

Princípios de uma política de backup que resiste

Cópias em locais e mídias diferentes

A regra 3-2-1 continua útil como referência: pelo menos três cópias dos dados, em dois tipos de armazenamento diferentes, com uma delas fora do local principal. Variações modernas acrescentam uma cópia imutável ou desconectada e a exigência de zero erros na verificação.

Imutabilidade e separação de credenciais

Ransomware costuma procurar e destruir backups antes de cifrar a produção. Repositórios com retenção imutável, armazenamento de objetos com bloqueio de exclusão e credenciais exclusivas para o sistema de backup reduzem esse risco. O servidor de produção não deve conseguir apagar as próprias cópias.

Consistência de aplicação

Bancos de dados devem ser copiados com as ferramentas próprias ou com mecanismos que garantam consistência, como dumps, backups físicos com arquivamento de logs de transação ou snapshots coordenados com a aplicação. Copiar os arquivos de um banco em execução raramente produz uma cópia confiável.

Virtualização ajuda, mas não substitui

Em ambientes Proxmox ou VMware, o backup de máquinas virtuais inteiras simplifica bastante a restauração. Ainda assim, snapshot não é backup: ele vive no mesmo armazenamento da máquina e desaparece junto com ele. Backups de VM precisam ir para outro destino, com retenção e verificação próprias.

Como testar restaurações na prática

Teste de restauração não precisa ser um evento grande. O importante é que seja periódico, documentado e que meça o tempo real.

Níveis de teste

1. Verificação automática de integridade: checar se os arquivos do backup estão íntegros e legíveis. Útil, mas insuficiente.
2. Restauração de arquivos isolados: recuperar alguns arquivos ou uma pasta e comparar com a origem.
3. Restauração de sistema em ambiente isolado: subir a máquina ou o banco em rede separada e validar que a aplicação funciona.
4. Exercício de recuperação de desastre: simular a perda do ambiente principal e executar o procedimento completo, medindo o RTO alcançado.

Exemplo de verificação de banco restaurado

Um teste simples para um banco PostgreSQL pode restaurar o dump mais recente em uma instância descartável e conferir se os dados esperados estão lá:

#!/usr/bin/env bash
set -euo pipefail

DUMP="/backups/erp/latest.dump"
DB="restore_test_$(date +%Y%m%d)"

createdb "$DB"
trap 'dropdb --if-exists "$DB"' EXIT

start=$(date +%s)
pg_restore --no-owner --exit-on-error -d "$DB" "$DUMP"
elapsed=$(( $(date +%s) - start ))

rows=$(psql -d "$DB" -tAc "SELECT count(*) FROM pedidos WHERE criado_em > now() - interval '2 days'")
echo "Restauração concluída em ${elapsed}s; pedidos recentes: ${rows}"
[ "$rows" -gt 0 ] || { echo "Nenhum pedido recente encontrado" >&2; exit 1; }

O script falha se a restauração der erro ou se não houver dados recentes, o que indica um backup desatualizado. O tempo medido alimenta a comparação com o RTO. Em produção, esse tipo de rotina deve rodar em servidor isolado, nunca contra o banco principal.

O que registrar em cada teste

• Data, responsável e sistema testado.
• Origem do backup usado e idade da cópia restaurada (RPO efetivo).
• Tempo total até o sistema estar utilizável (RTO efetivo).
• Problemas encontrados e ações corretivas, com prazo.
• Confirmação de que o ambiente de teste foi descartado.

Documentação e pessoas fazem parte do plano

Um procedimento que só uma pessoa sabe executar é um ponto único de falha. O plano de continuidade precisa de um roteiro de recuperação escrito, acessível fora da infraestrutura que pode falhar, com a ordem de restauração dos sistemas, dependências entre eles (rede, DNS, autenticação, banco, aplicação), contatos e onde estão as credenciais de emergência.

A ordem importa. Restaurar a aplicação antes do serviço de diretório ou do banco de dados costuma gerar horas de retrabalho. Mapear essas dependências com antecedência é uma das partes mais valiosas do exercício.

Uma rotina possível

Uma empresa sem histórico de testes pode começar de forma modesta e evoluir:

• Mensalmente, restaurar arquivos aleatórios e um banco em ambiente isolado.
• Trimestralmente, restaurar uma máquina virtual crítica completa e validar a aplicação.
• Anualmente, ou após mudanças grandes, executar um exercício de recuperação com a equipe e revisar RPO e RTO com a direção.
• Sempre que um sistema novo entrar em produção, incluí-lo na política e no próximo teste.

O ritmo ideal depende do risco de cada ambiente. O que não pode acontecer é o primeiro teste ser durante um incidente real.

Como a Trihelix pode ajudar

A Trihelix projeta e opera ambientes de servidores e nuvem com foco em continuidade, incluindo políticas de backup, cópias externas e imutáveis e rotinas de teste de restauração. Trabalhamos junto com a gestão para definir RPO e RTO realistas e documentar o roteiro de recuperação. O objetivo é que a empresa saiba, com base em testes registrados, quanto tempo leva para voltar a operar. Veja mais sobre servidores, cloud e continuidade ou fale com a Trihelix.