O TOTVS Protheus concentra dados financeiros, fiscais, contábeis e de RH da empresa. Uma falha sem backup adequado pode significar perda de dados irreversível, multas por descumprimento da LGPD e impossibilidade de operar. Este guia cobre o que precisa de backup no Protheus, como definir os parâmetros essenciais e como estruturar uma política de backup que funcione na prática.
Neste artigo
O que precisa de backup no TOTVS Protheus
Muitas empresas fazem backup do banco de dados e acham que estão protegidas. O Protheus tem mais componentes que precisam ser preservados para uma recuperação completa:
| Componente | O que contém | Impacto se perdido | Prioridade |
|---|---|---|---|
| Banco de dados SQL Server | Todos os dados transacionais do ERP | Perda de dados financeiros, fiscais, de RH | Crítica |
| Arquivos de configuração do Protheus | appserver.ini, dbaccess.ini, configurações de módulos | Reconfiguração manual demorada | Alta |
| Customizações ADVPL compiladas | Rotinas customizadas compiladas no repositório | Perda de funcionalidades específicas da empresa | Alta |
| Código-fonte ADVPL | Arquivos .prw, .tlpp das customizações | Impossibilidade de manutenção futura | Alta |
| Arquivos do Protheus (sistema) | Executáveis, dicionário de dados, help files | Reinstalação necessária | Média |
| Arquivos e documentos anexados | Documentos fiscais, contratos, fotos de produtos | Perda de documentação | Média |
| XML de NF-e e documentos fiscais | XMLs de notas emitidas e recebidas | Risco fiscal e tributário | Crítica (LGPD e fiscal) |
Backup vs snapshot: uma diferença crítica
Snapshot de VM e backup de banco de dados não são a mesma coisa — e confundir os dois é um dos erros mais graves de proteção de dados no Protheus.
| Característica | Snapshot de VM/Storage | Backup de banco de dados |
|---|---|---|
| O que captura | Estado da VM ou do volume no momento | Dados consistentes do banco (com log) |
| Consistência do banco | Pode capturar banco em estado inconsistente | Consistente por definição |
| Granularidade de recuperação | Restore de tudo ou nada (volume inteiro) | Restore até um ponto no tempo específico |
| Velocidade de criação | Instantâneo (segundos) | Minutos a horas (dependendo do tamanho) |
| Adequado como única proteção | Não — complementar ao backup | Sim — proteção primária |
Snapshot não substitui backup do banco
Snapshots de storage (como os do Pure Storage) são excelentes para recuperação rápida de falhas de VM ou corrupção de sistema operacional. Porém, um snapshot capturado com o SQL Server ativo pode conter o banco em estado inconsistente. O backup do banco de dados (via SQL Server Backup ou ferramenta dedicada) é a proteção primária dos dados do Protheus.
RPO e RTO: os parâmetros que definem a política
Antes de definir frequência e retenção do backup, é necessário responder duas perguntas:
- RPO (Recovery Point Objective): quanto de dado posso perder? Se o RPO é 4 horas, preciso de backup a cada 4 horas. Se é zero, preciso de log shipping ou mirroring em tempo real.
- RTO (Recovery Time Objective): em quanto tempo preciso estar operacional após um incidente? Se o RTO é 2 horas, o processo de restore completo (banco + aplicação + testes) precisa caber nesse tempo.
| Perfil de negócio | RPO típico | RTO típico | Implicação |
|---|---|---|---|
| Operação tolerante a perda | 24 horas | 4–8 horas | Backup diário noturno é suficiente |
| Operação comercial padrão | 4 horas | 2–4 horas | Backup + log backup a cada 4 horas |
| Operação crítica / alto volume | 1 hora | 1–2 horas | Log backup a cada hora; ambiente de standby |
| Missão crítica / 24×7 | Minutos | Minutos | Always On AG ou log shipping + failover automático |
Política de backup recomendada para o Protheus
| Tipo de backup | Frequência | Destino | Retenção | Observação |
|---|---|---|---|---|
| Full do banco | Diário (noturno) | Storage local + cópia offsite | 30 dias | Verificar integridade após geração |
| Diferencial do banco | A cada 6–12 horas | Storage local | 7 dias | Reduz o RTO sem gerar arquivo completo |
| Log de transação | A cada 30–60 min | Storage local | 7 dias | Permite recuperação ponto a ponto |
| Backup semanal (full) | Semanal | Destino offsite / nuvem | 90 dias | Proteção contra ransomware e falhas locais |
| Backup mensal | Mensal (fim do mês) | Destino offsite imutável | 12 meses (mínimo LGPD) | Backup imutável — não pode ser alterado ou deletado |
Snapshots Pure Storage como camada adicional
Nos ambientes Adentro com Pure Storage, snapshots de volume são criados automaticamente como ponto de recuperação rápida para falhas de sistema operacional ou corrupção de arquivos de sistema. Esses snapshots complementam o backup do banco — nunca o substituem.
Erros comuns que invalidam o backup
- Nunca testar o restore. Backup que nunca foi restaurado é backup não verificado. Faça teste de restore em ambiente isolado pelo menos a cada 90 dias.
- Fazer backup e destino no mesmo servidor. Se o servidor falhar, backup e dados originais são perdidos juntos. O destino primário deve ser separado do servidor do banco.
- Não ter cópia offsite. Backup local protege contra falha de hardware. Não protege contra incêndio, alagamento ou ransomware que cifra tudo na rede. A cópia offsite (nuvem ou site alternativo) é obrigatória.
- Não monitorar o backup. Job de backup que falha silenciosamente por dias (ou semanas) sem alerta é o cenário mais comum antes de uma perda de dados.
- Confundir snapshot de VM com backup do banco. Ver seção anterior — snapshot de VM captura o banco em estado possivelmente inconsistente.
- Não definir retenção adequada. Ransomware e corrupção de dados frequentemente só são descobertos dias depois. Se a retenção é de apenas 7 dias, o backup já pode estar comprometido quando o problema é identificado.
Backup do Protheus e LGPD
O TOTVS Protheus processa dados pessoais de funcionários (folha de pagamento, RH), clientes e fornecedores. Sob a LGPD, a empresa tem obrigações sobre a proteção e o ciclo de vida desses dados:
- Período de retenção: dados pessoais devem ser mantidos apenas pelo tempo necessário para a finalidade que justificou seu tratamento — ou pelo prazo legal aplicável (ex.: 5 anos para dados fiscais e trabalhistas).
- Criptografia dos backups: backups que contêm dados pessoais devem ser criptografados, especialmente cópias offsite.
- Acesso controlado: somente pessoas autorizadas devem ter acesso aos backups — especialmente em destinos em nuvem.
- Descarte seguro: ao encerrar a retenção, os backups devem ser descartados de forma segura (não apenas deletados).
Dimensione o backup do seu Protheus
Use a Calculadora de Backup para estimar capacidade e custo com base no volume do banco e na política de retenção.
Perguntas frequentes
Com que frequência devo testar o restore do banco do Protheus?
No mínimo a cada 90 dias. Para ambientes críticos, o teste mensal é mais adequado. O teste deve incluir a restauração completa do banco e a validação de que o Protheus consegue abrir e operar normalmente com o banco restaurado.
O backup do banco do Protheus protege contra ransomware?
Protege se a cópia offsite for imutável — ou seja, não puder ser alterada ou deletada pelo ransomware. Backup local acessível pela rede pode ser cifrado junto com os dados originais. A cópia offsite em destino imutável (nuvem com proteção de exclusão, fita) é a proteção real contra ransomware.
Quanto tempo leva o restore do banco do Protheus?
Depende do tamanho do banco e do hardware do ambiente de restore. Um banco de 500 GB pode levar de 30 minutos a 3 horas, dependendo do storage e da rede. Faça o teste de restore com cronometragem para saber o RTO real — não o estimado.
Preciso de backup dos arquivos XML de NF-e separado do banco?
Depende de como os XMLs são armazenados no seu ambiente. Se os XMLs ficam apenas no banco de dados SQL Server, o backup do banco os cobre. Se são armazenados em diretórios no servidor de aplicação, precisam de backup separado dos arquivos. Verifique onde os XMLs são gravados na sua configuração.
