Backup de ERP: Como Proteger SAP, TOTVS e Outros Sistemas
O ERP é o sistema mais crítico de qualquer empresa — concentra financeiro, estoque, vendas, compras e RH em uma única plataforma. Perder dados do ERP significa paralisar toda a operação. Aprenda a configurar backup de ERP (SAP, TOTVS, Oracle, Dynamics) com RPO adequado, estratégias de restauração e proteção contra ransomware.
Pontos-Chave deste Artigo
- O ERP é o sistema mais crítico da empresa — 1 hora sem ele custa em média R$ 50.000-200.000
- Backup de ERP exige estratégia application-aware que capture o estado transacional do banco de dados
- RPO recomendado: 1 hora ou menos para ERPs de alta transação
- A DataBackup suporta backup de Oracle, SQL Server, PostgreSQL e MySQL — os bancos dos principais ERPs
Por Que o ERP é o Sistema Mais Crítico
O ERP (Enterprise Resource Planning) é o coração digital de uma empresa. Ele integra e centraliza praticamente todos os processos de negócio:
- Financeiro: contas a pagar/receber, fluxo de caixa, demonstrativos
- Estoque: controle de inventário, compras, logística
- Vendas: pedidos, faturamento, comissões
- RH: folha de pagamento, ponto, benefícios
- Fiscal: notas fiscais, SPED, obrigações tributárias
- Produção: ordens de produção, PCP, controle de qualidade
Quando o ERP para, a empresa para. Vendedores não podem faturar, o financeiro não emite pagamentos, o estoque não atualiza e a produção não recebe ordens. Segundo pesquisa do Gartner, 1 hora de ERP inativo custa entre R$ 50.000 e R$ 200.000 para empresas de médio porte.
O Problema do Backup Genérico para ERP
Muitas empresas fazem "backup do servidor do ERP" copiando os arquivos do disco. Isso não é suficiente para um banco de dados transacional. O motivo:
- Enquanto o banco está rodando, existem transações em andamento (não gravadas em disco)
- Um backup de arquivos captura o disco em um estado possivelmente inconsistente
- Restaurar esse backup pode resultar em corrupção de dados — transações pela metade, integridade referencial quebrada
O backup correto de ERP exige uma abordagem application-aware: a ferramenta de backup se comunica com o banco de dados, solicita um ponto de consistência (checkpoint/snapshot), e então captura os dados em estado íntegro. Isso se chama backup consistente ou hot backup.
Estratégias de Backup por ERP
SAP (R/3, S/4HANA, Business One)
| Componente | Estratégia de Backup | Frequência |
|---|---|---|
| SAP HANA (in-memory) | Snapshot + delta backup via HANA Studio | A cada 15 min — 1 hora |
| SAP R/3 (Oracle/SQL Server) | BRTOOLS + backup externo do banco | Full diário + log a cada hora |
| SAP Business One | Backup do SQL Server via ferramenta externa | Full diário + diferencial a cada 4h |
| Customizações e configs | Backup de arquivos do sistema de transporte | Diário |
TOTVS (Protheus, RM, Datasul)
| Componente | Estratégia de Backup | Frequência |
|---|---|---|
| TOTVS Protheus (SQL Server/PostgreSQL) | Backup do banco + RPO files + environments | Full diário + log a cada hora |
| TOTVS RM (SQL Server) | Backup do SQL Server + attachments | Full diário + diferencial a cada 4h |
| TOTVS Cloud (SaaS) | Backup externo via API ou exportação | Diário |
| Customizações (ADVPL/TL++) | Controle de versão (Git) + backup de arquivos | A cada commit |
Oracle EBS / Oracle Cloud
| Componente | Estratégia de Backup | Frequência |
|---|---|---|
| Oracle Database | RMAN (Recovery Manager) + backup externo | Full semanal + incremental diário + archivelog contínuo |
| Oracle Cloud ERP | Export/Scheduled Backup + backup externo | Diário |
| Application tier | Backup de filesystem + configs | Diário |
Microsoft Dynamics 365
| Componente | Estratégia de Backup | Frequência |
|---|---|---|
| Dynamics 365 (Cloud) | Backup nativo Microsoft + backup externo via API | Diário (nativo restaura até 28 dias) |
| Dynamics on-premise | Backup do SQL Server via ferramenta externa | Full diário + log a cada hora |
| Integrações e customizações | Azure DevOps / backup de código | A cada deploy |
5 Regras de Ouro para Backup de ERP
1. RPO de 1 Hora ou Menos
Para a maioria dos ERPs corporativos, perder mais de 1 hora de transações é inaceitável. Configure backup de transaction log a cada 15-60 minutos. Isso permite restaurar o banco de dados até um ponto específico no tempo (point-in-time recovery), minimizando a perda de dados.
2. Backup Application-Aware, Não Genérico
Use ferramentas que entendam o banco de dados do ERP. A DataBackup suporta backup application-aware de Oracle, SQL Server, PostgreSQL e MySQL — solicitando checkpoints ao banco antes de capturar os dados, garantindo consistência.
3. Cópia Offsite Obrigatória
Manter backup do ERP apenas no mesmo data center é insuficiente. Uma cópia em nuvem protege contra desastre físico (incêndio, enchente) e ransomware que se propaga na rede local. Siga a regra 3-2-1.
4. Imutabilidade para Proteção Anti-Ransomware
Ransomware sofisticado busca especificamente backups para criptografá-los antes de atacar os dados de produção. Backup imutável com Object Lock garante que os backups do ERP sejam intocáveis pelo período de retenção — mesmo que o ransomware comprometa toda a rede.
5. Teste de Restauração Mensal
Restaure o banco de dados do ERP em ambiente de teste pelo menos uma vez por mês. Valide que as transações estão íntegras, que reports funcionam e que o sistema está operacional. Um backup que não restaura é apenas consumo de storage. Documente os resultados na sua política de backup.
Compatibilidade de ERPs e Bancos de Dados: Tabela Completa
Cada ERP utiliza um ou mais bancos de dados como engine de armazenamento. Conhecer o banco subjacente é essencial para configurar o backup application-aware correto. A tabela abaixo lista os principais ERPs do mercado brasileiro e seus respectivos bancos de dados suportados.
| ERP | Banco(s) de Dados Suportado(s) | Versão On-Premise | Versão Cloud/SaaS | Backup Nativo Incluso? | Backup Externo Recomendado? |
|---|---|---|---|---|---|
| SAP S/4HANA | SAP HANA (exclusivo) | Sim | Sim (SAP Cloud) | Sim (HANA Studio) | Sim — recomendado como segunda camada |
| SAP R/3 (ECC) | Oracle, SQL Server, DB2, MaxDB | Sim | Limitado | Sim (BRTOOLS) | Sim — essencial para backup do banco |
| SAP Business One | SQL Server, SAP HANA | Sim | Sim | Parcial | Sim |
| TOTVS Protheus | SQL Server, PostgreSQL, Oracle | Sim | Sim (TOTVS Cloud) | Parcial (depende do DBA) | Sim — RPO files + banco |
| TOTVS RM | SQL Server | Sim | Sim | Não | Sim — obrigatório |
| TOTVS Datasul | Progress OpenEdge, Oracle | Sim | Sim | Parcial | Sim |
| Oracle EBS (E-Business Suite) | Oracle Database | Sim | Limitado | Sim (RMAN) | Sim — backup externo do RMAN |
| Oracle Cloud ERP | Oracle Autonomous DB | N/A | Sim (nativo) | Parcial (retenção limitada) | Sim — backup independente via export |
| Microsoft Dynamics 365 | SQL Server (on-prem), Azure SQL (cloud) | Sim | Sim | Cloud: 28 dias de restauração | Sim — retenção maior + proteção completa |
| Microsoft Dynamics NAV/BC | SQL Server | Sim | Sim (Business Central) | On-prem: Não. Cloud: limitado | Sim |
| Sankhya | Oracle, PostgreSQL | Sim | Sim | Não | Sim — obrigatório |
| Senior Sistemas | PostgreSQL, Oracle | Sim | Sim | Não | Sim — obrigatório |
| Bling / Tiny | Cloud nativo (SaaS) | N/A | Sim (apenas) | Export manual | Sim — export + backup externo |
| Omie | Cloud nativo (SaaS) | N/A | Sim (apenas) | API de exportação | Sim — via API + armazenamento externo |
A DataBackup suporta backup application-aware de Oracle, SQL Server, PostgreSQL e MySQL — cobrindo os bancos de dados de todos os ERPs listados acima. Para ERPs SaaS, oferecemos orientação sobre estratégias de export + backup externo.
Estratégia de Backup por Módulo do ERP
Nem todos os módulos do ERP têm a mesma criticidade. Definir a estratégia de backup por módulo permite otimizar recursos e garantir que os dados mais sensíveis tenham proteção adequada.
| Módulo do ERP | Criticidade | RPO Recomendado | Estratégia de Backup | Observação |
|---|---|---|---|---|
| Financeiro (Contas a Pagar/Receber) | Crítico | 15 min — 1 hora | Transaction log contínuo + full diário | Perda gera retrabalho financeiro e risco de pagamentos duplicados |
| Fiscal (NF-e, SPED, obrigações) | Crítico | 15 min | Transaction log contínuo + full diário + backup de XMLs | Perda de NF-e pode gerar multa. XMLs devem ser retidos por 5+ anos |
| Estoque / WMS | Alto | 1 — 4 horas | Incremental a cada 2h + full diário | Divergência de estoque afeta vendas e produção |
| Vendas / CRM | Alto | 1 — 4 horas | Incremental a cada 2h + full diário | Perda de pedidos gera retrabalho e impacto no cliente |
| Compras / Suprimentos | Médio | 4 — 8 horas | Incremental a cada 4h + full diário | Pode operar manualmente por algumas horas em emergência |
| Produção / PCP | Alto | 1 — 4 horas | Incremental a cada 2h + full diário | Em indústrias, parada de PCP paralisa chão de fábrica |
| RH / Folha de Pagamento | Médio (Alto em período de folha) | 4 — 24 horas (1h durante processamento) | Incremental a cada 4h + full diário; RPO reduzido no período de folha | Durante processamento de folha (dias 25-05), aumentar frequência |
| Contabilidade | Alto (Crítico em fechamento) | 1 — 4 horas (15 min em fechamento) | Incremental a cada 2h + full diário; intensificado no fechamento mensal | Fechamento contábil exige RPO mínimo. Saiba mais |
| Customizações / Código-fonte | Médio | 24 horas | Controle de versão (Git) + backup diário de arquivos | Código pode ser reconstruído, mas perda gera atraso em projetos |
Importante: os RPOs acima são recomendações gerais. Cada empresa deve definir seus valores com base na análise de impacto (BIA) específica do seu negócio.
Estudo de Caso: Crash do ERP Durante Fechamento Mensal
O cenário a seguir ilustra o impacto real de um incidente com ERP e como a estratégia de backup determina a diferença entre uma recuperação de horas e uma crise de dias.
O Cenário
Uma distribuidora de médio porte (280 funcionários, faturamento R$ 15 milhões/mês) utiliza TOTVS Protheus com SQL Server como ERP principal. No dia 28 de um mês, durante o fechamento contábil e fiscal, o servidor do ERP sofreu falha de storage (RAID degradado seguido de falha de segundo disco). O banco de dados ficou corrompido e o servidor parou completamente.
O que estava em jogo
- 328 NF-e emitidas naquele dia — precisavam estar no SPED do mês
- R$ 4,2 milhões em contas a pagar programadas para os próximos 3 dias
- Apuração de impostos em andamento — prazo do SPED em 2 dias úteis
- Conciliação bancária de R$ 12 milhões processada parcialmente
- 280 funcionários sem acesso a vendas, estoque, financeiro e expedição
Cenário A — Sem backup adequado (o que teria acontecido)
- Último backup full: 5 dias antes (backup semanal aos domingos)
- Sem backup de transaction log — todas as transações de segunda a sexta perdidas
- Reconstrução manual: 5+ dias de trabalho, estimativa de R$ 180.000 em horas extras + consultoria
- Multa por atraso no SPED: R$ 1.500/dia após o prazo
- Perda de vendas durante parada: R$ 750.000/dia de faturamento perdido
- Prejuízo estimado: R$ 400.000 — R$ 1.000.000
Cenário B — Com backup application-aware (o que realmente aconteceu)
- Backup incremental do SQL Server rodava a cada 1 hora (transaction log)
- Último backup válido: 47 minutos antes da falha
- Restauração bare-metal do servidor em novo hardware: 2 horas
- Restauração do banco até o point-in-time de 47 min antes: 1 hora
- Validação e retomada da operação: 1 hora
- Tempo total de parada: 4 horas. Dados perdidos: 47 minutos de transações.
- Retrabalho para recriar 47 min de transações: 2 horas com equipe financeira
- Custo real: aproximadamente R$ 15.000 (hardware novo + horas da equipe)
A diferença entre os dois cenários é a estratégia de backup. O investimento mensal em backup corporativo profissional representava menos de 0,1% do custo do Cenário A.
Recomendações de RPO por Nível de Criticidade do ERP
O RPO (Recovery Point Objective) define a quantidade máxima de dados que a empresa aceita perder em caso de incidente. Para ERPs, o RPO deve ser definido com base no volume transacional e no custo de retrabalho.
| Perfil da Empresa | Volume Transacional | RPO Recomendado | Estratégia de Backup | Custo Estimado de Retrabalho (por hora perdida) |
|---|---|---|---|---|
| E-commerce alto volume | 1.000+ pedidos/dia | 15 minutos | Transaction log contínuo + DRaaS com failover automático | R$ 50.000 — 200.000 |
| Indústria com produção contínua | 500+ OPs/dia | 15 — 30 minutos | Transaction log a cada 15 min + réplica do banco | R$ 30.000 — 100.000 |
| Distribuidor / Atacadista | 200+ NF-e/dia | 30 minutos — 1 hora | Transaction log a cada 30 min + full diário | R$ 10.000 — 50.000 |
| Varejo com múltiplas lojas | 500+ PDVs/dia | 30 minutos — 1 hora | Transaction log a cada 30 min + sincronização PDV | R$ 20.000 — 80.000 |
| Prestadora de serviços | 50-200 transações/dia | 1 — 4 horas | Incremental a cada 2h + full diário | R$ 5.000 — 20.000 |
| PME com operação administrativa | 20-100 transações/dia | 4 — 8 horas | Incremental a cada 4h + full diário | R$ 2.000 — 10.000 |
| Microempresa | Menos de 20 transações/dia | 8 — 24 horas | Full diário + cópia offsite em nuvem | R$ 500 — 5.000 |
Regra prática: calcule quantas transações sua empresa processa por hora no ERP. Multiplique pelo custo médio de recriar cada transação manualmente (incluindo tempo de funcionário, risco de erro e possíveis multas fiscais). Esse valor é o custo real do RPO — compare com o investimento em backup para encontrar o ponto de equilíbrio.
Checklist: Seu Backup de ERP Está Adequado?
Responda as perguntas abaixo para avaliar se a proteção do seu ERP está adequada. Se mais de 3 respostas forem "não", sua empresa está em risco.
- O backup do banco de dados do ERP é application-aware (não apenas cópia de arquivos)?
- O RPO do ERP é de 1 hora ou menos para módulos financeiro e fiscal?
- Existe cópia offsite do backup em nuvem ou data center remoto?
- O backup inclui todas as camadas: banco de dados + application tier + customizações + configs?
- Restauração do ERP é testada pelo menos mensalmente?
- Existe backup imutável para proteger contra ransomware?
- O backup está documentado na política de backup da empresa?
- A equipe sabe como restaurar o ERP e tem procedimento documentado?
- O backup do ERP segue a regra 3-2-1?
- Para ERPs SaaS (TOTVS Cloud, Oracle Cloud, Dynamics 365): existe backup independente do provedor?
Quanto Custa Perder Dados do ERP
| Cenário | Custo Estimado |
|---|---|
| 1 hora de ERP inativo (PME) | R$ 50.000 — 200.000 |
| Reconstrução de 1 dia de transações | R$ 10.000 — 80.000 (manual) |
| Perda de NFe (obrigação fiscal) | Multa + retrabalho |
| Corrupção do banco (sem backup consistente) | R$ 50.000 — 500.000 em consultoria |
| Ransomware + sem backup imutável | Resgate: R$ 100.000 — milhões |
O investimento em backup corporativo profissional (a partir de R$ 159,90/mês) é uma fração do prejuízo de um único incidente. Para ERPs que geram centenas de transações por dia, o RPO de 1 hora que a DataBackup oferece pode significar a diferença entre reconstruir 1 hora de dados e reconstruir 1 semana.
DataBackup para ERP: Como Funciona
A DataBackup protege bancos de dados de ERPs corporativos com:
- Backup application-aware: integração nativa com Oracle, SQL Server, PostgreSQL e MySQL
- Transaction log backup: captura incremental a cada 15-60 minutos
- Point-in-time recovery: restaure o banco até o minuto exato antes do incidente
- Deduplicação global: reduz o volume armazenado em 40-60% para bancos de dados
- Criptografia AES-256: dados protegidos em trânsito e em repouso
- Backup imutável: Object Lock impede exclusão por ransomware
- Monitoramento 24/7: alerta imediato se o backup do ERP falhar
- Data center Tier III+ no Brasil: LGPD compliance
Teste grátis por 14 dias e proteja o sistema mais crítico da sua empresa. Configuração assistida pelo nosso suporte técnico especializado.
A DataBackup oferece backup nativo para SAP, TOTVS, Oracle, SQL Server e PostgreSQL com point-in-time recovery e RPO de até 15 minutos. Seu ERP nunca mais fica desprotegido. Teste 14 dias grátis.
Iniciar Teste Grátis Falar com Especialista