Quase toda empresa tem backup. Quase nenhuma tem ensaio de recuperação com data marcada. A diferença entre as duas coisas só aparece no dia em que alguém precisa do arquivo de volta — e aí não é mais um exercício.

O motivo do adiamento não é preguiça. É que o backup dá um sinal de sucesso todos os dias, e o restore não pede nada. O job termina, o painel fica verde, o relatório chega por e-mail. O sistema inteiro foi construído para informar que a escrita deu certo. Ninguém construiu nada que informe que a leitura vai dar.

O que o "backup concluído" realmente prova

Prova que os bytes saíram da origem e chegaram ao destino. Só isso.

Não prova que o índice que mapeia arquivo para objeto está consistente. Não prova que a chave de criptografia guardada no cofre é a chave certa. Não prova que a conta que fará a recuperação tem permissão de leitura no bucket. Não prova que alguém sabe a ordem de subida dos serviços. E não prova o item que mais dói: quanto tempo leva.

Cada um desses é um modo de falha independente. Backup verde e restore impossível convivem sem contradição.

As quatro coisas que se testa

Integridade. O arquivo que volta é idêntico ao que subiu? A verificação honesta é comparar checksum do original com checksum do restaurado, não abrir o arquivo e ver que parece certo. Para banco de dados, integridade significa restaurar o dump e rodar a verificação de consistência do próprio SGBD. Um dump que baixa inteiro e não importa é um arquivo íntegro e inútil.

Tempo. Cronometrado com relógio, do pedido até o dado utilizável. Esse número é o seu RTO real. O RTO que está no documento é uma intenção. A distância entre os dois costuma ser grande, e é maior quando o armazenamento é de classe de arquivamento (Glacier Flexible Retrieval, Deep Archive, Azure Archive): nessas classes existe uma etapa de reidratação antes do download, com prazo próprio, que varia conforme o nível escolhido. Classes de acesso infrequente e o Glacier Instant Retrieval não passam por reidratação — o objeto sai em acesso direto. A documentação da AWS sobre restauração de objetos arquivados e a visão geral de reidratação do Azure Blob descrevem os níveis disponíveis em cada plataforma. Se o seu backup está em classe de arquivamento, esse tempo não é detalhe: é a maior parcela do relógio. Escrevemos sobre esse comportamento em Deep Archive na prática.

Permissões. O teste tem que rodar com a identidade que vai existir no dia ruim. É tentador recuperar com a credencial de administrador que está na sua máquina — e é justamente ela que pode não existir no incidente, porque o incidente pode ser a perda da máquina, a rotação forçada de credenciais ou o comprometimento da conta. Teste com a conta de recuperação, a partir de um host que não seja o servidor de backup.

Ordem de dependência. Sistema não volta arquivo por arquivo. Volta em camadas: rede, segredo, banco, fila, aplicação, DNS. Restaurar a aplicação antes do banco produz uma aplicação que sobe, responde healthcheck e serve erro. A ordem precisa estar escrita, e o ensaio é o que revela o item esquecido — quase sempre um segredo, um certificado ou uma variável de ambiente que nunca entrou no escopo do backup.

Um exercício que cabe numa manhã

Não tente ensaiar o desastre completo na primeira vez. Ensaio grande demais é ensaio que nunca acontece. Comece com um escopo pequeno e fechado.

