Estratégia de Backup

Estratégia de backup resiliente é última linha de defesa contra perda de dados causada por ransomware, falhas de hardware, desastres naturais, erros humanos, corrupção de dados ou ataques maliciosos que destroem sistemas de produção - sem backups adequados, um incidente que poderia ser resolvido com restore de algumas horas pode se transformar em perda permanente de dados críticos, downtime de dias ou semanas, e potencialmente falência do negócio. A regra fundamental 3-2-1 (3 cópias dos dados, em 2 tipos diferentes de mídia, com 1 cópia offsite) continua válida mas precisa ser expandida para ambientes modernos com conceitos como backup imutável para proteção anti-ransomware (backups que não podem ser deletados ou modificados nem por administradores durante período de retenção), testes regulares de restore para validar que backups realmente funcionam quando necessário (muitas organizações descobrem que backups estão corrompidos somente quando precisam deles em emergência), definição clara de RPO (Recovery Point Objective - quanto de dados podemos perder medido em tempo desde último backup) e RTO (Recovery Time Objective - quanto tempo podemos ficar offline até sistema estar restaurado), separação de credenciais de backup do domínio principal para prevenir que atacante que compromete Active Directory também destrua todos os backups, e automação de processos de backup com monitoramento e alertas para garantir que backups acontecem conforme esperado. Erro comum é tratar backup como "set and forget" - backups requerem atenção contínua, validação, atualização de procedimentos conforme infraestrutura evolui, e principalmente: cultura organizacional que valoriza proteção de dados tanto quanto produção de novos features.

Regra 3-2-1: Fundamentos de Redundância

A regra 3-2-1 estabelece que você deve manter 3 cópias dos seus dados (produção + 2 backups), em 2 tipos diferentes de mídia de armazenamento, com 1 cópia offsite geograficamente separada. Por exemplo: dados de produção em SAN (Storage Area Network), backup primário em NAS (Network Attached Storage) no mesmo datacenter, e backup secundário em cloud storage (S3, Azure Blob) em região diferente. A diversidade de mídia protege contra falhas específicas de tecnologia - se você tem todos os backups em fitas magnéticas e descobre que seu tape drive parou de funcionar, você pode ficar impossibilitado de restaurar mesmo tendo as fitas. A cópia offsite protege contra desastres localizados (incêndio, inundação, roubo, ataque físico ao datacenter) - se todos os backups estão no mesmo prédio que queimou, você perdeu tudo. Moderna evolução do 3-2-1 é 3-2-1-1-0: 3 cópias, 2 mídias, 1 offsite, 1 immutable (imutável), 0 erros (validado por restore tests). Para implementar: configure backup software (Veeam, Commvault, Bacula, Acronis, AWS Backup, Azure Backup) para criar snapshots diários dos sistemas críticos, replique esses backups para storage local (primeira cópia), envie copy para cloud (segunda cópia offsite), e marque cópias cloud como immutable com Object Lock (S3) ou Immutable Blobs (Azure). Calcule storage necessário baseado em: tamanho dos dados × retention period × change rate - se você tem 10TB de dados, quer reter backups por 30 dias, e 10% dos dados mudam diariamente, você precisará aproximadamente 10TB + (10TB × 0.1 × 30) = 40TB de storage para backups. Use deduplicação e compressão para reduzir custos mas cuidado com crypto ransomware que pode fazer dados parecerem random e reduzir eficiência de dedupe.

Backup Imutável Anti-Ransomware

Ransomware moderno não apenas criptografa dados de produção mas ativamente procura e destrói backups para maximizar pressão sobre vítima para pagar resgate - atacantes usam credenciais administrativas comprometidas para deletar snapshots, desabilitar serviços de backup, corromper backup catalogs, e até mesmo criptografar os próprios backups. Backup imutável (também chamado de WORM - Write Once Read Many, ou air-gapped backup) previne isso tornando backups impossíveis de deletar ou modificar durante retention period definido, mesmo por administradores com privilégios máximos. Implementações: AWS S3 Object Lock em modo Compliance (nem root account pode deletar objetos antes de expiration date), Azure Blob Immutable Storage com legal hold ou time-based retention policies, tape backups fisicamente removidas e guardadas em vault offsite, e backup appliances com WORM mode (Dell EMC Data Domain, Cohesity). Configure retention period apropriado - geralmente 30-90 dias dependendo do seu RPO e quanto tempo você precisa manter versões históricas. IMPORTANTE: immutability previne deleção mas não previne criação de novos backups corrompidos - se atacante compromete sistema durante semanas antes de disparar ransomware, seus backups imutáveis podem conter dados já infectados. Solução: mantenha múltiplas versões de backups (não apenas o mais recente), use backup validation que detecta anomalias nos dados (súbito aumento de entropia pode indicar encryption), e considere "air gap" físico onde backups são periodicamente copiados para storage completamente desconectado da rede. Teste recovery de backups imutáveis regularmente pois alguns sistemas têm bugs onde imutabilidade impede até mesmo legitimate restore operations.

