Recuperação de desastres para SAP em IBM i: lições de um failover real

Pela equipe de Infraestrutura da Redsis · Outubro de 2026 · 6 min de leitura

Por que a continuidade pesa tanto no varejo

O varejo colombiano é um setor grande e concentrado: as 20 maiores empresas somaram receitas de 117,3 trilhões de pesos em 2025, com crescimento de 12,3 %, e as cinco primeiras concentraram 65,2 % dessas receitas, segundo o El Colombiano. Nesse nível de escala, cada hora de sistemas parados se mede em vendas, em pedidos que não saem para os fornecedores e em clientes que vão para a concorrência.

A rede do nosso caso opera cerca de 420 lojas, aproximadamente 4.800 pontos de venda e perto de 8.000 usuários de SAP, além de mais de 200 bases de dados SQL Server em torno do core. Uma contingência no seu data center principal não é um problema de TI: é um problema de todo o negócio.

RTO e RPO: os dois números que importam

Toda estratégia de recuperação se resume a dois objetivos que o negócio deve definir e a tecnologia deve cumprir:

• RTO (Recovery Time Objective): quanto tempo o sistema pode ficar parado antes de voltar a operar. Neste caso, 3 horas para o core SAP diante de uma contingência maior.
• RPO (Recovery Point Objective): quanta informação se pode perder, medida em tempo. Neste caso, uma janela máxima de 15 minutos na replicação.

Com 80 TB de dados, esses números são muito difíceis de alcançar apenas com backups tradicionais: restaurar um volume assim a partir de cópias periódicas costuma levar bem mais que algumas horas, e a perda pode ser de tudo o que ocorreu desde a última cópia. A única forma de alcançá-los é manter uma réplica viva do ambiente em outro site.

Como funciona o IBM PowerHA para IBM i

O IBM PowerHA é a solução de alta disponibilidade e recuperação de desastres da IBM para a plataforma Power. No IBM i, integra-se de forma nativa com o sistema operacional e oferece:

• Clusters entre sites que agrupam os sistemas do data center principal e do alternativo como uma única solução.
• Replicação contínua de dados , seja no nível do sistema operacional, seja apoiada na replicação do armazenamento, conforme o projeto.
• Comutação controlada ( switchover ) para testes planejados e comutação por falha ( failover ) diante de uma contingência real.
• Domínio administrativo que mantém sincronizados perfis de usuário, configurações e objetos do sistema entre os nós, para que o site alternativo esteja pronto para operar.

Neste projeto, os 80 TB de SAP são replicados entre duas cidades e a Redsis administra a infraestrutura IBM Power nos dois data centers.

Cinco lições de mais de três anos em operação

1. Que o negócio defina o RTO e o RPO

Os números de recuperação não são um parâmetro técnico: são uma decisão de negócio sobre quanto tempo e quanta informação se pode perder. Quando é a operação que os define, a arquitetura é projetada para cumpri-los, e não o contrário.

2. A distância faz parte do projeto

Um site alternativo na mesma cidade protege contra uma falha de equipamentos, mas não contra um evento regional. Levar a réplica para outra cidade amplia a proteção, em troca de projetar com cuidado os enlaces, a latência e o modo de replicação.

3. Testar, testar e testar de novo

A solução deste caso é testada de forma contínua, e em julho de 2026 foi executado um failover real. Essa é a diferença entre acreditar que o plano funciona e saber que funciona. Uma prática recomendável é alternar testes planejados com exercícios o mais parecidos possível com uma contingência real.

4. Olhar além do core

O SAP é o coração, mas não está sozinho: pontos de venda, integrações e bases de dados satélite também precisam voltar. Documentar a ordem de recuperação de todo o ecossistema evita que o core esteja disponível enquanto as lojas seguem sem poder vender.

5. Operar a alta disponibilidade como um serviço

A replicação se degrada se ninguém a vigia: mudanças de configuração, crescimento de dados ou atualizações podem quebrá-la em silêncio. Contar com uma equipe que administra a infraestrutura nos dois sites, como faz a Redsis neste caso, mantém a solução pronta para o dia em que for necessária.

O resultado: continuidade demonstrada, não prometida

Hoje o core SAP da rede tem um tempo de recuperação de 3 horas e uma janela máxima de perda de dados de 15 minutos, sobre uma solução que está há mais de três anos em operação e que já demonstrou o seu valor num failover real em julho de 2026. Para uma operação de 420 lojas e 4.800 pontos de venda, isso significa algo muito concreto: diante de uma contingência maior, o negócio sabe quanto tempo leva para voltar e quanto pode perder.

Por onde começar?

Se a sua organização não tem claros os seus números de RTO e RPO, ou se o seu plano de contingência não foi testado no último ano, vale a pena começar por um diagnóstico de continuidade. Na Redsis combinamos mais de 25 anos de experiência em infraestrutura de missão crítica na América Latina com a nossa condição de parceira IBM Platinum para projetar, implantar e operar alta disponibilidade sobre IBM Power e IBM i.