Backup é o seguro que ninguém valoriza até o dia do incêndio. E, assim como seguro, ele tem uma pegadinha cruel: a maioria das empresas só descobre que o seu não presta no exato momento em que precisa dele. O arquivo estava corrompido, faltava metade das tabelas, ninguém tinha a chave de descriptografia, ou — clássico — o backup automático parou de rodar há oito meses e o alerta caía numa caixa de e-mail que ninguém lia.
Disaster recovery para PME não é sobre comprar o storage mais caro nem contratar um serviço gerenciado premium que você não vai entender. É sobre duas decisões honestas: quanto tempo parado você aguenta e quanto dado você aceita perder — por sistema, porque nem tudo tem o mesmo valor. Este texto é sobre tomar essas decisões de forma pragmática e escolher a estratégia mais barata que atenda à necessidade real, sem cair no pânico de superdimensionar nem na negligência de não ter plano nenhum.
Backup e disaster recovery, em uma frase
Backup é a cópia dos dados para poder restaurar; disaster recovery é o plano completo de voltar a operar após uma falha grave — incluindo como recriar a infraestrutura, em quanto tempo e em que ordem. Backup sem plano de recovery é ter as peças sem o manual.
Guarde a diferença: quase todo mundo tem alguma forma de backup. Quase ninguém tem um plano ensaiado de como voltar ao ar. É o segundo que salva o negócio.
As duas perguntas que definem tudo: RTO e RPO
Antes de escolher qualquer ferramenta, responda duas perguntas para cada sistema. Elas são o vocabulário inteiro do assunto.
RTO (Recovery Time Objective) é quanto tempo você aceita ficar fora do ar. Uma hora? Um dia? A documentação de disaster recovery da AWS define RTO como o atraso máximo aceitável entre a interrupção e a restauração do serviço.
RPO (Recovery Point Objective) é quanto dado você aceita perder, medido em tempo desde o último ponto de recuperação. Se você faz backup uma vez por dia e o desastre acontece às 23h, você pode perder até 23 horas de dados. Esse é seu RPO real, quer você tenha planejado ou não.
A frase-chave: RTO responde “quanto tempo parado?” e RPO responde “quanto dado perdido?”. Toda a estratégia e todo o custo saem daí. Quanto menor os dois, mais caro e mais complexo o plano. Por isso não faz sentido exigir RTO de minutos para tudo.
Nem tudo é crítico: classifique por dor
O erro mais caro em DR é tratar todos os sistemas com o mesmo rigor. Isso ou estoura o orçamento (protegendo demais o que não importa) ou deixa buraco (protegendo de menos o que importa). A saída é classificar por criticidade, olhando o impacto real de cada sistema ficar fora.
| Criticidade | Exemplo | RTO alvo | RPO alvo |
|---|---|---|---|
| Crítico | Pagamento, autenticação, banco principal | Minutos a poucas horas | Segundos a minutos |
| Importante | Painel interno, relatórios, e-mail transacional | Horas | Uma hora |
| Secundário | Blog, site institucional, dados analíticos | Um dia ou mais | Um dia |
| Descartável/recriável | Cache, ambiente de teste, logs efêmeros | Sem plano formal | Sem plano formal |
A pergunta que preenche a tabela é direta: se este sistema sumir por X tempo, quanto custa em dinheiro, cliente e reputação? Um checkout parado por uma hora é sangramento; um blog parado por um dia é aborrecimento. Investir o mesmo nos dois é desperdiçar de um lado e arriscar do outro.
O espectro de estratégias (do barato ao caro)
A AWS organiza as opções de DR num espectro que vale para qualquer nuvem, do menor custo ao maior. Você escolhe o ponto do espectro que atende ao RTO/RPO de cada classe — não um único ponto para tudo.
- Backup e restore. O mais simples e barato. Você guarda cópias e, no desastre, recria a infraestrutura e restaura os dados. RTO e RPO são os mais altos (horas a dias). Perfeito para sistemas secundários e ótimo ponto de partida para quase toda PME.
- Pilot light. Você mantém sempre ligado o núcleo mínimo — tipicamente o banco replicado e a configuração central — e o resto desligado. No desastre, liga e escala o restante. RPO em minutos, RTO em horas. O melhor custo-benefício para os sistemas críticos de uma PME.
- Warm standby. Uma versão reduzida do ambiente inteiro fica rodando e pronta para receber tráfego; você só escala. RPO em segundos, RTO em minutos. Custa mais, porque há infraestrutura ligada o tempo todo.
- Multi-site ativo/ativo. O sistema roda simultaneamente em mais de uma região servindo tráfego. RTO e RPO próximos de zero, e custo próximo do dobro. Raramente justificável para PME.
A diferença prática entre pilot light e warm standby, segundo a AWS, é que o pilot light não consegue atender requisições sem uma ação prévia — você precisa ligar e escalar antes —, enquanto o warm standby já atende, em capacidade reduzida, na hora. Essa diferença é a fronteira entre “barato e aceitável” e “caro e rápido”.
Por que você quase nunca precisa de DRaaS caro
DRaaS — disaster recovery como serviço — é vendido como o botão mágico. Para uma PME, costuma ser resposta para uma pergunta que você não fez. A maioria dos negócios pequenos vive confortavelmente com backup e restore bem ensaiado para o grosso dos sistemas e pilot light para os críticos. Isso cobre a esmagadora maioria dos desastres reais — falha de hardware, erro humano, corrupção de dado, ransomware — a uma fração do custo de um ambiente duplicado rodando 24/7.
O caminho honesto é começar do lado barato do espectro e subir só onde o RTO/RPO da classe exigir. Comprar warm standby ou DRaaS para um sistema secundário é queimar dinheiro para dormir com uma tranquilidade que você já teria de graça.
A regra que a maioria ignora: teste o restore
Aqui está a parte que separa quem tem DR de quem tem a ilusão de DR. Backup que nunca foi restaurado não é backup — é uma esperança guardada. Você não sabe se ele funciona até tentar restaurar, e o pior momento para descobrir que não funciona é durante o desastre.
O ensaio de restore precisa ser rotina, não improviso:
- Restaure de verdade os sistemas críticos pelo menos uma vez por trimestre
- Cronometre o restore e compare com o RTO prometido — se estourar, o plano é ficção
- Confirme que o dado restaurado está íntegro e completo, não só que o arquivo abriu
- Teste quem tem acesso e as chaves de descriptografia, antes de precisar delas às 3h
- Reveja o plano sempre que a infraestrutura mudar
- Guarde cópias isoladas: outra região, outra conta, com retenção que impeça exclusão imediata
Esse último ponto merece ênfase: backup na mesma conta e região do sistema cai junto com ele se a conta for comprometida ou alguém apagar tudo. Redundância só protege quando as cópias não caem pelo mesmo motivo.
Ransomware e erro humano: os desastres mais prováveis
Quando se fala em desastre, a imaginação vai para incêndio no data center ou queda de uma região inteira da nuvem. Na prática de uma PME, os dois desastres mais comuns são bem mais prosaicos: alguém apagou o que não devia, e ransomware criptografou os dados. Um plano de DR que só protege contra falha de hardware ignora os cenários que mais acontecem.
Esses dois casos têm uma exigência específica que muda o desenho do backup: cópias imutáveis e versionadas. Contra erro humano, você precisa de versões anteriores — se alguém apagou um dado ontem e ninguém percebeu hoje, o backup de hoje já copiou o estrago; só uma versão de dois dias atrás salva. Contra ransomware, você precisa de cópias que não possam ser sobrescritas nem apagadas nem pela conta comprometida — retenção travada, que nem um administrador legítimo consegue burlar dentro da janela de proteção.
É por isso que o “quanto dado eu aceito perder” (RPO) precisa conversar com “quanto tempo até eu perceber o problema”. Se você só nota a corrupção depois de uma semana, um backup diário com retenção de três dias não te salva. O ensaio de restore, de novo, é o que revela essa lacuna antes que ela custe caro — porque testar restaurar uma versão de dias atrás mostra na hora se as cópias antigas ainda existem e estão íntegras.
Como a Pixelize ajuda
Em DevOps, a gente começa pela conversa desconfortável — quanto tempo parado e quanto dado perdido você aguenta, sistema por sistema — e só então escolhe a estratégia mais barata que atenda. Depois, monta os ensaios de restore para que o plano não seja ficção.
DR bem-feito conversa com o resto da operação: a escolha entre nuvem e servidor próprio muda a conta, como discutimos em cloud vs on-premise para PMEs; a observabilidade para produtos é o que detecta o desastre cedo; e um bom pipeline de CI/CD sem drama é o que recria a infraestrutura rápido na hora do restore. Vale também revisar os riscos de publicar apps em produção antes que o pior aconteça.
Perguntas frequentes
Qual a diferença entre backup e disaster recovery?
Backup é a cópia dos dados. Disaster recovery é o plano completo de voltar a operar — inclui o backup, mas também como recriar a infraestrutura, em quanto tempo e em que ordem.
O que são RTO e RPO?
RTO é quanto tempo você aceita ficar fora do ar; RPO é quanto dado aceita perder. Um responde “quanto tempo parado?” e o outro “quanto dado perdido?”. Juntos definem estratégia e custo.
Toda PME precisa contratar um serviço de DRaaS?
Não. DRaaS costuma ser caro e superdimensionado. A maioria fica bem com backup e restore ensaiado, ou pilot light nos sistemas críticos. Comece pelo RTO/RPO que você precisa.
Com que frequência devo testar o restore?
Pelo menos uma vez por trimestre para os sistemas críticos, e após mudança relevante de infraestrutura. Backup nunca restaurado é ficção — o desastre é o pior momento para descobrir falha.
O que é a estratégia pilot light?
Manter sempre ligado o núcleo mínimo (banco replicado e config) e o resto desligado. No desastre, liga e escala. RPO em minutos e RTO em horas, a custo baixo.
Backup na mesma nuvem do sistema é suficiente?
É um começo, mas frágil se ficar tudo na mesma conta e região. Isole: outra região, outra conta, retenção que impeça exclusão imediata. Redundância só vale se as cópias não caírem juntas.