Annex 11 cláusula 7.1: backup validado e teste de restauração

O ponto mais negligenciado e o mais cobrado em inspeção europeia. Backup que não foi restaurado não é backup — é esperança.

Se eu pudesse apontar uma única cláusula do EU GMP Annex 11 que mais aparece em observação de inspeção europeia, seria a §7.1. É curta, é clara, e é violada em quase toda farmacêutica brasileira que recebe sua primeira inspeção EMA ou PIC/S. O texto, em tradução prática, diz: backups regulares de dados devem ser feitos. A integridade e exatidão dos dados de backup e a capacidade de restauração dos dados devem ser verificadas durante a validação e monitoradas periodicamente.

A leitura ingênua é: "tenho backup automático rodando todo dia, está OK". A leitura do auditor é: "você nunca testou restauração, então não sabe se seu backup é válido". E o auditor está certo.

Por que backup não testado não conta

Backup é probabilidade. Você está apostando que, no dia que o sistema cair (servidor crashar, banco corromper, ransomware encriptar tudo, alguém deletar acidentalmente), o arquivo salvo no destino vai ser recuperável, íntegro, completo e atual. Cada um desses 4 atributos pode falhar de forma silenciosa por meses.

• Recuperável: o arquivo .bak existe, mas precisa de uma versão específica do software que ninguém tem mais. Ou a senha de criptografia se perdeu.
• Íntegro: o arquivo está corrompido. Foi gerado quando o disco já tinha bad sectors, e ninguém notou.
• Completo: falta uma tabela ou um arquivo essencial. O job de backup excluiu algo por configuração equivocada.
• Atual: o backup é de 3 meses atrás, porque o agente parou silenciosamente e ninguém viu o alerta.

Cada um desses só é descoberto quando você tenta restaurar. Se você não testou nunca, está descobrindo no pior dia possível.

O que o Annex 11 §7.1 exige na prática

1. Backup regular: com frequência definida proporcional à criticidade. Pra eQMS GxP, diário é o padrão.
2. Verificação da integridade: mecanismo que confirma que o backup gerado é válido — checksum, hash, ou rotina similar.
3. Verificação durante a validação inicial: teste de restauração executado e documentado como parte do IQ/OQ.
4. Monitoramento periódico: teste de restauração repetido em ciclo definido (trimestral é praxe). Cada teste documentado com data, executor, resultado.

Como executar um teste de restauração que conta

Não é "abrir o arquivo .bak" — isso não prova nada. O teste de restauração válido é:

1. Provisionar ambiente isolado (servidor de teste, idealmente diferente da produção).
2. Restaurar o backup mais recente nesse ambiente, do zero.
3. Validar que o sistema sobe corretamente, que dados-amostra são acessíveis, que a integridade está preservada (hashes batem).
4. Documentar: data, responsável, ambiente, backup usado (data/hora), resultado, evidências (screenshots/logs).
5. Se falhar, abrir desvio e CAPA — porque é falha estrutural, não evento isolado.

Os 3 erros mais comuns em campo

1. "Testamos quando implantamos"

Teste único na implantação não cumpre §7.1. O texto exige monitoramento periódico. Sem rotina, não tem cobertura.

2. "Verificamos com checksum, é suficiente"

Checksum prova que o arquivo não corrompeu durante a transferência. Não prova que o conteúdo é restaurável, completo ou atual. Tem que abrir o arquivo num ambiente e ver o sistema funcionar.

3. "Tem alerta automático se o backup falha"

Alerta cobre falha óbvia. Não cobre falha silenciosa: backup que rodou, mas com configuração errada que excluiu meia base. Pra cobrir isso, teste de restauração real periódico.