Alta disponibilidade para SAP Business One e HANA: o que realmente protege

📚 Continue aprendendo sobre este tema:

A confusão que custa caro

A conversa costuma começar assim: "estamos protegidos, temos backup". Backup é essencial e é a base de tudo. Ele apenas não responde à pergunta que a diretoria realmente faz quando o ERP para, que é: em quanto tempo voltamos a faturar?

Quem só tem backup descobre a resposta no pior momento possível. É preciso providenciar um servidor, reinstalar o ambiente, restaurar a base, reconectar as integrações, revalidar o acesso dos usuários e conferir se o que voltou está consistente. Cada uma dessas etapas leva tempo, e o tempo total só é conhecido por quem já ensaiou.

A tabela abaixo é o mapa que costuma encerrar a discussão em reunião:

Camada	Do que protege	Do que NÃO protege	Efeito no tempo de retomada
Backup	Perda de dado, corrupção, exclusão indevida, ransomware, erro humano em lançamento	Não evita a parada. Restaurar exige tempo e um ambiente onde restaurar	Alto, porque envolve preparar o destino antes de recuperar
Replicação	Perda do servidor ou do armazenamento onde o banco vive	Não protege contra erro lógico, porque o erro é copiado para a réplica	Menor, porque existe uma cópia atualizada pronta para assumir
Cluster	Falha de um componente ou de um servidor do conjunto	Não protege contra perda de dado nem contra perda do local inteiro	Baixo, porque a troca é automatizada
Disaster recovery	Indisponibilidade do local: incêndio, alagamento, falha prolongada de energia, evento de segurança em larga escala	Não substitui backup nem dispensa teste. Plano sem ensaio é papel	Depende do plano, e é justamente isso que precisa estar acordado por escrito

Backup: a cópia do passado

É a única camada que permite voltar no tempo. Se um lançamento errado apagou informação na sexta-feira, nenhuma réplica e nenhum cluster resolvem, porque os dois reproduziram fielmente o erro. Só o backup traz de volta o estado anterior.

Em ambiente de ERP, três pontos merecem atenção especial:

Consistência. A cópia precisa ser feita de um jeito que o banco de dados reconheça como válida na restauração. Copiar arquivos com o banco em uso, sem o procedimento adequado, produz uma cópia que parece existir e não restaura.
Cópia isolada. Ao menos uma cópia fora do alcance das credenciais do dia a dia. Ataque de ransomware bem-sucedido procura o backup antes de criptografar o resto.
Além do banco. Restaurar apenas a base não devolve o ERP. Entram na conta os anexos e documentos armazenados fora do banco, as configurações do ambiente, os complementos instalados, os arquivos de integração e o controle de licenças. O que não estiver na lista de recuperação será descoberto na hora errada.

A disciplina completa está descrita em política de backup e a regra 3-2-1, e vale aplicá-la integralmente ao ambiente SAP.

Replicação: a cópia do presente

Na replicação, as alterações do banco principal são enviadas continuamente para uma segunda cópia, em outro servidor. Quando o principal fica indisponível, essa cópia pode assumir o papel dele, e a empresa evita a etapa demorada de restaurar do zero.

Dois pontos que precisam ficar claros para quem decide:

Replicação não é backup. O erro cometido no principal é replicado. Se alguém apagar dados, a réplica também estará sem eles em instantes.
Existe uma escolha entre segurança e desempenho. Em um modo, a transação só é confirmada depois que a réplica também recebeu o dado, o que reduz ao máximo o risco de perda e exige uma conexão de qualidade entre os dois lados. Em outro, a confirmação é imediata e a réplica fica ligeiramente atrás, o que preserva o desempenho e admite uma pequena perda em caso de falha. Essa é uma decisão de negócio, tomada com base no que a empresa considera aceitável perder.

