Failover é o momento em que sua operação deixa de rodar no ambiente principal e passa a rodar no secundário. Parece um botão. Na prática, é uma sequência de decisões que precisam estar tomadas antes do desastre — porque durante o desastre ninguém tem tempo de decidir.
O que failover realmente significa
Imagine que o storage principal do seu data center falha às 14h de uma terça-feira. O backup está íntegro, o ambiente secundário está replicado. A pergunta que decide se você volta em 15 minutos ou em 8 horas não é técnica: é quem tem autoridade para declarar o desastre.
Failover é a transição da carga de trabalho do ambiente primário para o secundário. Failback é o retorno depois que o primário é restaurado. As duas operações têm riscos diferentes, e a segunda é a que mais gente esquece de testar.
Failover manual, assistido e automático
Manual
Uma pessoa executa um procedimento documentado. É o modelo mais comum e o mais lento. Funciona quando o RTO tolerado é de horas e quando existe alguém de plantão que conhece o procedimento — duas condições que costumam ser assumidas sem verificação.
Assistido
A detecção é automática, a execução depende de aprovação humana. Reduz o tempo de decisão sem abrir mão do julgamento. Para a maioria das empresas de médio porte, é o ponto de equilíbrio: evita failover acidental e ainda corta o tempo de reação.
Automático
Detecção e execução sem intervenção. Entrega o menor RTO possível e traz o risco que ninguém gosta de discutir: o split-brain.
Split-brain: o problema que o failover automático cria
Split-brain acontece quando o ambiente secundário assume a operação enquanto o primário ainda está de pé — normalmente porque o que caiu foi o link entre os dois, não o primário em si. O resultado são dois ambientes gravando dados divergentes ao mesmo tempo.
Recuperar disso é pior que o desastre original. Você não perdeu dados: você tem duas versões conflitantes e nenhuma forma automática de decidir qual vale. É por isso que failover automático exige um mecanismo de quórum — uma terceira testemunha que decide quem manda quando os dois se acham vivos.
O que testar, e o que quase ninguém testa
- Failover completo: subir o ambiente secundário e rodar a operação real nele, não só verificar se ele liga.
- Failback: voltar para o primário sincronizando os dados gerados durante a contingência. É aqui que a maioria dos planos falha.
- Dependências externas: DNS, integrações de terceiros, licenças amarradas a MAC ou endereço IP, certificados. O ambiente sobe e a aplicação não conecta.
- Autoridade de decisão: quem declara o desastre às 3h da manhã de um domingo, e qual é o caminho de escalonamento se essa pessoa não responder.
A relação com RPO e RTO
O modelo de failover que você escolhe é consequência do RTO, não uma decisão separada. RTO de minutos não se atinge com procedimento manual em PDF. RTO de um dia útil não justifica o custo e o risco de automação com quórum.
Defina primeiro quanto tempo a operação pode parar e quanto dado pode ser perdido. O modelo de failover cai por gravidade depois disso.
Onde começar
O DR Ativo e o DR PureSync da Adentro cobrem cenários diferentes de failover. Mas a escolha do produto é o segundo passo: o primeiro é definir qual RTO sua operação realmente exige. Fale com nosso time técnico para dimensionar isso antes de comparar soluções.