Backup de ERP: Como Proteger TOTVS, Sankhya e Outros Sistemas de Gestão

Por que o backup do ERP merece uma estratégia própria

O ERP concentra o que mantém a empresa funcionando: pedidos, notas fiscais, contas a pagar e a receber, estoque, folha, contabilidade e histórico de clientes. Se o TOTVS Protheus, o Sankhya ou outro sistema de gestão para, a empresa deixa de faturar, não consegue separar pedidos e perde prazos fiscais. Por isso o backup do ERP não pode ser tratado como mais uma pasta copiada no fim do dia. Ele precisa de uma estratégia própria, pensada para o tipo de dado e para quanto tempo a operação aguenta ficar parada.

Muitas empresas descobrem o problema no pior momento. O backup existia, mas copiava só os arquivos do banco com o serviço rodando, gerando cópias inconsistentes. Ou protegia o banco de dados e esquecia os anexos, os XMLs das notas e as customizações feitas ao longo dos anos. Na hora do restore, o sistema volta incompleto, e a equipe passa dias refazendo lançamentos à mão.

Uma boa proteção de dados do ERP começa com duas perguntas simples: quanto dado a empresa aceita perder (o RPO, ou ponto de recuperação) e em quanto tempo o sistema precisa voltar (o RTO, ou tempo de recuperação). Uma distribuidora que emite centenas de notas por hora não pode aceitar perder um dia inteiro de movimento. Já um escritório com poucos lançamentos diários pode trabalhar com janelas maiores. Essas respostas definem a frequência, o tipo de backup e a infraestrutura necessária.

O que precisa entrar no backup de um ERP

O erro mais comum é achar que o ERP é só o banco de dados. Na prática, um ambiente de gestão é formado por várias camadas, e todas precisam ser protegidas para que um restore devolva o sistema funcionando de verdade, e não só uma tabela de dados sem contexto.

• Banco de dados: SQL Server, Oracle ou PostgreSQL, conforme o ERP. É o coração do sistema e exige backup nativo e consistente (full, diferencial e log de transações).
• Anexos e documentos: XMLs de NF-e e CT-e, PDFs, imagens de produtos, contratos e comprovantes gravados em pastas do servidor ou em repositórios próprios.
• Customizações: no TOTVS Protheus, fontes ADVPL/TLPP compilados no RPO, pontos de entrada e o dicionário de dados (SX); no Sankhya, personalizações, telas, eventos e regras criadas no próprio sistema.
• Arquivos de configuração: appserver.ini, configurações do servidor de licenças, parâmetros de conexão, certificados digitais e agendamentos de rotinas.
• Integrações: scripts, conectores com e-commerce, bancos (CNAB e arquivos de retorno), EDI com clientes e fornecedores, e APIs de terceiros.
• Servidor de aplicação: a máquina virtual inteira, para permitir subir o ambiente rapidamente em caso de falha de hardware ou ataque.

Mapear essas camadas é um trabalho que vale a pena fazer junto com a consultoria ou o time interno responsável pelo ERP. Em muitas empresas, customizações foram feitas por pessoas que já não estão mais lá, e ninguém sabe exatamente onde ficam os arquivos. O levantamento feito com antecedência evita surpresas justamente no dia em que o sistema precisa voltar.

Como estruturar o backup do banco de dados do ERP

Copiar os arquivos físicos do banco (.mdf, .ldf ou datafiles) com o serviço ligado não garante uma cópia íntegra. O caminho correto é usar os mecanismos nativos do banco ou uma ferramenta de backup que converse com ele, como o Veeam com processamento consistente de aplicação. Assim, o backup é feito em um ponto consistente e pode ser restaurado sem corrupção.

Para a maioria dos ambientes TOTVS e Sankhya, um desenho equilibrado combina três tipos de cópia:

1. Backup full: cópia completa do banco, normalmente diária ou semanal, fora do horário de pico.
2. Backup diferencial: guarda o que mudou desde o último full, reduzindo tempo e espaço.
3. Backup de log de transações: em intervalos curtos (15 a 60 minutos), permite voltar o banco a um ponto específico, como o minuto anterior a uma exclusão acidental.

Também é importante acompanhar o crescimento do banco e a duração das rotinas. Um ERP com anos de histórico pode ter centenas de gigabytes, e um backup que ultrapassa a janela noturna passa a concorrer com o processamento do dia seguinte. Nesses casos, compressão, backup incremental em nível de bloco e armazenamento mais rápido fazem diferença. Rotinas pesadas de fechamento, como o fechamento de estoque e a apuração fiscal, também merecem um backup extra antes e depois de rodar.

