Melhores práticas para a recuperação de desastres em ambientes SAP: Backups, alta disponibilidade e muito mais

Há alguns anos, eu estava sentado em meu escritório tomando um café (é claro, Death Wish dark roast) quando recebi uma ligação frenética de nossa equipe do centro de dados. Uma enorme sobretensão em um transformador próximo havia deixado nosso ambiente SAP à beira do colapso.

A corrida frenética para iniciar nosso plano de recuperação de desastres foi um alerta. Acontece quando menos esperamos.

Embora não gostemos de pensar muito nisso, um desastre pode (e provavelmente irá) destruir seu árduo trabalho, colocar em risco funções-chave e ameaçar toda a sua infraestrutura. Opere o software empresarial tempo suficiente e algo ameaçará sua segurança.

Mas mesmo que Humpty Dumpty caia do muro, ainda podemos colocá-lo de volta no lugar.

A recuperação de desastres envolve aceitar certa quantidade de perda de dados, mas reduzir seu RTO tanto quanto possível (ou pelo menos para algo com o qual você possa viver).

Ao longo dos anos, desenvolvi algumas melhores práticas que ajudarão a colocar os aplicativos SAP em funcionamento após o proverbial terremoto.

Backup e restauração em vários níveis

Juntamente com backups regulares, mantive soluções de backup em vários níveis. Por exemplo, há uma estratégia de backup incremental diário e backup completo semanal que mantém os dados tanto localmente quanto em armazenamento na nuvem para redundância.

Automatize o processo de backup com scripts que iniciam um backup no SAP HANA usando Backint e em seguida transferem os arquivos de backup para uma localização externa na nuvem com versionamento habilitado.

Programe um script tão simples como:

E então transfira-os usando algo como AWS CLI ou Azure Blog Storage:

Alta disponibilidade e configuração de recuperação de desastres

Configurei uma combinação de HA e DR dentro de meu ambiente SAP. HA no site principal garante um tempo de inatividade mínimo, enquanto o site secundário está pronto para assumir em caso de falha.

A replicação síncrona ou assíncrona para um site de failover em uma localização diferente (na mesma região) pode ser usada, dependendo dos requisitos comerciais e da tolerância à perda de dados.

No sistema principal:

No sistema secundário:

Se seu RPO for relativamente alto, você pode dispensar um servidor de failover terciário, mas se não puder lidar com muita perda de dados, é melhor ter esse host de DR dedicado.

Envio de logs de banco de dados

Enviar regularmente logs de transações para uma localização externa ajuda a recuperar sistemas para um ponto mais próximo da falha. Esta abordagem me ajudou a recuperar a última transação confirmada, essencialmente uma cópia completa dos dados antes da falha.

Um servidor Microsoft SQL pode enviar continuamente logs para um servidor em standby, que pode então ser ativado em caso de falha.

Em seguida, para restaurá-lo no servidor standby:

Virtualização e snapshots

Utilizei snapshots de VM para habilitar pontos de restauração que poderiam ser rapidamente iniciados em novo hardware ou em um ambiente na nuvem após uma falha do servidor físico. O vSphere da VMware é excelente para isso, capturando automaticamente estados de servidor consistentes.

É tão simples como:

Standby quente

Às vezes, você precisa ter um sistema standby atualizado regularmente usando replicação de sistemas ou backups. Embora não lide com a carga de produção, está pronto para ser ativado e colocar em funcionamento seu site.