Backup e Disaster Recovery (DR) são complementares, não a mesma coisa. Backup protege seus dados — é o que permite recuperar arquivos, bancos de dados e sistemas após uma perda. DR protege a continuidade da operação — é o que permite que sua empresa continue funcionando mesmo quando o datacenter principal falha inteiro.
Por que a confusão acontece — e por que ela é cara
Imagine que você é gestor de uma empresa de varejo online. Num sábado de Black Friday, o datacenter onde seus servidores estão hospedados sofre uma falha catastrófica — uma falha elétrica que destrói equipamentos físicos. A equipe de TI aciona o backup. Os dados estão lá. Ótimo.
Mas onde você vai restaurar? O ambiente inteiro precisa ser reconstruído: servidores provisionados, sistemas operacionais instalados e configurados, aplicações implantadas, banco de dados restaurado, rede configurada, testes realizados. No melhor dos cenários com equipe experiente e infraestrutura disponível, isso leva de 12 a 48 horas. Para um e-commerce na Black Friday, isso é catastrófico — não pela perda de dados, mas pela perda de operação.
Esse é o gap entre backup e DR. Backup resolve “os dados existem?”. DR resolve “a empresa consegue operar?”.
A confusão é cara porque empresas que investem só em backup se planejam para um nível de risco que não cobre os cenários de maior impacto operacional.
O que cada um resolve — com precisão
Backup é um processo de cópia e retenção de dados. Seu objetivo primário é recuperação de dados — um arquivo apagado, um banco de dados corrompido, um servidor com falha de storage. O resultado de um restore bem-sucedido é: os dados voltaram. O ambiente precisa estar disponível para recebê-los.
Backup é excelente para:
- Recuperar arquivos excluídos acidentalmente
- Restaurar banco de dados corrompido por erro de aplicação
- Recuperar servidor com falha de disco
- Atender requisito de retenção de dados para compliance
- Voltar a um ponto anterior ao ataque de ransomware
Disaster Recovery é um conjunto de processos, tecnologias e planos que permitem retomar a operação do negócio após um evento disruptivo de larga escala. O resultado de um DR bem-sucedido é: a operação está funcionando em ambiente alternativo. Os dados podem ser os do backup mais recente, mas o ambiente está operacional.
DR é necessário quando:
- O datacenter principal falha completamente (incêndio, inundação, falha de energia prolongada)
- Um ataque de ransomware paralisa todos os sistemas simultaneamente
- Um desastre natural afeta a região onde a infraestrutura está
- Uma falha em cascata derruba múltiplos sistemas críticos simultaneamente
RPO e RTO: as métricas que separam os dois mundos
A melhor forma de entender a diferença prática é através das métricas de recovery:
RPO (Recovery Point Objective) é quanto de dado você aceita perder, medido em tempo. Se seu backup roda a cada 4 horas e você sofre um incidente, você pode perder até 4 horas de dados. Se isso é inaceitável para o negócio, o RPO precisa ser menor — o que exige backup mais frequente ou continuous data protection.
RTO (Recovery Time Objective) é quanto tempo você pode ficar sem operar. Backup tradicional tem RTOs de horas a dias. DR bem projetado tem RTOs de minutos a poucas horas.
Backup corporativo típico entrega: RPO de 1–24 horas, RTO de 4–48 horas.
DR com replicação ativa entrega: RPO de segundos a minutos, RTO de minutos a 1 hora.
A diferença de custo entre essas duas realidades é significativa. E é exatamente por isso que a decisão “o que precisamos de backup vs o que precisamos de DR” precisa ser baseada no impacto financeiro e operacional de cada cenário — não em feeling.
Quando backup resolve e quando só DR resolve
Backup resolve:
Um servidor de arquivo de RH fica inacessível porque o disco falhou. Você restaura para um servidor alternativo ou provisiona um novo, restaura o backup. O processo leva algumas horas, mas o impacto ao negócio é aceitável porque RH pode operar parcialmente no dia.
Um banco de dados de ERP tem dados corrompidos por um bug de aplicação. Você restaura o banco para o ponto anterior à corrupção. O ERP fica offline por 2 horas enquanto o restore acontece.
Só DR resolve:
O datacenter principal vai a zero — falha elétrica total, servidores destruídos. Com backup apenas, você precisa reconstruir toda a infraestrutura antes de restaurar os dados. Esse processo pode levar dias. Com DR ativo — ambiente secundário espelhado pronto para assumir — você ativa o failover em minutos.
Um ransomware massivo criptografa simultaneamente todos os servidores, storages e backups acessíveis em rede. Com apenas backup em rede (sem imutabilidade), você não tem de onde restaurar. Com DR em site isolado com replicação, o ambiente secundário está limpo e disponível.
Os erros mais comuns de quem trata backup como DR
Empresas que tratam backup como DR geralmente fazem isso: calculam que o backup mais recente tem os dados, concluem que estão protegidos para qualquer incidente e não investem em ambiente de recuperação. Os três erros mais comuns que resultam disso:
Não ter onde restaurar. O backup existe, mas o ambiente de destino para o restore — servidores, rede, storage — não está provisionado. No momento da crise, a equipe gasta horas ou dias provisionando infraestrutura antes de sequer iniciar o restore.
RTO implícito absurdo. Ninguém calculou quanto tempo leva para restaurar o ambiente completo. Na crise, descobrem que o processo leva 3 dias — e o contrato com o cliente exige SLA de 4 horas.
Backup também comprometido. O incidente que justificaria DR — ransomware massivo, falha catastrófica de datacenter — geralmente também compromete o backup se ele estiver no mesmo local ou acessível na mesma rede.
Quer entender qual combinação de Backup e DR faz sentido para o perfil de risco da sua empresa? A Adentro oferece avaliação técnica gratuita com especialistas em continuidade de negócios.