Escolha o alvo na véspera. Um diretório real, um banco pequeno, um volume de máquina virtual. Algo que importe, mas cuja indisponibilidade não pare ninguém.
Escreva a hipótese antes. "Espero recuperar 8 GB em menos de duas horas, usando a conta restore-ops, sem precisar de ninguém do time de infraestrutura." Hipótese escrita transforma o ensaio em medição. Sem ela, o resultado é sempre "deu certo".
Restaure em destino isolado. Bucket separado, host separado, banco separado. Nunca por cima da produção. Restore de ensaio que sobrescreve dado bom é um incidente criado pelo próprio exercício.
Cronometre em três marcos. Pedido feito; dado disponível para download; dado utilizável pela aplicação. Os três números contam histórias diferentes, e o terceiro é o único que o negócio entende.
Verifique com checksum. sha256sum na origem e no destino, comparação automática. Amostragem serve para volumes grandes, desde que a amostra seja aleatória e não os primeiros arquivos da lista.
Anote o que faltou. Todo primeiro ensaio descobre algo ausente. É o produto principal do exercício, não um fracasso dele.
Feche com o registro. Data, escopo, tempos, quem executou, o que quebrou, o que mudou no runbook. Uma página. Sem isso o próximo ensaio recomeça do zero.

Ensaiar custa dinheiro, e o custo tem forma conhecida

Esta é a objeção real, e ela merece resposta honesta. Recuperar não é gratuito. A cobrança costuma ter quatro componentes, e todos os grandes provedores usam alguma combinação deles:

Requisições. Cobradas por operação. Recuperar um milhão de arquivos pequenos gera um milhão de operações, e essa conta às vezes supera a do armazenamento do mês.
Saída de dados. Trafegar para fora da nuvem costuma ter preço por gigabyte na maioria dos provedores. Restaurar para um host dentro da mesma região costuma ser bem mais barato que restaurar para o escritório.
Recuperação de dados arquivados. Em arquivamento, além do armazenamento você paga pelo volume recuperado, com preço diferente por nível de urgência.
Mínimo de retenção e multa por exclusão antecipada. Classes frias cobram um período mínimo. Apagar a cópia de ensaio antes desse prazo pode gerar cobrança pelo restante.

Não coloco valores aqui porque eles mudam e variam por região. Abra a tabela de preços atual do seu provedor, para a sua região e a sua classe, e monte a conta do ensaio antes de rodá-lo. Duas decisões reduzem esse custo sem falsear o teste: restaurar uma amostra em vez do conjunto inteiro, e restaurar para dentro da mesma região. A amostra mede integridade e permissões de forma suficiente para o ensaio. Só não mede tempo total — para isso, uma vez por ano, vale pagar o ensaio grande.

Cadência que funciona

Mensal, pequeno e automatizado: um alvo rotativo, restaurado por script, com checksum comparado e resultado registrado. Trimestral, médio: um serviço inteiro, com a ordem de dependência exercitada e pessoas de plantão diferentes conduzindo. Anual, grande: o cenário de perda total, com tempo medido de ponta a ponta.

O critério de rodízio é simples: ensaie primeiro o que você tem mais medo de perder e menos costume de tocar.

O que este artigo não prova

Não trago aqui nenhuma medição, e isso é proposital: o seu relógio depende do volume, da classe de armazenamento, da região e do disco de destino. Número de teste alheio não vira promessa para o seu caso — meça o seu.

Há situações em que o conselho acima é ruim. Se o seu backup está em classe fria com mínimo de retenção longo e o orçamento é apertado, ensaio mensal do conjunto inteiro é desperdício: use amostra e reserve o teste completo para uma vez por ano. Se a base tem dado pessoal sensível, restaurar em ambiente de teste pode violar a sua própria política — nesse caso o ensaio exige anonimização ou um ambiente com o mesmo controle da produção, e isso muda o esforço. E se a sua operação é de um servidor só, com uma pessoa, o ritual de três cadências é burocracia: um ensaio semestral bem registrado já resolve.

Este texto também não cobre recuperação de sistemas distribuídos com estado replicado, onde a ordem de dependência é bem mais complexa do que a lista acima sugere. E não trata de quem detém a chave, que é um problema separado e tão grave quanto — está em quem consegue abrir o seu backup.

O que sobra é a parte que vale para todo mundo: restore não testado é hipótese. A hipótese custa uma manhã para virar fato.

O NubliVault é o produto de backup da Nublify: empacota milhões de arquivos pequenos e os guarda numa nuvem diferente da de origem. Como funciona · Segurança