Backup de dados fiscais: por que testar o restore muda tudo

Um escritório contábil de São Paulo perdeu acesso ao servidor local numa sexta-feira à tarde. Falha de disco, sem aviso. O sócio abriu o painel do backup: rodando havia meses, sem erro registrado. Ele restaurou o último snapshot e descobriu que o índice do SPED estava corrompido desde março — quatro meses de arquivos gravados em cima de uma estrutura já quebrada, sem ninguém perceber, porque ninguém tinha aberto o arquivo restaurado desde então.

Isso não é hipótese. É o padrão mais comum de falha de backup que existe: o job roda, o arquivo é criado, o ícone fica verde — e o único jeito de saber se aquilo presta é restaurar de verdade. Quase ninguém faz esse teste antes de precisar dele pela primeira vez.

Backup não é a mesma coisa que dado recuperável

Um backup é uma cópia gravada. Um restore testado é a prova de que essa cópia volta a virar dado utilizável, com os números batendo com o original. A distinção parece óbvia escrita assim — e é justamente por parecer óbvia que quase todo escritório trata as duas coisas como sinônimo.

O painel de backup te diz se o job terminou. Ele não te diz se o arquivo gerado consegue reconstruir o SPED de uma competência específica, se o XML restaurado tem o mesmo hash do original, ou se a senha de criptografia usada há três anos ainda está em algum lugar acessível. Cada uma dessas perguntas só tem resposta quando alguém restaura de verdade — e não em produção, testando com o cliente esperando.

Quanto tempo o escritório é obrigado a guardar dado fiscal

O prazo legal de guarda de documento fiscal no Brasil é de cinco anos completos, pelo prazo decadencial do Código Tributário Nacional. Para nota fiscal eletrônica, a regra é mais específica: o XML precisa estar recuperável por cinco anos contados a partir do primeiro dia do ano seguinte ao da emissão. Um XML emitido em março de 2026 precisa estar restaurável até 31 de dezembro de 2031 — quase seis anos de janela real.

A responsabilidade legal por essa guarda é da empresa cliente, não do escritório que transmite. Mas isso é letra fria: na prática, quem vai receber a ligação em pânico quando um cliente for intimado a apresentar um XML de 2027 é o escritório, não o departamento jurídico de ninguém. Cinco anos é tempo suficiente para o sistema contábil trocar de versão, o servidor trocar de fornecedor de nuvem, e a pessoa que configurou o backup original já não trabalhar mais ali.

Por que a maioria dos backups nunca é testada

Levantamentos do setor de proteção de dados — como o publicado pela Unitrends, referência internacional em backup corporativo — mostram um padrão recorrente: uma fração relevante das empresas que tentam restaurar um backup descobre, só nesse momento, que o arquivo está incompleto ou corrompido. Não é um problema brasileiro nem específico de contabilidade. É estrutural de como backup costuma ser tratado — como rotina de infraestrutura que “só precisa rodar”, não como processo que precisa ser validado.

As causas mais comuns se repetem em qualquer setor:

• Agente de backup desatualizado. O software que copia os dados foi instalado há anos e nunca foi revisado. O sistema contábil trocou de versão, mudou de estrutura de banco, e o agente continua copiando um formato que já não existe mais daquele jeito.
• Senha de criptografia perdida. O backup está criptografado — boa prática — mas a senha foi definida por alguém que já não está mais na empresa. O arquivo existe. Ninguém consegue abrir.
• Dependência esquecida. O backup do banco de dados está perfeito, mas ninguém incluiu o certificado, a configuração de rede ou o arquivo de licença do sistema contábil. Restaurar o banco não adianta se o sistema em volta dele não sobe.

Nenhuma dessas três causas aparece no relatório de “backup concluído com sucesso”. Todas elas só aparecem quando alguém tenta restaurar.

O que muda quando você testa o restore de verdade

Testar restore não é reinstalar o sistema inteiro toda semana. É um processo pequeno, repetível, com três partes:

Primeiro, restaurar de fato um subconjunto de dados reais — uma competência específica, não um arquivo de teste vazio criado só para o exercício. Segundo, abrir o que foi restaurado e conferir se os números batem: total de notas, valores do SPED, folha do mês. Terceiro, cronometrar e documentar quanto tempo o processo levou, porque numa fiscalização com prazo de resposta curto, o tempo de restore importa tanto quanto o resultado.

