Backup que nunca foi restaurado: transformar cópia em garantia de recuperação

O que o job de backup prova quando termina com sucesso é bem menos do que o time costuma assumir. Ele prova que um processo leu dados de uma origem e escreveu bytes num destino sem retornar código de erro. Não prova que os bytes escritos são legíveis, que representam um estado consistente do sistema, que o conteúdo cobre tudo o que precisa ser restaurado, que existe alguém com permissão para lê-los de volta, nem que o tempo de leitura cabe no prazo que o negócio aceita. Cada uma dessas cinco afirmações é independente das outras, e o job de backup verifica exatamente zero delas.

A diferença entre a cópia e a garantia é a mesma que existe entre um teste que compila e um teste que passa. A métrica que quase todo painel exibe é a taxa de sucesso do job, e ela é enganosa justamente porque fica em cem por cento durante todo o período em que o backup está silenciosamente inútil. Um dump que perdeu uma tabela porque o usuário de leitura não recebeu permissão na tabela nova termina com sucesso. Um arquivo truncado por disco cheio no destino termina com sucesso se a escrita retorna antes do flush. Um backup criptografado com uma chave que já foi rotacionada termina com sucesso todos os dias, e continua terminando com sucesso até o dia em que alguém precisa abri-lo.

A reformulação que resolve isso é tratar a restauração como o teste e o backup como o código. Ninguém aceitaria um sistema em que a suíte de testes nunca roda e a equipe afirma que o código funciona porque compilou setecentas e vinte vezes seguidas. O backup está exatamente nessa posição na maioria das organizações, e o motivo é que restaurar parece caro enquanto nada quebrou. O custo real é assimétrico da mesma forma que no caso dos testes: o ensaio semanal custa algumas horas de máquina, e a descoberta de que o backup não presta durante um incidente custa o tempo de indisponibilidade multiplicado por todo o negócio que depende do sistema.

O QUE CADA COISA REALMENTE PROVA

  job de backup verde      -> "um processo escreveu bytes em algum lugar"
                              nao prova legibilidade
                              nao prova completude
                              nao prova acesso
                              nao prova prazo

  checksum do arquivo      -> "os bytes nao corromperam depois da escrita"
                              nao prova que o conteudo esta certo

  restauracao em ambiente  -> "estes bytes viram um banco que sobe"
  descartavel                 nao prova que a aplicacao funciona

  restauracao + consulta   -> "este banco responde o que a aplicacao pergunta"
  de verificacao              ESTA e a garantia

  ^ so a ultima linha e uma garantia. as tres primeiras sao indicios.

Uma recuperação depende de quatro propriedades independentes, e vale enumerá-las separadamente porque cada uma falha por um motivo próprio, é detectada por um teste próprio e é responsabilidade de uma pessoa diferente na prática. Legibilidade é a capacidade de ler os bytes de volta e obter o que foi escrito. Completude é a cobertura: se tudo o que precisa existir depois da restauração está dentro do conjunto de cópias. Consistência é a propriedade de que os dados representam um instante válido do sistema, e não um retrato borrado de várias tabelas capturadas em momentos diferentes. Acessibilidade é a capacidade de a pessoa certa chegar aos bytes no momento do incidente, com credencial, permissão e rede.

A coluna mais útil dessa tabela é a última, e ela explica por que a discussão sobre backup tende a ser improdutiva. Quatro das cinco linhas só são descobertas durante o incidente, que é o único momento em que não existe tempo para resolvê-las. O ensaio de restauração não é uma prática de maturidade opcional: é o único mecanismo que move essas descobertas de dentro do incidente para fora dele. Vale notar também que a ordem de falha na prática é quase sempre a inversa da ordem de atenção que os times dão. Quase todo mundo se preocupa com legibilidade, que é a que menos falha, e quase ninguém testa acessibilidade, que é a que mais transforma um incidente de quarenta minutos numa parada de meio dia.

A consistência merece um parágrafo próprio porque é a mais mal compreendida das quatro. Um backup lógico que roda tabela por tabela sem uma transação única captura cada tabela num instante diferente, e o resultado é um estado que nunca existiu: um pedido que referencia um item de pagamento que ainda não havia sido criado quando aquela tabela foi lida. Em Postgres, a opção de dump em transação única resolve isso dentro de um banco, mas não entre bancos: se o sistema guarda pedidos num banco e pagamentos em outro, nenhuma ferramenta de dump garante um instante comum entre os dois, e a consistência passa a depender de um ponto de recuperação coordenado por tempo, com a tolerância explicitamente aceita pelo negócio.