Quando o banco é o HANA, existe um agravante prático a considerar: por ser um banco que mantém os dados em memória para responder rápido, subir uma cópia e deixá-la pronta para atender não é instantâneo. Manter a réplica em estado de prontidão, e não apenas recebendo dados, é uma decisão de projeto que afeta diretamente o tempo de retomada. A relação entre esse comportamento e a experiência do usuário está detalhada em SAP Business One na nuvem e performance.

Cluster: a troca automática

Cluster é um conjunto de servidores que se comportam como um serviço só. Quando um componente falha, outro assume o atendimento sem depender de alguém acordar, entender o problema e executar um procedimento.

O que o cluster entrega é redução de tempo de parada por falha de infraestrutura local. O que ele não entrega:

Não protege contra apagar dado por engano.
Não protege contra a perda do local, se todos os nós estiverem no mesmo lugar.
Não corrige problema de aplicação. Se o erro está na configuração ou em um complemento, ele vai junto para o outro nó.
Não elimina a janela de manutenção, embora facilite muito atualizar com menos impacto.

Cluster também tem um custo que não é só de licença e equipamento: ele acrescenta complexidade operacional. Um arranjo automatizado mal configurado consegue causar mais indisponibilidade do que evitaria. Ele faz sentido quando existe quem opere e teste o conjunto com regularidade.

Disaster recovery: o plano, não o equipamento

Disaster recovery costuma ser confundido com um segundo servidor em outro endereço. O servidor é uma parte pequena. O plano é o que importa, e ele responde por escrito a perguntas como:

Quem declara o desastre e a partir de qual critério? Sem essa definição, a empresa perde as primeiras horas discutindo se a situação já se qualifica.
Qual é a ordem de retomada dos sistemas? O ERP normalmente vem cedo, mas depende de rede, identidade e resolução de nomes, que precisam vir antes.
Como os usuários vão acessar o ambiente alternativo, e o que muda para eles?
Como a empresa opera manualmente enquanto o ERP não volta, e como esses registros entram no sistema depois?
Quem comunica clientes, fornecedores e equipe, e com que mensagem?
Como se volta ao ambiente original depois, sem perder o que foi lançado no alternativo? Essa etapa é a mais esquecida dos planos.

Um plano de recuperação que nunca foi ensaiado é uma hipótese. O ensaio é o que transforma promessa em prazo confiável.

RPO e RTO: as duas perguntas que a diretoria precisa responder

Todo o resto decorre daqui. As duas siglas parecem técnicas e são, na verdade, decisões de negócio.

RPO, ou objetivo de ponto de recuperação, é quanto trabalho a empresa aceita perder. Se o backup roda uma vez por dia, de madrugada, e a falha acontece às 17 horas, você perde os lançamentos daquele dia inteiro. Alguém vai precisar refazer notas, pedidos, recebimentos e movimentações. O RPO é a resposta para: quantas horas de digitação a empresa consegue refazer sem prejuízo grave?

RTO, ou objetivo de tempo de recuperação, é quanto tempo a empresa aceita ficar sem o sistema. Conta desde o momento da falha até o ERP estar disponível e confiável para uso, não até o servidor ligar. O RTO é a resposta para: por quanto tempo conseguimos faturar, expedir e atender sem o sistema?

Como chegar a esses números com as áreas

Não pergunte "qual RTO você quer", porque a resposta será sempre zero. Pergunte assim:

O que a sua área deixa de fazer se o ERP parar agora? Emissão de nota, separação de pedido, recebimento de mercadoria, atendimento ao cliente.
Existe um jeito manual de continuar? Por quanto tempo, com quantas pessoas e com qual limite prático?
O que se perde de forma irreversível a cada hora parada? Prazo de entrega, janela de coleta, obrigação com prazo, cliente atendido.
Se perdermos os lançamentos das últimas horas, quem refaz e a partir de qual documento? Se não existe papel nem outro sistema de onde recuperar, o RPO precisa ser curto.
Existe horário em que a parada dói muito mais? Fechamento de mês, pico de expedição e data de obrigação acessória mudam completamente a resposta.