Testes de Restore e Validação

Backup não testado é backup não confiável - há inúmeros casos documentados de empresas que faziam backups religiosos por anos e descobriram durante disaster recovery que backups estavam corrompidos, configuração estava errada, mídia estava degradada, ou processo de restore simplesmente não funcionava. Implemente programa formal de backup testing: restore completo de produção em ambiente de teste mensalmente (full system restore), restore de VMs/databases críticas semanalmente (partial restore), e validação de backup job logs diariamente (verificar que backups completaram sem erros). Automatize testes usando scripts que: iniciam restore em ambiente isolado, verificam integridade dos dados restaurados (checksums, database consistency checks), medem tempo de restore (valida se você consegue cumprir RTO), e geram reports com métricas. Para databases, use backup restore validation do próprio DBMS: SQL Server RESTORE VERIFYONLY, MySQL mysqlcheck, PostgreSQL pg_restore --list. Para backups de aplicações, restaure e execute smoke tests automatizados que verificam funcionalidades críticas. Documente cada teste: data, sistemas testados, resultado (sucesso/falha), tempo decorrido, issues encontrados, e ações corretivas. Trate falhas em restore tests como P0 incidents - se backup test falha, você assume que não tem backup funcional até corrigir. Considere fazer "surprise restore drills" onde você avisa equipe sem antecedência que precisam restaurar sistema X em Y horas, simulando emergency real. Além de validar backups, esses drills treinam equipe em procedimentos de recovery e identificam gaps em documentação ou automação.

RPO e RTO: Definindo Objetivos de Recovery

RPO (Recovery Point Objective) é quantidade máxima de dados que você pode perder medida em tempo - se seu RPO é 4 horas, você precisa fazer backups pelo menos a cada 4 horas, e em caso de disaster você pode perder até 4 horas de transações. RTO (Recovery Time Objective) é tempo máximo que sistema pode ficar offline até ser restaurado - se seu RTO é 2 horas, você tem 2 horas desde detecção do incident até sistema estar operacional novamente. RPO e RTO devem ser definidos por business requirements (quanto de dados perdidos e downtime o negócio tolera) e ditam arquitetura de backup: aplicações tier-1 críticas podem exigir RPO=0 (zero data loss via replicação síncrona) e RTO de minutos (high availability cluster), aplicações tier-2 podem tolerar RPO=1h (backups incrementais horários) e RTO=4h, aplicações tier-3 podem ter RPO=24h (backups noturnos) e RTO=8h. Calcule custo vs risk: RPO menor requer backups mais frequentes (mais storage, mais overhead de performance), RTO menor requer sistemas de recovery mais sofisticados (hot standby, automated failover). Exemplo de arquitetura para diferentes tiers: Tier-1 (ERP, Payment Processing) - replicação síncrona para DR site + snapshots de 15 min + backup diário imutável, RPO menor que 15 min, RTO menor que 1h, Tier-2 (CRM, Email) - backups incrementais de 1h + backup full diário, RPO=1h, RTO=4h, Tier-3 (File Shares, Logs) - backup daily, RPO=24h, RTO=8h. Documente RPO/RTO para cada sistema em Disaster Recovery Plan, obtenha sign-off de business stakeholders (para garantir alignment de expectations), e monitore se você consegue cumprir objetivos definidos (track actual recovery times em incidents).

Separação de Credenciais de Backup

Atacante que compromete Active Directory com Domain Admin privileges pode potencialmente acessar e destruir todos os backups se backup system usa credenciais do mesmo AD - isso é vetor comum em ataques de ransomware onde atacante primeiro estabelece persistência em AD, depois mapeia toda infraestrutura de backup, e finalmente destroi backups antes de disparar encryption. Mitigue com segregação de credenciais: crie domínio separado ou workgroup standalone para backup infrastructure, use service accounts locais em vez de domain accounts onde possível, configure backup appliances com autenticação própria independente de AD, implemente MFA para acesso a backup console e storage, e use API keys com permissões restritas para cloud backups em vez de credenciais com acesso amplo. Para ambientes com Veeam, implemente "hardened Linux repository" onde backup server é Linux (fora do AD Windows) acessível apenas via SSH com key-based auth e sem possibilidade de deleção de backups via Veeam console (immutability enforced no Linux filesystem level). Para AWS backups, use cross-account backup vault onde backups são enviados para AWS account separada controlada por equipe diferente com credenciais não compartilhadas, e configure Vault Lock para prevenir deleção. Aplique princípio de least privilege: conta que faz backups só precisa de read access em produção e write access no backup destination, não precisa de delete permissions. Monitore acessos a backup infrastructure como high-value targets - qualquer tentativa de acesso fora de horários de backup ou de IPs inesperados deve gerar alerta de segurança. Em casos extremos, considere "offline backup admin" onde credenciais de administração de backups não existem em forma digital - são stored em vault físico e só acessadas em emergências.