Os dois objetivos que organizam qualquer plano de recuperação são o tempo máximo aceitável até o sistema voltar, e a quantidade máxima aceitável de dados perdidos medida em tempo. O primeiro responde quanto tempo o negócio sobrevive parado, o segundo responde quanto trabalho pode desaparecer. São números de negócio, não de infraestrutura, e o erro mais comum é deixá-los na apresentação sem verificar se a arquitetura atual consegue entregá-los. Um objetivo de quinze minutos de perda máxima com um backup diário é uma contradição declarada: a arquitetura já garante, por construção, até vinte e quatro horas de perda.

O que torna esses números concretos é derivar deles a restrição técnica correspondente, e é aí que a conversa deixa de ser retórica. A quantidade aceitável de perda define a frequência mínima da cópia e, quando é menor que algumas horas, obriga o envio contínuo do log de transações em vez de dumps periódicos. O tempo aceitável até a volta define a forma da restauração, não o tamanho do backup: restaurar dois terabytes de dump lógico não cabe em quatro horas por mais banda que exista, porque o gargalo é a reconstrução de índices, enquanto uma réplica já promovida cabe em minutos porque não há nada a reconstruir.

Uma armadilha específica aparece na última linha e merece ser dita com todas as letras, porque ela já custou dados a muita gente: réplica não é backup. A replicação propaga fielmente qualquer escrita, inclusive a errada, e um comando de exclusão sem cláusula de filtro chega à réplica em milissegundos. A réplica resolve o tempo de retorno diante de falha de hardware e não resolve nada diante de erro humano, defeito de aplicação ou ataque. Os dois mecanismos são complementares e respondem a perguntas diferentes: a réplica protege contra a máquina que morreu, o backup protege contra a escrita que não deveria ter acontecido, e um plano que confunde os dois descobre a diferença no dia em que alguém roda um UPDATE sem WHERE.

O ensaio precisa ser automatizado por um motivo que não é preguiça: um procedimento manual só é executado enquanto alguém se lembra dele, e a memória organizacional dura menos que a rotatividade do time. O ensaio automatizado roda toda semana sem que ninguém decida rodar, e a primeira semana em que ele falha é a semana em que o backup parou de funcionar, e não o dia do incidente. O desenho mínimo tem quatro etapas: provisionar um ambiente descartável, restaurar a cópia mais recente dentro dele, rodar consultas de verificação contra o resultado, e destruir o ambiente registrando o tempo total.

A etapa que diferencia um ensaio útil de um teatro de conformidade é a terceira. Restaurar e verificar apenas que o banco sobe prova pouco, porque um banco vazio também sobe. As consultas de verificação precisam checar completude, comparando a contagem de tabelas e de objetos com a origem, checar integridade referencial, procurando registros órfãos que denunciam captura inconsistente, e checar atualidade, confirmando que o registro mais recente do backup está dentro da janela de perda aceitável. Esse último item é o que detecta o caso mais silencioso de todos, que é o backup que roda com sucesso mas sobre uma réplica que parou de receber dados há três semanas.

#!/usr/bin/env bash
# scripts/ensaio-restauracao.sh
# Ensaio semanal de restauracao. Roda em agendador, sem intervencao humana.
# Falhar aqui e o objetivo: e mais barato do que falhar durante o incidente.

set -euo pipefail

BUCKET="${BACKUP_BUCKET:?bucket de backup nao definido}"
RPO_HORAS="${RPO_HORAS:-24}"
INSTANCIA="ensaio-restauracao-$(date +%Y%m%d%H%M%S)"
INICIO=$(date +%s)

# Ambiente descartavel e sempre destruido, inclusive quando o ensaio falha.
# Sem esta linha, um ensaio que falha deixa lixo caro rodando ate alguem ver.
limpar() {
  docker rm -f "$INSTANCIA" >/dev/null 2>&1 || true
  rm -f "$ARQUIVO" 2>/dev/null || true
}
trap limpar EXIT

# 1. Buscar a copia mais recente pelo armazenamento, e nao por um nome
#    previsivel: nome previsivel esconde o caso em que o job parou de gerar
#    arquivo novo e o ensaio segue restaurando o mesmo backup antigo.
ARQUIVO=$(mktemp /tmp/backup-XXXXXX.dump)
CHAVE=$(aws s3api list-objects-v2 --bucket "$BUCKET" --prefix "postgres/" \
  --query 'sort_by(Contents, &LastModified)[-1].Key' --output text)

