Backup e Recuperação

Toda organização tem dois tipos de dados: os que estão no backup e os que ainda não foram perdidos. É uma distinção cruel, mas precisa — porque a maioria das empresas só descobre que o backup não funciona no momento em que mais precisa dele.

Backup e recuperação é o conjunto de práticas que garante que dados críticos possam ser restaurados após perda, corrupção ou destruição. O conceito parece simples; a implementação que realmente funciona sob pressão é mais complexa do que parece.

O objetivo não é ter backup — é ter recuperação. Backup é o processo; recuperação é a capacidade real de restaurar dados e sistemas num tempo aceitável quando algo dá errado. Empresas que fazem backup mas nunca testam a restauração frequentemente descobrem, no pior momento, que o backup era inutilizável: arquivo corrompido, processo de restauração que ninguém conhece, tempo de recuperação incompatível com a operação.

Falha de hardware: discos falham — a taxa de falha anual para discos mecânicos gira em torno de 1 a 3%. Em ambiente com muitos discos, falha é evento esperado, não exceção.

Erro humano: a causa mais comum. Arquivo deletado acidentalmente. Banco de dados sobrescrito durante deploy. Script de manutenção executado no ambiente errado. Erro humano é inevitável; backup é o que torna o erro reversível.

Ransomware: malware que criptografa dados e exige pagamento para restaurar acesso. Tornou-se o cenário de backup mais crítico — e o mais exigente, porque atacantes modernos frequentemente comprometem os backups antes de ativar o ransomware. Backup isolado, imutável e testado é a única defesa eficaz.

Desastre físico: incêndio, alagamento, queda de energia com dano a equipamentos. Backup no mesmo local físico que os dados originais não protege contra desastre físico.

Falha de software / corrupção de dados: bug em aplicação que corrompe registros, migração mal feita que destrói dados, atualização que causa incompatibilidade.

Encerramento de serviço: fornecedor SaaS que fecha ou muda de produto. Dados que ficam apenas no sistema de terceiro estão sujeitos às decisões desse terceiro.

O framework mais reconhecido para estratégia de backup é a regra 3-2-1:

3 cópias dos dados (o original mais dois backups) 2 mídias ou tecnologias diferentes (não dois HDs do mesmo modelo no mesmo servidor) 1 cópia offsite — fora do local principal (nuvem, outro datacenter, outro escritório)

A lógica: três cópias porque falhas múltiplas simultâneas são muito menos prováveis do que falha única. Duas mídias porque uma falha de modelo ou tecnologia pode afetar todos os dispositivos do mesmo tipo. Uma cópia offsite porque desastre físico destrói tudo no mesmo local.

Para ambientes com ransomware como ameaça relevante, a regra evoluiu para 3-2-1-1-0: os três elementos originais, mais uma cópia imutável (não pode ser modificada ou deletada por ninguém) e zero erros verificados — backups testados regularmente e confirmados como restauráveis.

Antes de desenhar uma estratégia de backup, é necessário definir dois parâmetros que dependem de decisão de negócio, não de TI.

RPO (Recovery Point Objective): quanto de dados a empresa pode perder sem impacto inaceitável? Se o backup é executado toda madrugada e o servidor falha às 17h, os dados do dia inteiro são perdidos. Se o RPO de negócio é de 4 horas, o backup precisa acontecer a cada 4 horas.

RTO (Recovery Time Objective): em quanto tempo o sistema precisa estar restaurado para que o impacto seja aceitável? Se a operação para completamente sem o sistema de pedidos, e cada hora de indisponibilidade custa caro, o RTO pode ser de 2 horas. Se o sistema de arquivo histórico pode ficar offline por dias, o RTO é muito mais relaxado.

Sistemas diferentes têm RPO e RTO diferentes — e a estratégia de backup precisa ser dimensionada para cada um. A maioria das empresas não definiu formalmente esses parâmetros, o que significa que o tempo de recuperação em caso de incidente vai ser uma surpresa desagradável.

Full backup: cópia completa de todos os dados. Mais simples de restaurar, mais lento de executar, consome mais espaço. Frequentemente executado semanalmente.

Incremental: copia apenas o que mudou desde o último backup (full ou incremental). Rápido de executar, usa pouco espaço. Restauração mais complexa — precisa do último full mais todos os incrementais em sequência.

Diferencial: copia o que mudou desde o último backup full. Restauração mais simples que incremental — precisa apenas do último full mais o último diferencial.

Snapshot: captura do estado de um sistema num ponto no tempo — especialmente útil para VMs e bancos de dados. Muito rápido de criar; permite reverter para um ponto específico rapidamente.

Continuous Data Protection (CDP): replica cada mudança em tempo real para local secundário. RPO próximo a zero. Alto custo de infraestrutura; justificável apenas para sistemas de missão crítica.

Serviços de backup em nuvem resolvem o requisito de cópia offsite com custo e complexidade baixos. Mas têm armadilhas específicas.

Tempo de restauração: copiar dados para a nuvem é rápido; restaurar grandes volumes da nuvem pode levar horas ou dias dependendo da largura de banda disponível. Para sistemas com RTO curto, a velocidade de restauração precisa ser verificada antes do incidente.

Custo de egress: muitos provedores cobram pelo tráfego de saída. Uma restauração de grande volume pode ter custo significativo não planejado.

Backup de SaaS: dados em sistemas SaaS (Salesforce, Google Workspace, Microsoft 365) são responsabilidade do cliente, não do provedor. Os provedores protegem a infraestrutura, não os dados de cada cliente contra erro humano ou deleção acidental. Backup independente de sistemas SaaS críticos é frequentemente ignorado — e frequentemente necessário.

A diferença entre backup e capacidade de recuperação está no teste. Backup não testado é suposição, não garantia.

O teste de restauração deve verificar: os dados são íntegros (não corrompidos)? O processo de restauração é conhecido e documentado? O tempo de restauração está dentro do RTO definido? Quem executa a restauração em caso de emergência, se o responsável técnico habitual não estiver disponível?

Agendar um teste de restauração completo — não simulado, mas a restauração real de dados de um período específico — revela mais sobre a real capacidade de recuperação do que qualquer auditoria de configuração de backup.

Backup é uma das áreas onde a lacuna entre o que as empresas acham que têm e o que realmente têm é maior. A pergunta mais reveladora é simples: quando foi a última vez que a empresa testou a restauração de um backup completo? Se a resposta for "nunca" ou "não sei", o backup existe como processo — não como capacidade de recuperação.

Para PMEs, a recomendação prática é direta: definir RPO e RTO para os dois ou três sistemas mais críticos, verificar se o backup atual atende esses parâmetros, e executar um teste de restauração real. Esse exercício frequentemente revela problemas que um incidente real tornaria muito mais caros de descobrir.

O investimento em backup adequado é seguro — com retorno apenas quando algo dá errado, mas com retorno que frequentemente significa a diferença entre empresa que sobrevive ao incidente e empresa que não sobrevive.