Backup e Continuidade de Negócio (BCDR)
BCDR junta duas disciplinas complementares: Business Continuity Planning (BCP) — como a empresa continua operando durante uma crise — e Disaster Recovery (DR) — como os sistemas de TI são restaurados depois de um desastre. Já vimos backup do ponto de vista pessoal (Aula 4); agora vamos ver como isso escala para uma organização inteira.
🎯 O que você vai aprender
- RTO e RPO: as duas métricas que definem qualquer plano de recuperação
- O que é uma Análise de Impacto no Negócio (BIA)
- Estratégias comuns de disaster recovery (hot/warm/cold site)
- Por que testar o plano é tão importante quanto ter um
RTO e RPO
- RTO (Recovery Time Objective): quanto tempo a operação pode ficar parada até ser restaurada, antes que o impacto se torne inaceitável. "Nosso sistema de vendas precisa voltar em até 4 horas."
- RPO (Recovery Point Objective): quantos dados a empresa pode se dar ao luxo de perder, medido em tempo. "Podemos perder no máximo 1 hora de transações" significa que backups precisam rodar pelo menos a cada hora.
Essas duas métricas, definidas junto com as áreas de negócio (não só pela TI), guiam todo o desenho técnico da solução de backup e recuperação — quanto mais agressivos os objetivos, mais caro e complexo costuma ser atingi-los.
Análise de Impacto no Negócio (BIA)
Antes de definir RTO/RPO, é preciso saber quais processos são realmente críticos. A BIA mapeia cada processo de negócio, o impacto (financeiro, reputacional, legal) de ele ficar indisponível ao longo do tempo, e as dependências entre sistemas. Nem tudo merece o mesmo nível de proteção — BIA é o que evita gastar a mesma energia protegendo o sistema de recados internos e o sistema que processa pagamentos.
Estratégias de disaster recovery
| Tipo de site | Características |
|---|---|
| Hot site | Ambiente redundante já ativo e sincronizado em tempo real. Recuperação quase imediata, mas o mais caro. |
| Warm site | Infraestrutura pronta, mas dados precisam ser sincronizados/atualizados na hora do desastre. Custo e tempo intermediários. |
| Cold site | Apenas o espaço/infraestrutura básica existe; tudo precisa ser configurado do zero. Mais barato, recuperação muito mais lenta. |
A escolha depende diretamente do RTO definido na BIA: quanto menor o RTO tolerável, mais "quente" o site precisa ser.
Testar o plano é a parte que mais falha
Um plano de continuidade nunca testado é uma suposição, não uma garantia. Testes variam de simples (revisão em mesa, discutindo o plano teoricamente) a completos (simulação real de failover para o site de contingência). Empresas descobrem falhas nos próprios planos com frequência assustadora — e é infinitamente melhor descobrir isso em um teste programado do que durante um incidente real.
💡 Exemplo prático
Um ataque de ransomware criptografa os servidores de produção de uma empresa. Como o RPO definido era de 1 hora, o backup mais recente (feito 40 minutos antes do ataque) permite restaurar as operações com perda mínima de dados. Como existia um warm site pré-configurado, a equipe consegue direcionar o tráfego para lá dentro do RTO de 4 horas combinado com as áreas de negócio.
⚠️ Erro comum
Definir RTO/RPO ambiciosos sem orçamento compatível, ou definir esses valores apenas dentro da TI, sem envolver as áreas de negócio que realmente entendem o impacto de cada sistema ficar fora do ar. BCDR eficaz é uma decisão de negócio com implementação técnica — não o contrário.
✅ Pontos-chave
- RTO = quanto tempo até voltar; RPO = quanto dado se pode perder.
- BIA define o que é crítico antes de desenhar qualquer solução técnica.
- Hot/warm/cold site são níveis de prontidão com trade-off direto entre custo e velocidade de recuperação.
- Um plano não testado é uma suposição — testes regulares são parte do plano, não um extra.
🔗 Para se aprofundar
- Plano de continuidade de negócios — Wikipédia
- Recuperação de desastre — Wikipédia
- (ISC)²BCDR é um domínio do CISSP e do (ISC)² CC