if [ "$CHAVE" = "None" ] || [ -z "$CHAVE" ]; then
  echo "FALHA: nenhum backup encontrado em $BUCKET" >&2
  exit 1
fi

# Idade do arquivo: um backup legivel porem velho falha o objetivo de perda
# aceitavel do mesmo jeito que um backup corrompido. Esta checagem pega o
# job que morreu silenciosamente ha semanas com o painel ainda verde.
MODIFICADO=$(aws s3api head-object --bucket "$BUCKET" --key "$CHAVE" \
  --query 'LastModified' --output text)
IDADE_HORAS=$(( ( $(date +%s) - $(date -d "$MODIFICADO" +%s) ) / 3600 ))

if [ "$IDADE_HORAS" -gt "$RPO_HORAS" ]; then
  echo "FALHA: backup mais recente tem ${IDADE_HORAS}h, limite e ${RPO_HORAS}h" >&2
  exit 1
fi

aws s3 cp "s3://$BUCKET/$CHAVE" "$ARQUIVO" --quiet

# 2. Restaurar num banco efemero, isolado do ambiente real.
docker run -d --name "$INSTANCIA" -e POSTGRES_PASSWORD=ensaio \
  -p 55432:5432 postgres:16 >/dev/null

until docker exec "$INSTANCIA" pg_isready -q; do sleep 1; done

# --exit-on-error e essencial: sem ele, pg_restore ignora erros de objeto
# individual e termina com codigo zero, e o ensaio aprova um backup parcial.
PGPASSWORD=ensaio pg_restore --host=localhost --port=55432 --username=postgres \
  --dbname=postgres --no-owner --exit-on-error "$ARQUIVO"

# 3. Verificacao de conteudo. Um banco vazio tambem sobe: o que prova a
#    restauracao sao as consultas abaixo, nao o processo ter iniciado.
PGPASSWORD=ensaio psql --host=localhost --port=55432 --username=postgres \
  --dbname=postgres --variable=ON_ERROR_STOP=1 --quiet <<'SQL'
DO $
DECLARE
  total_tabelas int;
  pedidos_orfaos int;
  registro_mais_novo timestamptz;
BEGIN
  -- Completude: contagem conferida contra o inventario esperado da origem.
  SELECT count(*) INTO total_tabelas
    FROM information_schema.tables WHERE table_schema = 'public';
  IF total_tabelas < 42 THEN
    RAISE EXCEPTION 'Completude: % tabelas restauradas, esperado ao menos 42',
      total_tabelas;
  END IF;

  -- Consistencia: orfao denuncia captura sem transacao unica, em que cada
  -- tabela foi lida num instante diferente.
  SELECT count(*) INTO pedidos_orfaos
    FROM orders o LEFT JOIN customers c ON c.id = o.customer_id
    WHERE c.id IS NULL;
  IF pedidos_orfaos > 0 THEN
    RAISE EXCEPTION 'Consistencia: % pedidos sem cliente', pedidos_orfaos;
  END IF;

  -- Atualidade: pega a origem que parou de receber dados com o job verde.
  SELECT max(created_at) INTO registro_mais_novo FROM orders;
  IF registro_mais_novo < now() - interval '36 hours' THEN
    RAISE EXCEPTION 'Atualidade: registro mais novo e de %', registro_mais_novo;
  END IF;
END $;
SQL

# 4. O tempo do ensaio e a estimativa honesta do tempo de retorno. Publicar
#    como metrica permite alertar quando a restauracao passa a nao caber no
#    prazo, o que acontece de forma gradual conforme a base cresce.
DURACAO=$(( $(date +%s) - INICIO ))
echo "ensaio_restauracao_segundos $DURACAO"
echo "OK: restauracao verificada em ${DURACAO}s a partir de $CHAVE"

Duas escolhas no script merecem destaque porque são exatamente onde os ensaios caseiros costumam falhar em silêncio. A primeira é a opção que faz o restaurador parar no primeiro erro: sem ela, a ferramenta reporta problemas por objeto individual e ainda assim termina com código zero, de forma que um backup em que metade dos objetos não restaurou é aprovado pelo ensaio. A segunda é buscar a cópia mais recente consultando o armazenamento em vez de montar um nome previsível a partir da data, porque o nome previsível esconde justamente o caso em que o job parou de gerar arquivos novos: o ensaio continua restaurando com sucesso o mesmo arquivo de três semanas atrás e continua reportando verde.