Backup que nunca foi restaurado é só uma expectativa. A única prova de que o ERP está protegido é um restore testado, com o sistema abrindo e os dados conferidos.

A regra 3-2-1 e a proteção contra ransomware

O ERP é um alvo preferido de ataques de ransomware, justamente porque parar o faturamento pressiona a empresa a pagar o resgate. Os ataques atuais procuram os backups primeiro: se as cópias estão no mesmo servidor, no mesmo domínio ou em um compartilhamento acessível, são criptografadas junto com o sistema principal.

A regra 3-2-1 continua sendo a base de uma proteção sólida: três cópias dos dados, em dois tipos de mídia diferentes, com uma delas fora do ambiente principal. Hoje, recomenda-se ir além com o modelo 3-2-1-1-0, que acrescenta uma cópia imutável ou desconectada e zero erros na verificação dos backups.

• Cópia local: para restores rápidos do dia a dia, como uma tabela apagada ou um arquivo corrompido.
• Cópia externa em nuvem ou data center: protege contra incêndio, roubo, falha elétrica ou perda total do escritório.
• Cópia imutável: não pode ser alterada nem apagada durante o período de retenção, nem mesmo por um administrador com a senha comprometida.
• Credenciais separadas: o repositório de backup não deve usar a mesma conta do domínio da empresa, e o acesso deve ter autenticação multifator.

A retenção também precisa considerar exigências legais e fiscais. Documentos fiscais e contábeis têm prazos de guarda obrigatórios, e a LGPD exige cuidado com dados pessoais de clientes e colaboradores armazenados no ERP. Combinar retenção diária, semanal, mensal e anual permite voltar a um ponto recente com rapidez e, ao mesmo tempo, recuperar informações antigas quando uma auditoria ou fiscalização pedir.

Testes de restore: onde a maioria das estratégias falha

O teste de restore é a etapa mais ignorada e a mais importante. Um log de backup marcado como "concluído com sucesso" não garante que o banco vai abrir, que o RPO do Protheus está compatível com o dicionário de dados, ou que os anexos estão no lugar certo. Só um teste real mostra se o plano funciona e quanto tempo ele leva.

O ideal é ter um roteiro de testes periódicos, executado em um ambiente isolado para não afetar a produção:

1. Restaurar o banco de dados em um servidor de homologação, pelo menos uma vez por mês.
2. Subir o servidor de aplicação com as customizações e conectar ao banco restaurado.
3. Validar logins, abrir rotinas críticas (faturamento, estoque, financeiro) e conferir saldos e últimos lançamentos.
4. Verificar se anexos, XMLs e integrações aparecem corretamente.
5. Medir o tempo total do processo e comparar com o RTO definido pela diretoria.
6. Registrar o resultado, os problemas encontrados e as correções feitas.

Esse ambiente de teste tem um benefício extra: pode ser usado para homologar atualizações do ERP, pacotes de correção e novas customizações antes de aplicá-los em produção. Assim, o investimento em testes de restore também reduz o risco de uma atualização mal planejada derrubar o sistema no meio do mês.

Como a Duk protege o ERP da sua empresa

Montar e manter uma estratégia de backup de ERP exige disciplina: acompanhar rotinas todos os dias, agir rápido quando uma cópia falha, testar restores e ajustar o plano conforme o banco cresce e a operação muda. Para muitas empresas, esse trabalho acaba ficando em segundo plano até o dia em que faz falta.

A Duk Informática & Cloud atua há mais de 18 anos como parceira de TI de mais de 550 empresas, com ambientes que rodam TOTVS, Sankhya e outros sistemas de gestão. Como Microsoft Gold Partner e com data center próprio em Alphaville, a Duk desenha a estratégia de backup a partir do RPO e do RTO de cada cliente, com backup consistente do banco de dados, proteção de anexos e customizações, cópias externas e imutáveis contra ransomware e monitoramento contínuo das rotinas.

Além disso, a equipe da Duk faz testes de restore periódicos e entrega relatórios claros para a gestão, mostrando que o ERP pode voltar dentro do prazo combinado. Se a sua empresa ainda não sabe quanto tempo levaria para recuperar o sistema de gestão depois de uma falha, este é o momento de descobrir, antes que o problema aconteça. Fale com a Duk e avalie a proteção do seu ERP.