Teste de restauração de backup: o ensaio que ninguém faz até precisar

Todo painel de infraestrutura tem aquele indicador verde de backup concluído. Ele responde a uma pergunta menor do que parece: diz que um arquivo foi gerado e enviado para algum lugar. Não diz se aquele arquivo abre, se contém tudo, se a chave que o decifra ainda existe, nem quanto tempo o time levaria para colocar o sistema de pé com ele. Enquanto ninguém tenta, o backup é uma hipótese bem formatada.

A diferença entre ter cópia e conseguir voltar só aparece no dia em que voltar é obrigatório, e esse é o pior dia possível para descobrir que o dump não tem a extensão de banco que a aplicação exige. Quem opera verificação de identidade tem um agravante: o material guardado inclui dado pessoal, e o próprio ensaio de restauração cria uma cópia nova que precisa do mesmo cuidado do original.

Este texto trata do ensaio: as duas perguntas que desenham o backup antes da ferramenta, o que a norma pede, como testar sem destruir o que está no ar, o que fazer com dado pessoal no ambiente de teste e que registro sobrevive a uma auditoria.

RPO e RTO: as duas perguntas que definem o desenho

Antes de escolher ferramenta, frequência ou destino, existem duas perguntas de negócio, e elas aparecem no NIST SP 800-34 Revision 1, o guia de planejamento de contingência do instituto de padrões dos Estados Unidos.

A primeira é o RPO, o ponto de recuperação: quanto dado a operação aceita perder. Um backup diário às três da manhã significa aceitar perder até vinte e quatro horas de cadastros, decisões e trilhas de auditoria. Para muitos negócios isso é aceitável; para um sistema que registra decisões com efeito jurídico, perder um dia de trilha é problema regulatório, não apenas operacional.

A segunda é o RTO, o tempo de recuperação: em quanto tempo o serviço precisa estar de pé de novo. É a pergunta que muda a arquitetura, porque restaurar de um armazenamento frio pode levar horas só de transferência, antes de qualquer índice ser reconstruído. Se o RTO combinado é de duas horas e a restauração leva seis, o desenho está errado, e nenhuma disciplina de execução no dia do incidente corrige isso.

As duas respostas são decisão de negócio, não de infraestrutura, e determinam frequência, tipo de cópia e onde o backup vive.

A norma não pede backup, pede restauração testada

O Anexo A da ISO/IEC 27001:2022 traz um controle específico de cópias de segurança, o A.8.13, e o ponto que costuma escapar de quem lê rápido é que ele não se contenta com a existência da cópia: o próprio enunciado do controle fala em cópias testadas com regularidade, exatamente porque cópia que não restaura não protege nada.

Isso muda o que o auditor pergunta. Não é "vocês fazem backup?", pergunta que qualquer painel verde responde. É "quando foi a última restauração de teste, quem executou e quanto tempo levou?". Sem resposta, o controle é considerado não implementado, ainda que o backup rode todas as noites há três anos. Vale aqui a disciplina de qualquer outro controle: se não há registro, não aconteceu.

O ensaio acontece em ambiente isolado

O erro que arruína a operação inteira é testar restaurando por cima do que está no ar: a restauração aponta para o banco de produção, sobrescreve os dados atuais com os de ontem e transforma um exercício em incidente real.

O ensaio precisa de um ambiente separado, com credenciais próprias, criado para a ocasião e destruído no fim. O procedimento mínimo tem cinco passos:

1. Provisionar infraestrutura limpa, sem nenhuma rota de rede para a produção.
2. Restaurar a cópia mais recente, cronometrando desde o início da transferência.
3. Subir a aplicação apontando exclusivamente para o ambiente restaurado.
4. Validar por consulta funcional, e não por contagem de linhas: um usuário conhecido consegue autenticar, uma verificação antiga aparece com o histórico completo, um relatório fecha o mesmo total.
5. Destruir o ambiente e registrar o que foi feito.

O passo quatro é o que separa o ensaio do teatro. Contar linhas prova que o arquivo tinha conteúdo; abrir a aplicação prova que aquele conteúdo é utilizável. E se o seu sistema serve várias empresas na mesma base, o ensaio também precisa provar que o isolamento entre clientes sobreviveu à restauração, porque políticas de acesso e papéis de banco costumam ser justamente o que se perde num dump lógico.