A falha mais cara em recuperação raramente está no backup. Está na cadeia de coisas que precisam funcionar para que alguém consiga usá-lo, e essa cadeia costuma passar pelo próprio sistema que caiu. A credencial de acesso ao armazenamento está num gerenciador de segredos que autentica contra o serviço de identidade que usa o banco que está fora do ar. A documentação do procedimento está num wiki hospedado no mesmo cluster. O alerta que avisaria o plantão passa por um serviço que depende da fila que parou. Cada um desses elos é razoável isoladamente e o conjunto forma um ciclo que só se revela quando o ciclo precisa ser percorrido.

O teste que revela esse ciclo é diferente do ensaio automatizado e não pode ser substituído por ele, porque o ensaio roda com as credenciais de serviço já configuradas no agendador, que é justamente o que não existirá durante o incidente. O que revela a dependência circular é o ensaio conduzido por uma pessoa do plantão, partindo apenas do que ela teria em mãos às três da manhã: um notebook, um segundo fator e o documento de procedimento. Toda vez que essa pessoa precisa perguntar algo a alguém, a pergunta é uma dependência não documentada, e o objetivo do exercício é produzir exatamente essa lista.

1. Desenhar a cadeia completa de recuperação, do alerta inicial até a aplicação servindo tráfego, listando cada sistema que precisa estar de pé em cada passo.
2. Marcar na cadeia todo elemento que depende, direta ou indiretamente, do sistema que está sendo recuperado, incluindo identidade, segredos, rede, observabilidade e documentação.
3. Para cada dependência circular encontrada, criar um caminho alternativo que não passe pelo sistema caído, como credencial de emergência guardada fora de linha e procedimento exportado em arquivo estático.
4. Conduzir o ensaio com uma pessoa do plantão que não desenhou o sistema, sem ajuda dos autores, registrando cada pergunta que ela precisa fazer.
5. Transformar cada pergunta registrada em correção do procedimento ou em automação, e repetir o exercício com outra pessoa no trimestre seguinte.
6. Guardar a credencial de emergência com validade limitada e auditoria de uso, para que o caminho alternativo não vire uma porta permanente sem controle.

Há uma variante dessa dependência que é específica de backup e que merece atenção própria: a chave de criptografia. Cifrar as cópias é correto e frequentemente obrigatório, e cria um ponto de falha novo, porque o backup passa a valer exatamente o que a chave vale. Se a chave vive apenas no gerenciador de segredos que depende do ambiente afetado, a cópia está criptografada contra o próprio dono. Se a chave é rotacionada sem manter as anteriores acessíveis, os backups antigos viram ruído no dia da rotação, de forma silenciosa, e o ensaio semanal só detecta isso se restaurar também uma cópia antiga de tempos em tempos, e não apenas a mais recente.

Trocar a taxa de sucesso do job por indicadores que refletem recuperação de verdade é a mudança de instrumentação que sustenta todo o resto. São quatro sinais, e a característica comum entre eles é que nenhum pode ser satisfeito por um processo que apenas escreveu bytes em algum lugar. A idade da cópia verificada mais recente responde qual é a perda real de dados neste instante, e é diferente da idade do último backup, porque uma cópia não verificada não conta. A duração do ensaio de ponta a ponta é a estimativa honesta do tempo de retorno, e ela cresce com a base até o dia em que deixa de caber no prazo, o que precisa ser detectado antes do incidente e não durante.

Os outros dois sinais cobrem o que costuma passar despercebido. A diferença de inventário entre origem e restaurado detecta a tabela nova que ficou de fora por falta de permissão, que é a causa mais comum de restauração incompleta em sistemas que evoluem rápido. O tempo desde o último ensaio conduzido por um humano do plantão detecta a erosão do procedimento, que acontece por rotatividade e por mudança de infraestrutura mesmo quando tudo o mais continua automatizado e verde.

Vale fechar com a inversão que organiza a prioridade de investimento nesse tema. O backup não é o produto, a recuperação é. Todo o esforço gasto em aumentar a frequência de cópias tem retorno decrescente e é fácil de justificar em reunião, enquanto o esforço gasto em provar a recuperação tem retorno alto e é difícil de vender porque não produz nada visível enquanto nada quebra. A pergunta que separa uma organização preparada de uma organização confiante não é com que frequência o backup roda, é qual foi a data da última restauração bem-sucedida conduzida por alguém que estaria de plantão, e quanto tempo ela levou.