Atualizado em
Backup e Guia de Disaster Recovery não são a mesma coisa. Backup protege contra perda de dados. DR protege contra indisponibilidade prolongada do sistema — que, para o TOTVS Protheus, significa ERP fora do ar e operação parada. Este artigo explica como definir o plano de DR para o Protheus: dos objetivos de RPO e RTO e RPO até as arquiteturas disponíveis e o que o plano precisa cobrir.
Neste artigo
O que é um evento de desastre para o Protheus
Para fins de DR, um desastre é qualquer evento que torne o TOTVS Protheus indisponível por um período superior ao tolerado pela operação. Não é apenas incêndio ou inundação — na prática, os eventos mais comuns são:
- Falha de hardware — pane no servidor, storage ou componente de rede
- Corrupção do banco de dados — falha de escrita, shutdown inesperado durante transação
- Ransomware — cifração dos dados e do backup local pela mesma ameaça
- Falha do datacenter — perda de energia, falha de climatização, acidente físico
- Erro humano crítico — exclusão acidental de dados, tabela ou banco inteiro
- Falha do provedor de nuvem — indisponibilidade de região ou zona de disponibilidade
O custo de indisponibilidade do Protheus varia com o porte e o setor da empresa, mas qualquer operação com emissão de NF-e, faturamento ou folha de pagamento sente o impacto em horas. Quanto maior o volume transacional, maior o impacto por hora de parada.
RPO e RTO: definindo os objetivos de recuperação
Os dois parâmetros fundamentais de um plano de DR são:
- RPO (Recovery Point Objective): até qual ponto no tempo a empresa aceita perder dados? Um RPO de 1 hora significa que, no pior caso, as transações da última hora serão perdidas.
- RTO (Recovery Time Objective): em quanto tempo o Protheus precisa estar operacional após um incidente? RTO de 4 horas significa que a operação pode ficar parada no máximo 4 horas.
RPO e RTO precisam ser definidos pelo negócio, não pela TI
O RPO e o RTO refletem o quanto a operação aguenta parada e quanto dado pode ser reprocessado. Essa decisão é dos gestores de operação e financeiro — não da TI. A TI implementa a arquitetura que atende esses objetivos.
Quatro arquiteturas de DR para o Protheus
| Estratégia | RPO | RTO | Complexidade | Custo relativo | Quando usar |
|---|---|---|---|---|---|
| Backup + restore manual | Horas (depende da frequência) | 4–8 horas+ | Baixa | Baixo | Operações que toleram horas de parada |
| Ambiente de standby (warm) | 15–60 min | 1–2 horas | Média | Médio | Maioria das operações comerciais |
| SQL Server Always On AG | Segundos a minutos | Minutos | Alta | Alto | Operações críticas com baixa tolerância |
| Replicação síncrona + HA | Zero (sem perda de dados) | Segundos (automático) | Muito alta | Muito alto | Missão crítica — zero tolerância |
Para a maioria das empresas que usam o Protheus como ERP principal, a estratégia de ambiente de standby warm com log shipping é o equilíbrio mais adequado entre custo, RPO e RTO. O standby mantém uma cópia do banco atualizada a intervalos regulares em um servidor alternativo — que pode assumir a operação em horas.
O que o plano de DR do Protheus precisa cobrir
Um plano de DR efetivo para o Protheus não é só uma arquitetura técnica — é um documento que define quem faz o quê, quando e como:
- Critérios de acionamento: qual evento ou condição aciona o DR? Quem tem autoridade para declarar o desastre?
- Árvore de comunicação: quem notificar, em qual ordem e por qual canal
- Runbook técnico: passo a passo para ativar o ambiente de DR (AppServer, DBAccess, SQL Server, integrações, DNS)
- Validação mínima: o que precisa funcionar para o ambiente de DR ser declarado operacional?
- Comunicação com usuários: como e quando informar que o sistema está disponível (mesmo que em modo DR)
- Retorno ao ambiente principal: como e quando reverter para o ambiente primário após a recuperação
- Responsabilidades: o que é responsabilidade do provedor de infra e o que é do cliente
- Integrações: as integrações externas (SEFAZ, EDI, transportadoras) precisam ser reconfiguradas ou apontam automaticamente para o ambiente de DR?
Como testar o DR sem interromper a produção
Um plano de DR que nunca foi testado é uma hipótese, não uma garantia. O teste de DR deve ser realizado pelo menos uma vez por ano para ambientes padrão, e a cada 6 meses para ambientes críticos.
Formas de testar sem interromper a produção:
- Teste de restore isolado: restaurar o banco em um servidor temporário separado e validar que o Protheus inicia e opera. Não afeta a produção.
- Teste de failover planejado: em uma janela de manutenção, ativar o ambiente de standby e operar por 1–2 horas antes de reverter. Valida o runbook completo.
- Validação de RTO cronometrada: medir o tempo real do processo de ativação do DR — não o estimado. O RTO real deve ser documentado e revisado a cada teste.
Diferença entre backup e DR — resumo
| Aspecto | Backup | Disaster Recovery |
|---|---|---|
| Objetivo principal | Proteger dados contra perda | Garantir continuidade operacional |
| O que faz | Copia e armazena dados periodicamente | Mantém ambiente alternativo para assumir a operação |
| Tempo para voltar | Horas (restore + configuração) | Minutos a horas (dependendo da arquitetura) |
| Perda de dados | Depende da frequência do último backup | Depende do RPO da estratégia escolhida |
| São excludentes? | Não — backup é parte do DR. DR sem backup não protege dados; backup sem DR não garante continuidade. | |
Quer definir o DR do Protheus na sua empresa?
A Adentro projeta e implementa arquiteturas de disaster recovery para ambientes TOTVS Protheus, do standby warm ao Always On.
Solução de DR Falar com especialistaPerguntas frequentes
Preciso de DR se já tenho backup do Protheus?
O backup protege os dados. O DR garante que a operação volta em tempo aceitável após um incidente. São complementares: sem backup, o DR não tem dados para recuperar; sem DR, o backup pode levar horas ou dias para ser restaurado em um ambiente funcional. Para operações com baixa tolerância à indisponibilidade, os dois são necessários.
O SQL Server Always On é obrigatório para o Protheus?
Não. Always On é uma das arquiteturas disponíveis, mas não é obrigatória. É recomendada para operações críticas com RTO abaixo de 15 minutos. Para a maioria das empresas, um ambiente de standby warm com log shipping atende os objetivos de RPO e RTO com menor complexidade e custo.
O DR do Protheus precisa incluir as customizações ADVPL?
Sim. O ambiente de DR precisa ter todas as customizações compiladas e configuradas — caso contrário, ao ativar o DR, as funcionalidades customizadas não estarão disponíveis. As customizações devem ser parte do runbook de ativação do DR.
As integrações do Protheus continuam funcionando no ambiente de DR?
Depende de como estão configuradas. Integrações que apontam para o servidor de produção por nome ou IP precisarão ser reconfiguradas para apontar para o ambiente de DR. O ideal é que as integrações usem um nome DNS que possa ser redirecionado rapidamente — evitando reconfiguração manual de cada integração durante um incidente.
Você também pode se interessar:
