Failover: O Que É, Tipos e Como Funciona na Prática
Quando um servidor crítico falha, cada minuto conta. Failover é o mecanismo que transfere automaticamente a operação para um sistema de backup — sem intervenção manual e, idealmente, sem que os usuários percebam. Entenda os tipos, como funciona e como implementar.
Pontos-Chave deste Artigo
- Failover transfere a operação para um sistema de backup quando o principal falha
- Tipos: automático (cluster, 30s-5min), DNS (5-30min), manual (15-60min), DRaaS (15-30min)
- Failover ≠ Disaster Recovery — failover é um mecanismo; DR é a estratégia completa
- Justifica-se quando o custo do downtime supera o investimento em redundância
O Que é Failover
Failover é o mecanismo que transfere automaticamente a operação de um sistema que falhou para um sistema redundante. Quando o servidor principal de e-mail cai, o servidor de failover assume. Quando o banco de dados primário para, a réplica assume. Os usuários podem nem perceber que houve uma troca.
O termo vem do inglês: "fail" (falhar) + "over" (passar para). Literalmente: "quando falhar, passar para outro".
Failover vs Failback
| Conceito | Definição | Quando Acontece |
|---|---|---|
| Failover | Transferir operação do primário para o secundário | Quando o sistema principal falha |
| Failback | Transferir operação de volta para o primário | Quando o sistema principal é reparado |
O failback é tão importante quanto o failover. Sem failback planejado, a empresa fica rodando indefinidamente no sistema secundário — que pode ter limitações de performance, capacidade ou localização.
Tipos de Failover
1. Failover Automático (Cluster)
O tipo mais rápido. Dois ou mais servidores formam um cluster de alta disponibilidade. Um mecanismo de heartbeat monitora constantemente se o nó primário está respondendo. Se detectar falha, o cluster promove automaticamente o nó secundário — sem intervenção humana.
Tecnologias:
- Windows Server Failover Cluster (WSFC): para SQL Server, Hyper-V, File Server, Exchange
- VMware vSphere HA: reinicia VMs em outro host se o host original falhar
- Proxmox HA: similar ao VMware HA para ambiente open source
- Linux Pacemaker/Corosync: cluster HA para serviços Linux (PostgreSQL, MySQL, Apache)
Tempo de failover: 30 segundos a 5 minutos
Custo: Alto (hardware duplicado + licenças cluster)
Quando usar: Servidores críticos com RTO < 5 minutos
2. Failover DNS
O DNS que aponta para o servidor principal é atualizado para apontar para o servidor de backup. Pode ser automático (DNS health check) ou manual (alterar registro). O tempo de propagação depende do TTL (Time to Live) configurado no DNS.
Tempo de failover: 5 a 30 minutos (depende do TTL)
Custo: Baixo (não requer cluster, apenas DNS e servidor de backup)
Quando usar: Sites, APIs, serviços web com RTO de 15-30 minutos
3. Failover Manual
Um técnico identifica a falha, toma a decisão e executa o procedimento de troca manualmente. Mais lento, mas às vezes necessário quando a decisão de failover requer análise humana (ex: falha intermitente que pode se resolver sozinha).
Tempo de failover: 15 a 60+ minutos
Custo: Baixo (operacional)
Quando usar: Sistemas com RTO tolerante (4-8h), quando failover automático não justifica o custo
4. Failover na Nuvem (DRaaS)
O servidor de backup fica na nuvem, mantido como réplica ou backup. Quando o servidor on-premise falha, a réplica na nuvem é ativada. Com tecnologia Run Direct, a VM pode ser iniciada diretamente a partir do backup — sem esperar restauração completa.
Tempo de failover: 15 a 30 minutos (Run Direct)
Custo: Moderado (assinatura DRaaS)
Quando usar: PMEs que precisam de failover mas não podem duplicar hardware on-premise
Comparativo Completo: Hot, Warm e Cold Standby
Além de classificar failover por mecanismo (cluster, DNS, manual, DRaaS), existe uma classificação igualmente importante baseada no nível de prontidão do sistema de backup. Entender essa diferença é essencial para dimensionar investimento e expectativa de RTO.
| Característica | Hot Standby | Warm Standby | Cold Standby |
|---|---|---|---|
| Estado do sistema secundário | Ligado, sincronizado em tempo real | Ligado, sincronizado periodicamente | Desligado, precisa ser iniciado |
| Sincronização de dados | Contínua (replicação síncrona) | Periódica (a cada minutos/horas) | Manual ou via restore de backup |
| RTO típico | Segundos a 2 minutos | 5 a 30 minutos | 1 a 8+ horas |
| RPO típico | Zero (sem perda de dados) | Minutos a horas | Horas a 24h (último backup) |
| Custo | Muito alto (hardware idêntico + licenças) | Moderado | Baixo |
| Complexidade | Alta | Média | Baixa |
| Exemplo de tecnologia | SQL Server Always On, VMware FT | VMware HA, DRaaS com Run Direct | Bare-metal recovery a partir de backup |
| Ideal para | Bancos, fintechs, e-commerce 24/7 | ERP, e-mail, sistemas críticos | Sistemas internos, contingência |
A escolha entre hot, warm e cold depende diretamente do custo do downtime. Se cada hora parada custa R$ 100.000 (como em fintechs), hot standby se paga. Se custa R$ 5.000, warm ou cold pode ser suficiente. A DataBackup oferece DRaaS que funciona como warm standby — combinando custo acessível com RTO de 15-30 minutos via Run Direct.
Comparativo dos Tipos de Failover por Mecanismo
| Tipo | Tempo de Troca | Automático? | Custo | Complexidade | Ideal Para |
|---|---|---|---|---|---|
| Cluster HA | 30s — 5 min | Sim | Alto | Alta | Bancos de dados, ERP, e-mail (enterprise) |
| DNS failover | 5 — 30 min | Semi | Baixo | Média | Sites, APIs, serviços web |
| Manual | 15 — 60 min | Não | Baixo | Baixa | Sistemas não-críticos, contingência |
| DRaaS (Run Direct) | 15 — 30 min | Semi | Moderado | Baixa | PMEs, servidores on-premise sem redundância |
O Processo Completo: Failover e Failback Passo a Passo
Failover e failback não são eventos isolados — são processos complementares que precisam ser planejados, testados e documentados juntos. Um failover perfeito sem failback planejado deixa a empresa operando indefinidamente no sistema secundário, consumindo recursos de contingência e sem capacidade de responder a um segundo incidente.
Etapas do Failover
- Detecção da falha: o mecanismo de monitoramento (heartbeat, health check, alerta manual) identifica que o sistema primário parou de responder. A detecção pode ser automática (cluster HA) ou manual (equipe de TI percebe a indisponibilidade)
- Validação: antes de acionar o failover, o sistema valida que a falha é real — não apenas um pico de latência ou falha de rede temporária. Em clusters, isso envolve múltiplas verificações de heartbeat com timeout configurável
- Ativação do secundário: o sistema de backup assume a operação. Em hot standby, isso é instantâneo. Em warm standby (como DRaaS com Run Direct), envolve iniciar a VM a partir do backup
- Redirecionamento de tráfego: DNS, balanceador de carga ou IP flutuante (VIP) é atualizado para apontar para o sistema secundário. Os usuários passam a acessar o novo servidor
- Verificação pós-failover: a equipe confirma que o sistema secundário está operando corretamente — aplicações respondendo, dados consistentes, performance aceitável
Etapas do Failback
- Reparo do sistema primário: o servidor original é consertado, reinstalado ou substituído. Pode envolver bare-metal recovery se o hardware foi trocado
- Sincronização de dados: todos os dados criados ou modificados durante o período de failover precisam ser sincronizados de volta para o sistema primário. Esse é o passo mais crítico e mais demorado
- Validação de integridade: verificar que o sistema primário restaurado possui dados íntegros e aplicações funcionais. Testar antes de redirecionar o tráfego
- Janela de manutenção: agendar o failback para horário de baixo uso. O failback pode causar breve indisponibilidade durante a troca
- Redirecionamento para o primário: DNS, VIP ou balanceador é atualizado novamente para apontar para o sistema primário
- Monitoramento intensivo: nas primeiras 24-48 horas após o failback, monitorar de perto o sistema primário para garantir estabilidade
Failover e Failback: Erros Comuns
| Erro | Consequência | Prevenção |
|---|---|---|
| Não testar o failover | Failover falha quando realmente precisa funcionar | Testes trimestrais em ambiente isolado |
| Ignorar o failback | Empresa fica no sistema secundário por meses | Documentar e testar failback junto com failover |
| Sincronização incompleta | Perda de dados criados durante o período de failover | Replicação contínua ou incremental antes do failback |
| Split-brain em cluster | Dois nós acreditam ser o primário simultaneamente | Quorum configurado corretamente, STONITH/fencing |
| TTL DNS muito alto | Failover DNS demora mais do que o esperado | Manter TTL baixo (60-300 segundos) em registros críticos |
Failover vs Disaster Recovery vs Backup
Esses três conceitos são frequentemente confundidos. Cada um resolve um problema diferente:
| Conceito | Resolve | Tempo de Recuperação | Exemplo |
|---|---|---|---|
| Failover | Manter serviço disponível durante falha | Segundos a minutos | Servidor de BD cai → réplica assume |
| Disaster Recovery | Recuperar operação após desastre | Minutos a horas | Data center inundado → ativar DR na nuvem |
| Backup | Recuperar dados perdidos ou corrompidos | Horas a dias | Ransomware criptografou → restaurar do backup |
Failover é um mecanismo técnico. Disaster Recovery é uma estratégia que pode incluir failover. Backup é a proteção de dados que sustenta ambos. A proteção completa precisa dos três.
Failover por Tipo de Infraestrutura
Cada tipo de infraestrutura tem suas particularidades para implementar failover. A tabela abaixo detalha as opções por ambiente:
| Infraestrutura | Tecnologia de Failover | RTO Típico | Complexidade | Observações |
|---|---|---|---|---|
| VMware vSphere | vSphere HA, vSphere FT, vMotion | 30s — 5 min (HA), 0s (FT) | Média-Alta | FT = zero downtime mas alto custo de recursos (CPU/RAM duplicados) |
| Hyper-V | WSFC, Hyper-V Replica, Live Migration | 30s — 5 min | Média | Hyper-V Replica é warm standby nativo e gratuito |
| Proxmox | Proxmox HA, ZFS replication, Ceph | 1 — 5 min | Média | Open source, sem custo de licença; Ceph para storage distribuído |
| Servidor físico Windows | WSFC, DRaaS com Run Direct | 2 — 30 min | Média-Alta | WSFC requer edição Datacenter ou Standard; DRaaS como alternativa acessível |
| Servidor físico Linux | Pacemaker/Corosync, DRBD, DRaaS | 1 — 10 min | Alta | Configuração manual; DRBD para replicação de bloco em tempo real |
| Banco de dados SQL Server | Always On AG, FCI, Log Shipping | 0s (AG síncrono) — 15 min (Log Shipping) | Alta | Always On AG é o padrão enterprise; requer licenciamento específico |
| Banco de dados PostgreSQL | Streaming Replication, Patroni, pgBouncer | 5 — 30s | Média | Patroni automatiza failover; pgBouncer faz redirecionamento transparente |
| Nuvem (AWS/Azure/GCP) | Auto Scaling Groups, Availability Zones, Site Recovery | Segundos — 5 min | Baixa-Média | Nativo das plataformas cloud; custo baseado em uso |
Para PMEs que operam com servidores físicos ou virtualizados on-premise, o DRaaS da DataBackup é frequentemente a opção mais prática: não exige hardware duplicado local, funciona tanto com ambientes VMware, Hyper-V e Proxmox quanto com servidores Windows e Linux físicos, e oferece RTO de 15-30 minutos via Run Direct.
Arquitetura de Failover: Como Funciona na Prática
A arquitetura de failover varia conforme o tipo, mas todos seguem os mesmos princípios fundamentais: monitoramento contínuo, detecção de falha, ativação do secundário e redirecionamento de tráfego. Abaixo, detalhamos as três arquiteturas mais comuns em ambientes empresariais.
Arquitetura 1: Cluster HA (Active-Passive)
Dois servidores compartilham um storage (SAN/NAS) ou usam replicação de bloco. O nó ativo processa todas as requisições. O nó passivo monitora via heartbeat. Quando o heartbeat falha, o nó passivo assume o IP flutuante (VIP) e inicia os serviços.
- Componentes: 2+ servidores, storage compartilhado ou replicado, rede heartbeat dedicada, IP flutuante
- Monitoramento: heartbeat a cada 1-5 segundos entre os nós
- Decisão: quorum (votação) para evitar split-brain — requer número ímpar de nós ou witness disk
- Troca: IP flutuante migra para o nó sobrevivente, serviços são iniciados automaticamente
Arquitetura 2: Active-Active (Load Balanced)
Ambos os servidores estão ativos simultaneamente, dividindo a carga via balanceador. Se um servidor falha, o balanceador redireciona todo o tráfego para o servidor restante. Não há "troca" — apenas redistribuição.
- Componentes: 2+ servidores, balanceador de carga (hardware ou software), dados sincronizados
- Vantagem: melhor uso de recursos (ambos os servidores trabalham) e failover mais rápido
- Desvantagem: mais complexo — requer aplicação stateless ou sessões compartilhadas
- Ideal para: servidores web, APIs, microsserviços
Arquitetura 3: DRaaS (On-Premise para Nuvem)
O servidor de produção roda on-premise. O backup corporativo é enviado para a nuvem diariamente (ou com maior frequência). Quando o servidor on-premise falha, a VM é iniciada diretamente a partir do backup na nuvem via Run Direct — sem esperar restauração completa.
- Componentes: servidor on-premise, agente de backup, storage na nuvem, orquestrador DRaaS
- Monitoramento: alerta manual ou automatizado quando o servidor on-premise fica indisponível
- Ativação: operador aciona Run Direct no painel; VM inicia em 15-30 minutos
- Failback: após reparo do servidor on-premise, dados são sincronizados da nuvem de volta via Live VM Migration
Procedimentos de Teste de Failover
Failover que não é testado é failover que provavelmente não funciona. Pesquisas mostram que mais de 30% dos failovers falham na primeira tentativa real quando nunca foram testados. Um plano de teste estruturado é obrigatório para qualquer ambiente com requisitos de alta disponibilidade.
Checklist de Teste de Failover
- Definir escopo: quais sistemas serão testados (BD, aplicação, rede, storage)?
- Agendar janela: horário de baixo uso ou ambiente isolado (sandbox)
- Notificar stakeholders: equipe de TI, gestores, usuários afetados
- Documentar estado inicial: registrar status de todos os componentes antes do teste
- Simular falha: desligar servidor primário, desconectar rede, ou parar serviço
- Medir RTO real: cronometrar o tempo até o sistema secundário estar 100% operacional
- Validar funcionalidade: testar todas as aplicações críticas no sistema secundário
- Verificar dados: confirmar que dados estão íntegros e atualizados no sistema de failover
- Testar failback: reativar o sistema primário e verificar sincronização reversa
- Documentar resultados: registrar RTO alcançado, problemas encontrados, ações corretivas
Frequência Recomendada de Testes
| Tipo de Teste | Frequência | Descrição |
|---|---|---|
| Teste tabletop | Mensal | Simulação em mesa — equipe percorre o procedimento sem executar ações reais |
| Teste parcial (sandbox) | Trimestral | Failover executado em ambiente isolado, sem impacto em produção |
| Teste completo | Semestral | Failover real em produção, durante janela de manutenção agendada |
| Teste não anunciado | Anual | Simulação de falha real sem aviso prévio à equipe operacional — mede resposta real |
A DataBackup oferece Restore Drill — testes de restauração automatizados que validam a integridade dos backups e medem o RTO real sem impactar a produção. O teste inicia a VM de failover em ambiente isolado, executa verificações de integridade e gera relatório. Ideal para empresas que precisam comprovar compliance com LGPD e ISO 27001.
Quando Failover se Justifica
Failover requer investimento: hardware redundante, licenças, configuração e manutenção. Para justificar, calcule:
Se (custo do downtime/hora × horas de RTO sem failover) > custo anual do failover → compensa.
| Cenário | Custo Downtime/Hora | RTO sem Failover | Prejuízo por Incidente | Failover Justifica? |
|---|---|---|---|---|
| E-commerce | R$ 50.000 | 4-8h (restore) | R$ 200.000-400.000 | Sim |
| Fintech | R$ 100.000+ | 4-8h | R$ 400.000+ | Sim |
| ERP (indústria) | R$ 30.000 | 8-24h | R$ 240.000-720.000 | Sim |
| File server (escritório) | R$ 5.000 | 4-8h | R$ 20.000-40.000 | Depende da frequência |
| Sistema interno não-crítico | R$ 1.000 | 24h | R$ 24.000 | Provavelmente não |
Cenários Reais: Quando o Failover Salva a Operação
Para entender o valor do failover na prática, veja cenários baseados em padrões documentados de incidentes em empresas brasileiras:
Cenário 1: Falha de Hardware em Servidor de ERP
Uma indústria de médio porte com 200 funcionários opera um ERP que centraliza produção, estoque, faturamento e fiscal. O servidor do banco de dados sofre falha de controladora RAID na segunda-feira às 9h.
- Sem failover: equipe de TI aciona garantia do fabricante. Peça chega em 24-48h. Restauração do backup leva mais 4-8h. Total: 2-3 dias parados. Prejuízo estimado: R$ 180.000 (produção parada, pedidos não faturados, multas de entrega).
- Com DRaaS (Run Direct): às 9h20, operador aciona Run Direct no painel da DataBackup. Às 9h45, VM do servidor de BD está operando na nuvem. ERP volta a funcionar em 45 minutos. Quando o hardware é reparado, failback sincroniza os dados de volta. Prejuízo: R$ 2.500 (45 minutos parado).
Cenário 2: Ransomware em Escritório de Contabilidade
Um escritório contábil com 50 clientes é atingido por ransomware LockBit em período de entrega de declarações fiscais. Todos os servidores e estações são criptografados.
- Sem failover (mas com backup imutável): restauração do backup imutável leva 8-12h para o servidor principal. Mais 2-4h para estações. Total: 12-16h de downtime.
- Com DRaaS + backup imutável: servidor principal ativado via Run Direct em 30 minutos. Estações acessam via RDP temporário. Operação retomada em 1 hora. Restauração completa (failback) feita no fim de semana, sem impacto.
Cenário 3: Desastre Físico em Data Center Local
Uma empresa de e-commerce opera um data center próprio em São Paulo. Uma enchente compromete o andar térreo onde ficam os servidores.
- Sem DR na nuvem: todos os servidores destruídos. Backup local inacessível. Se havia backup offsite em fitas, restauração leva 3-7 dias após adquirir novo hardware. Muitas empresas não sobrevivem.
- Com DRaaS na nuvem: servidores ativados na nuvem em 30-60 minutos. Site volta ao ar, pedidos continuam processando. Novo hardware é adquirido com calma, failback feito quando conveniente.
Failover e Compliance: LGPD, ISO 27001 e Regulações Setoriais
Ter failover não é apenas uma decisão operacional — para muitos setores, é uma exigência regulatória. A capacidade de manter serviços disponíveis e dados acessíveis está diretamente ligada a requisitos de compliance:
| Regulação | Requisito Relevante | Como o Failover Atende |
|---|---|---|
| LGPD | Art. 46 — medidas técnicas de segurança para proteção de dados pessoais | Failover garante disponibilidade contínua dos dados pessoais e reduz risco de perda |
| ISO 27001 | Controle A.17 — continuidade da segurança da informação | Failover é componente essencial do plano de continuidade de negócios |
| Bacen (Resolução 4.893) | Política de segurança cibernética para instituições financeiras | Exige plano de continuidade com testes periódicos — failover é pilar central |
| CFM/ANS (Saúde) | Disponibilidade de prontuários eletrônicos e sistemas hospitalares | Failover garante acesso contínuo a sistemas clínicos críticos |
| SOC 2 Type II | Critério de disponibilidade — uptime e recuperação documentados | Failover + testes documentados atendem ao critério de disponibilidade |
A DataBackup fornece relatórios de Restore Drill que documentam testes de failover, RTO alcançado e integridade dos dados — artefatos essenciais para auditorias de compliance. Consulte nosso guia de LGPD e backup para mais detalhes.
Como a DataBackup Implementa Failover
Para PMEs que precisam de failover sem o custo e complexidade de clusters on-premise, a DataBackup oferece DRaaS (Disaster Recovery as a Service):
- Run Direct: inicia a VM diretamente a partir do backup na nuvem em 15-30 minutos — sem esperar restauração completa
- Live VM Migration: após o Run Direct, a VM migra para o ambiente definitivo enquanto continua operando
- Failback automatizado: quando o servidor on-premise é reparado, os dados são sincronizados de volta e a operação retorna
- Backup imutável: garante que o backup usado no failover está íntegro — ransomware não pode corromper
- Teste de failover sem impacto: teste o DR em ambiente isolado, sem afetar produção
- Suporte a múltiplas plataformas: VMware, Hyper-V, Proxmox, Windows Server e Linux físico
- Relatórios de compliance: documentação de testes para LGPD, ISO 27001 e auditorias
Tudo isso integrado ao backup corporativo — não precisa de produto separado. O mesmo agente que faz backup diário mantém os dados prontos para failover. A partir de R$ 159,90/mês. Teste grátis 14 dias.
A DataBackup oferece DRaaS com Run Direct: sua VM inicia diretamente do backup em 15-30 minutos. Failover, failback e teste de DR integrados ao backup corporativo. Teste 14 dias grátis.
Proteger Minha Empresa Falar com Especialista