A cadência recomendada é trimestral como mínimo aceitável, e mensal para os dados que mudam mais — NF-e, SPED, folha de pagamento. Documentos que mudam pouco (contratos antigos, por exemplo) podem ter teste semestral sem grande risco.

A diferença entre as duas posturas fica clara lado a lado:

	Backup sem teste	Backup com restore testado
O que existe	Cópia gravada, job “concluído”	Cópia gravada + prova de que volta a funcionar
Quando o problema aparece	No dia da emergência real	No teste trimestral, sem pressão
Quem descobre a falha	O cliente, na pior hora	O escritório, com tempo de corrigir
Prazo de resposta numa fiscalização	Incerto — depende de conseguir restaurar na hora	Conhecido — já foi cronometrado antes
Custo de corrigir um agente desatualizado	Alto, sob pressão	Baixo, dentro da rotina

Como isso fica na prática, com stack nomeada

Na nossa própria operação a regra é a mesma que recomendamos para cliente: backup sem teste de restore documentado não conta como backup, conta como esperança. Rodamos Postgres com backup diário e retenção definida, e o teste de restore não é opcional nem informal — é um processo com data marcada, dados reais e resultado registrado, exatamente como qualquer cliente deveria fazer com o próprio SPED.

Monitoramento entra como segunda camada, não substituto do teste manual: Zabbix acompanha se o job de backup rodou, se o tamanho do arquivo gerado está dentro do esperado (um backup 90% menor que o normal é sinal de que algo parou de ser copiado) e dispara alerta antes que três meses de silêncio virem uma surpresa. O alerta automático pega o sintoma rápido — o job falhou. O teste de restore trimestral pega o que o alerta não vê — o job “funcionou” mas o resultado está incompleto ou incompatível com a versão atual do sistema.

Para um escritório contábil, isso normalmente significa três camadas cobertas: o banco onde o sistema contábil grava (SPED, NF-e, folha), o repositório de arquivo bruto (XML, PDF de guia, certidão) e a configuração do próprio sistema — usuário, permissão, integração com o cliente. Backup que cobre só o banco e esquece as outras duas camadas passa no teste errado: você recupera os números, mas não recupera o sistema funcionando.

Onde o backup de terceiro te deixa exposto

Guardar cópia longe de casa é parte de qualquer estratégia de backup séria — a regra 3-2-1-1-0 (três cópias, dois tipos de mídia, uma fora do local, uma imutável, zero erro no teste) existe exatamente para isso. O problema não é usar armazenamento em nuvem de terceiro para a cópia extra.

O problema é terceirizar também o controle. Se só o fornecedor sabe fazer o restore, se só ele tem a chave de criptografia, e você nunca validou pessoalmente que um dado seu volta inteiro — o dado fiscal do seu cliente não está com você, está com a promessa de um contrato de nível de serviço que você provavelmente nunca leu até o fim. A tese não é abandonar nuvem. É garantir que o teste de restore acontece com quem responde pelo dado — o escritório —, não só com quem hospeda a cópia.

Quando não vale a pena complicar isso

Escritório pequeno, com poucos clientes e um sistema contábil que já faz backup gerenciado pelo próprio fornecedor, não precisa montar uma operação de backup paralela do zero. Nesse caso, o ganho real está em pedir ao fornecedor um teste de restore documentado — e recusar aceitar “sim, fazemos backup” como resposta suficiente sem ver a prova.

Também não vale a pena testar restore de dado que já passou do prazo de guarda obrigatório e não tem mais nenhum valor operacional. Arquivo de oito anos atrás, sem processo aberto, sem cliente ativo, não precisa entrar na rotina de teste — arquivar e esquecer é decisão válida, desde que seja decisão, não acidente.

Conclusão

O ícone verde no painel de backup prova que um job terminou. Não prova que o dado volta. A única forma de saber se o backup do seu escritório sobrevive a uma sexta-feira ruim é restaurar um pedaço dele antes que a sexta-feira ruim aconteça de verdade — com dado real, cronômetro rodando, e alguém conferindo se os números batem.