Com essas respostas você constrói uma tabela por processo, e ela deixa evidente onde investir. Normalmente aparece um resultado saudável: nem tudo precisa do mesmo nível de proteção. O banco de dados de produção precisa de um arranjo robusto, enquanto o ambiente de testes pode conviver com uma recuperação mais demorada.

A relação entre RPO, RTO e arranjo técnico

Necessidade do negócio	Arranjo que costuma atender	O que isso exige em contrapartida
Aceita perder algumas horas de lançamento e ficar algumas horas sem sistema	Backup bem feito, com destino isolado e teste periódico de restauração	Um ambiente de destino previamente definido, para não improvisar servidor no dia
Aceita pouca perda de dado, mas precisa voltar mais rápido	Backup somado a replicação do banco para um segundo servidor	Conexão adequada entre os dois lados e procedimento escrito de troca
Não tolera parada perceptível por falha de um servidor	Backup, replicação e automação de troca em conjunto	Maior custo, mais complexidade e disciplina de teste regular
Precisa continuar operando mesmo se o local ficar inacessível	Todo o anterior, com o ambiente alternativo em outro local ou em nuvem	Plano de retomada escrito, ensaio periódico e definição de quem declara o desastre

Repare que cada linha inclui a anterior. Não existe atalho que dispense o backup, e nenhuma camada elimina a necessidade de teste.

O que é específico do SAP Business One

Alguns pontos aparecem em quase todo projeto de disponibilidade de B1 e merecem estar na lista desde o começo:

O ERP não é só o banco. Recuperar o ambiente envolve também o controle de licenças, os serviços auxiliares, os complementos instalados, as integrações com sistemas fiscais e de terceiros e os documentos armazenados fora da base. O plano precisa listar tudo isso, item por item, com o responsável de cada peça.
A parte fiscal tem prazo próprio. Documentos com obrigação de emissão e transmissão não esperam a TI resolver. Vale definir antecipadamente o procedimento de contingência da área fiscal, junto com a contabilidade.
Consistência do banco em memória. Em bancos que operam com os dados em memória, o procedimento de cópia e o de recuperação precisam seguir o método suportado, com os registros de transação incluídos. Improvisar aqui gera cópia que não restaura.
Ambiente de homologação de verdade. Sem um ambiente separado, não há onde ensaiar restauração, testar atualização nem validar mudança antes de aplicar em produção. Ele é parte da estratégia de disponibilidade, não um luxo.
Dimensionamento coerente do destino. Não adianta ter uma cópia se o ambiente alternativo não sustenta a operação real. Os critérios de porte estão descritos em requisitos de servidor para SAP Business One.
Documentação de acesso. Credenciais administrativas em cofre corporativo, com mais de uma pessoa autorizada. Plano perfeito trava quando a senha está com quem não atende o telefone.

O custo de ter o ERP parado

Não vamos apresentar números de mercado, porque o valor depende inteiramente do seu negócio. O que dá para fazer, e é mais útil, é listar os efeitos que costumam ser esquecidos quando se compara o custo de proteger com o custo de parar:

Faturamento represado. O que não foi emitido durante a parada precisa ser emitido depois, e o depois costuma esbarrar em fechamento e em prazo.
Expedição parada. Caminhão parado, janela de entrega perdida e multa contratual em alguns setores.
Recompras e retrabalho. Quando os lançamentos precisam ser refeitos, o custo não é só de horas: é de erro adicional introduzido na pressa.
Hora extra e mutirão de recuperação nos dias seguintes, que quase nunca entram na conta.
Atendimento ao cliente. A equipe não consulta pedido, não confirma prazo e não resolve. O desgaste dura mais que a parada.
Obrigações com prazo, que não são adiadas por indisponibilidade de sistema.
Decisão no escuro. Enquanto o ERP não volta, a empresa opera sem números.

A comparação honesta não é "quanto custa o projeto de disponibilidade". É "quanto custa o projeto" contra "quanto custa um dia parado, multiplicado pela chance de isso acontecer no ano". Esse é exatamente o tipo de decisão que a matriz de riscos torna objetiva, como mostramos em como montar uma matriz de riscos de TI.

