Plano de Recuperação de Desastres para SAP

Como o SAP frequentemente forma um dos componentes mais importantes do fluxo de dados dentro de uma organização, o plano de recuperação de desastres para SAP sempre deve ser uma das principais prioridades para todas as partes interessadas. Existe uma grande variedade de desastres diferentes que podem acontecer de repente, desde danos irreparáveis aos seus dados, até perdas comerciais completas. Nesse contexto, se você não estiver preparado, isso lhe custará muito caro. Quase cada minuto de inatividade é um desastre para uma empresa, e cada hora adicional pode chegar a milhares de reais (ou mais) de custo adicional.

É por isso que as empresas precisam estar sempre prontas e capazes de minimizar ao máximo o possível o tempo de paralisação. Há alguns termos importantes para isso, tais como RTO e RPO.

RTO significa “recovery time objective”, ou “objetivo de tempo de recuperação”. Ele representa a quantidade de tempo que os sistemas SAP da sua empresa pode ficar offline sem afetá-la. Não importa o tipo exato de desastre que ocorreu: falha de rede, falta de energia, um furacão, etc. O fato é que você vai querer seu banco de dados SAP ou HANA de volta, funcionando, dentro do período “permitido”, e é exatamente isso que RTO significa.

Agora, existem muitos ativos e/ou serviços diferentes que podem se envolver ou ser afetados por um desastre, e cada um deles tem um RTO diferente. Por exemplo, sistemas bancários ou lojas online de alta demanda medem seu RTO em segundos, enquanto um RTO de empresas menos relevantes em termos de tempo poderia chegar a vários dias. É claro que também há muitos casos diferentes entre esses exemplos.

O RPO significa “recovery point objective”, ou “objetivo de ponto de recuperação”, e provavelmente também será um fator importante do seu plano de recuperação de desastres para SAP. O RPO representa a quantidade máxima de dados (medida em termos da idade dos dados) que podem ou não ser perdidos no caso de um desastre. Basicamente, algum tipo de perda de dados é quase inevitável, a menos que você esteja espelhando todo o seu banco de dados o tempo todo. É aqui que o RPO é importante. O que é tolerável para o seu negócio? Assim como o RTO, seu RPO varia muito, dependendo da natureza de seu negócio. Por exemplo, os negócios de ações podem ter um RPO extremamente sensível, enquanto outros negócios podem ter RPO muito maiores.

Falando de planos de recuperação de desastres, há vários tipos desses planos por aí, cada um com seus próprios recursos e deficiências:

• Método tradicional de recuperação de dados. O próprio nome dá a entender que esse é provavelmente o método mais antigo que existe. Nesse caso, são usados dois servidores idênticos, o “principal” e o “reserva”. Os logs do banco de dados são coletados do “principal” e enviados para o “reserva”. Esse método tem muitos inconvenientes, sendo o principal deles a velocidade de funcionamento e o custo total de propriedade. No entanto, muitas empresas ainda o usam como opção primária.
• Uso de serviços de nuvem para backup e recuperação de dados. Essa opção também poderia ser chamada de “econômica”, já que o custo total do uso dos serviços da Amazon Web Services ou similares não é tão grande assim, e pode ser arcado por empresas menores. Os serviços em nuvem são usados principalmente por empresas que não têm muitas mudanças frequentes em seu banco de dados, e os dados em si são copiados de vez em quando. Pode ser de fato uma boa opção para empresas iniciantes, mas preocupações gerais com a segurança fazem dela uma escolha difícil para empresas maiores com dados mais sensíveis.