Backup não é uma cópia que existe; é uma recuperação que funciona
É comum ouvir que os dados “estão na nuvem” ou que “o sistema faz backup”. Essas frases não respondem às perguntas que realmente importam: qual dado é protegido, com que frequência, onde fica a cópia, quem pode alterá-la, quanto se perde se houver falha e se a restauração já foi testada.
Para uma serventia, backup é parte da continuidade, da integridade do acervo e da capacidade de retomar o atendimento. Uma cópia que não pode ser localizada, descriptografada ou restaurada em tempo útil não reduz o risco de forma suficiente.
O que muda com o Provimento 213
O Anexo IV do Provimento 213 estabelece rotinas automatizadas de backup completo e incremental. Para cópias completas, os intervalos máximos indicados são de 24 horas para Classe 3, 48 horas para Classe 2 e 72 horas para Classe 1, admitindo solução tecnicamente equivalente que assegure o RPO aplicável.
O mesmo anexo exige pelo menos dois ambientes tecnicamente independentes, com redundância geográfica ou lógica equivalente. Também determina que ao menos um ambiente seja protegido contra criptografia maliciosa, exclusão indevida ou comprometimento sistêmico simultâneo. A arquitetura pode ser local, em nuvem ou híbrida, mas não pode criar um ponto único de falha.
Comece pelo inventário de dados e do RPO
Não trate “backup” como um único objeto. Liste bancos, atos e livros eletrônicos, arquivos de trabalho necessários à continuidade, integrações, configurações, trilhas de auditoria e documentação crítica. Depois, defina para cada grupo a perda máxima aceitável, o RPO.
Esse exercício revela incoerências. Uma rotina noturna pode ser suficiente para um arquivo administrativo, mas incompatível com um processo que exige recuperação mais próxima do momento da falha. O RPO não é um número técnico isolado: é uma decisão de risco ligada ao impacto operacional e à capacidade de recompor informações.
Dois ambientes independentes não significam duas pastas no mesmo risco
A independência precisa ser técnica e operacional. Um disco conectado ao mesmo computador pode ser afetado pelo mesmo incidente. Duas cópias na mesma conta, com as mesmas credenciais administrativas, podem sofrer exclusão indevida juntas. Avalie localização, credenciais, retenção, fornecedor, conectividade e capacidade de recuperação.
O Provimento admite arquitetura em nuvem para cumprir múltiplos ambientes quando houver, cumulativamente, redundância geográfica em regiões distintas, retenção imutável com bloqueio contra exclusão administrativa, segregação lógica, registro auditável e viabilidade comprovada de restauração integral. Para Classes 1 e 2, a norma também prevê hipótese de nuvem comercial, desde que haja criptografia forte antes do envio e a chave de descriptografia permaneça sob custódia exclusiva da serventia.
O teste de restauração é a prova mais importante
A rotina deve produzir alertas e registro formal de falhas. Ainda assim, o teste é o que valida a cópia. O Anexo II prevê testes periódicos de restauração; o Anexo IV exige, na etapa de monitoramento e validação, testes documentados conforme a periodicidade da classe.
Planeje testes em camadas: recupere um arquivo ou base não crítica; restaure um conjunto representativo em ambiente seguro; e simule uma recuperação mais ampla em cenário controlado. Em cada caso, registre data, responsável, cópia usada, tempo, resultado, dados recuperados, limitações e ações corretivas. Não use dados reais fora de ambiente protegido nem transforme o teste em risco adicional para a operação.
Evidências que devem ficar organizadas
Uma pasta de evidências pode conter política e procedimento de backup; inventário de dados protegidos; configuração ou relatório do sistema; alertas e falhas; comprovantes de criptografia e retenção; relatórios de restauração; análise de incidentes; e ações de melhoria. Para as Classes 2 e 3, a documentação de conclusão de etapas tem requisitos específicos de integridade; para Classe 1, há forma simplificada, mas contratos, notas fiscais e relatório precisam ser guardados pelo prazo mínimo indicado no Anexo IV.
A evidência deve permitir a uma pessoa externa entender o requisito, a solução, a data, o responsável e a verificação feita. Captura de tela sem contexto raramente é suficiente sozinha.
Erros que fragilizam a rotina
Evite depender de um único fornecedor sem verificar portabilidade; deixar chaves de criptografia apenas com o provedor; testar somente se o arquivo abre, sem validar a operação; usar contas compartilhadas; e ignorar alertas de falha. Outro erro é confundir retenção com backup: histórico de versões pode ajudar, mas não substitui uma estratégia de recuperação que considere os dados e os tempos necessários.
Conclusão
Backup é uma prática de gestão. Quando a serventia conhece seus dados críticos, define RPO, mantém cópias independentes, testa restaurações e guarda evidências, ela reduz uma incerteza que pode comprometer toda a continuidade do serviço.
Escrito por: Isabella Flores