As falhas que só aparecem no ensaio

Os modos de falha abaixo passam despercebidos por anos e aparecem na primeira restauração de verdade.

• Backup lógico sem a extensão do banco. O dump traz as tabelas, mas o ambiente novo não tem a extensão que a aplicação usa, e a restauração morre no meio. Anotar as dependências de servidor junto com a cópia resolve.
• Chave de criptografia guardada só onde o incidente aconteceu. Backup cifrado com chave que vivia no mesmo cofre que caiu é um arquivo aleatório muito bem protegido.
• Dependência de um serviço externo que também estava fora. Se a restauração exige um provedor de identidade, um serviço de nomes ou um segredo que só o ambiente derrubado servia, o plano tem um nó que ninguém desenhou.
• Papéis ausentes. O dump lógico de um banco carrega as políticas de acesso por linha e o dono de cada objeto, mas não carrega os PAPÉIS do agrupamento, que vivem fora do banco e saem por um despejo próprio. O efeito é traiçoeiro: a política volta, o dono volta, e os dois apontam para um papel que não existe no destino. O dado está lá e o controle de acesso não funciona.
• Tempo real muito maior que o estimado. Descompactar, restaurar e reconstruir índices custa mais que transferir. Sem cronômetro, o RTO é chute.

Nenhum desses problemas aparece no painel verde.

Dado pessoal no ambiente de teste é dado pessoal

Ao restaurar a base num ambiente novo, você criou mais um lugar onde o dado pessoal dos seus usuários existe. A Lei 13.709/2018, a LGPD, não abre exceção para ambiente de teste: as obrigações de segurança, de finalidade e de prazo acompanham o dado onde quer que ele esteja, e o registro das operações de tratamento exigido pelo artigo 37 deveria mencionar essa cópia.

Na prática, isso significa três compromissos. O ambiente de ensaio nasce com controle de acesso equivalente ao de produção, e não com a senha padrão de laboratório. Ele tem prazo de vida curto e declarado, com destruição verificada e não apenas prometida. E o acesso a ele fica registrado, porque uma consulta a dados de clientes reais feita "só para conferir a restauração" é acesso a dado pessoal como qualquer outro, sujeito à mesma trilha de auditoria.

Para bases com dado biométrico o cuidado sobe de patamar, e manter ou não esse tipo de dado no ensaio merece discussão explícita com o encarregado, pelo que está em jogo num incidente com dado biométrico. Restaurar só o subconjunto necessário é alternativa legítima, desde que o teste continue exercitando o caminho real.

A ata é o artefato que sobra

Terminado o teste, o que sobrevive não é a memória de quem participou, é o registro. Uma ata curta basta, desde que traga data e hora de início e fim, quem executou, qual cópia foi usada e de que data, o que foi restaurado, quanto tempo cada etapa levou, quais validações funcionais passaram, o que falhou e qual correção foi aberta.

Esse documento tem três leitores previsíveis: o auditor que quer evidência do controle, o time que vai restaurar de verdade um dia, e você mesmo daqui a seis meses. Um ensaio que revelou falhas e gerou correções é resultado melhor do que um ensaio impecável, porque prova que o exercício foi feito com o sistema real.

A frequência é decisão de risco, calibrada pelo mesmo raciocínio do RPO e do RTO. Sistemas que sustentam obrigação regulatória costumam ensaiar em intervalos curtos e fixos; sistemas periféricos toleram intervalos maiores. O que não existe é a opção de nunca, e há dois eventos que forçam um ensaio fora do calendário: mudança grande de esquema e troca da ferramenta de backup. O procedimento antigo, nesses casos, deixou de descrever o sistema atual.

Fontes citadas

• ISO/IEC 27001:2022, Anexo A, controle A.8.13 (Information backup), citada por nome e número no texto.
• NIST SP 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems, citado por nome no texto.
• Lei 13.709/2018 (LGPD), artigo 37, registro das operações de tratamento, e o tratamento de dado pessoal também em ambiente de teste, citada por nome e número no texto.