Teste: o que precisa ser provado

Toda camada acima vale o que o último teste provou. O mínimo:

Restauração completa em ambiente separado, com periodicidade definida, medindo o tempo real gasto e conferindo se os dados voltaram íntegros. O tempo medido aqui é o seu RTO verdadeiro, não o estimado.
Ensaio de troca para a réplica, com a equipe executando o procedimento escrito, e não a pessoa que montou o ambiente fazendo de memória.
Verificação das dependências: integrações, emissão fiscal, impressão, acesso dos usuários e relatórios. Banco no ar com integração fora do ar ainda é ERP parado.
Registro do resultado, com data, responsável, tempo gasto e o que falhou. A lista do que falhou é o plano de melhoria do próximo ciclo.
Reteste depois de toda mudança relevante de versão, de complemento ou de infraestrutura.

Erros comuns

Achar que replicação dispensa backup. É o erro mais frequente e o mais caro, porque só aparece quando alguém apaga ou corrompe dado.
Manter a cópia no mesmo local, no mesmo armazenamento e com a mesma credencial do ambiente principal.
Nunca ter medido o tempo de recuperação. Prometer um prazo à diretoria sem nunca ter cronometrado é criar uma expectativa que vai ser desmentida no pior dia.
Proteger o banco e esquecer o resto, especialmente anexos, complementos e integrações.
Plano guardado só no ambiente que caiu. Documento de recuperação precisa estar acessível fora do ambiente que ele recupera.
Definir RPO e RTO na TI, sem as áreas. Números definidos sem o negócio não são acordo, são suposição.

Perguntas frequentes

Se o ERP está em nuvem, alta disponibilidade já vem incluída?

Não automaticamente. O provedor cuida da infraestrutura dele, e muitos serviços oferecem recursos de resiliência, mas o que se aplica ao seu ambiente depende do que foi contratado e de como ele foi desenhado. Backup do banco, retenção, cópia isolada, réplica, procedimento de troca e teste de restauração continuam sendo responsabilidade de quem opera o ambiente. Vale ler o contrato com uma pergunta na mão: em caso de perda de dado por erro nosso, o que exatamente o provedor recupera e em quanto tempo?

Vale a pena investir em cluster para uma média empresa?

Depende do RTO acordado com as áreas, e não do tamanho da empresa. Se a operação suporta algumas horas sem o ERP, backup bem feito somado a replicação costuma atender com custo e complexidade bem menores. Se cada hora parada trava expedição e faturamento de forma crítica, a automação de troca passa a se pagar. A pergunta anterior a essa é sempre a mesma: alguém já mediu quanto tempo leva hoje para recuperar o ambiente?

Com que frequência devemos testar a recuperação?

Restauração de banco em ambiente separado deve ser rotina periódica, com registro. O ensaio completo, incluindo integrações, emissão fiscal e acesso de usuário, costuma ser feito com intervalo maior, mas precisa acontecer pelo menos uma vez ao ano e sempre depois de mudança relevante de versão ou de infraestrutura. O critério prático é simples: se ninguém consegue dizer com segurança quanto tempo leva a recuperação, já passou da hora de testar.

Como a BS IT Solutions protege ambientes SAP

A BS IT Solutions desenha a estratégia de disponibilidade do ERP a partir do RPO e do RTO acordados com as áreas de negócio, e não a partir de um catálogo pronto. Isso inclui política de backup com cópia isolada e teste de restauração registrado, replicação quando o tempo de retomada exige, plano de recuperação escrito e ensaiado, e monitoramento contínuo do ambiente pelo NOC 24x7, para que a falha seja detectada antes do usuário perceber. Nossa liderança é especializada em SAP Business One, HANA e Basis, com atendimento presencial em São Paulo e região metropolitana e remoto em todo o Brasil, dentro do serviço de infraestrutura SAP.

Fale com um especialista da BS IT Solutions e descubra, com número medido em vez de estimativa, quanto tempo o seu ERP levaria para voltar hoje.