Recuperação de desastres: o seguro que ninguém quer pagar até precisar

Existe uma categoria de investimento que todo gestor sabe que deveria fazer e quase ninguém prioriza: aquele cujo valor só aparece no pior dia. Recuperação de desastres é o exemplo perfeito. Enquanto tudo funciona, parece dinheiro jogado fora. Quando o servidor pega fogo, o ransomware criptografa tudo ou o data center inunda, vira a coisa mais importante do mundo.

O problema é que a hora de descobrir se você tem um plano não pode ser a hora do desastre. Nesse momento, ou o plano existe e funciona, ou a organização descobre, no pior contexto possível, que estava operando sem rede de proteção.

Este artigo é uma introdução ao conceito para quem ainda não o trata com a seriedade que ele exige. Não é um manual técnico, é uma explicação de por que recuperação de desastres deveria estar na agenda de qualquer líder que depende de sistemas para funcionar. E hoje, isso é praticamente todo mundo.

O que é recuperação de desastres, de verdade

Recuperação de desastres é o conjunto de planos, processos e recursos que permite à organização restaurar suas operações depois de um evento que as interrompe gravemente. A sigla técnica é DR, de disaster recovery, e ela vive dentro de um conceito maior: continuidade de negócio.

A diferença entre os dois importa. Continuidade de negócio pergunta "como mantemos a operação funcionando durante uma crise?". Recuperação de desastres pergunta "como voltamos a funcionar depois que algo nos derrubou?". Uma cuida do durante, a outra do depois.

O ponto central é que um desastre, nesse contexto, não significa só catástrofe natural. Significa qualquer evento que torne seus sistemas ou dados indisponíveis: uma falha de hardware, um erro humano que apaga a base de produção, um ataque de ransomware, a queda de um provedor de nuvem. A maioria dos "desastres" reais é mundana, e justamente por isso, comum.

A tese: desastre não é exceção, é estatística

A forma mais perigosa de pensar sobre isso é tratar desastre como algo improvável que acontece com os outros. Defendo o oposto: desastre é uma certeza distribuída no tempo. Você não sabe quando, mas sabe que algo vai dar errado.

Discos falham. Pessoas erram. Atacantes existem e são incansáveis. Provedores têm interrupções. Some tudo isso ao longo dos anos de operação de uma organização e a pergunta deixa de ser "se" e passa a ser "quando" e "quão preparados estaremos".

Quem internaliza essa lógica para de ver recuperação de desastres como pessimismo e passa a vê-la como gestão de risco básica. É o mesmo raciocínio do seguro do carro ou do extintor de incêndio: você não compra esperando usar, compra porque o custo de não ter quando precisa é alto demais.

Os dois números que definem todo plano

Recuperação de desastres parece abstrata até você conhecer dois conceitos que a tornam concreta e mensurável.

RTO, Tempo Objetivo de Recuperação. Quanto tempo a operação pode ficar parada antes que o dano se torne grave? Minutos? Horas? Dias? Esse número define o quão rápido seu plano precisa restaurar os sistemas.

RPO, Ponto Objetivo de Recuperação. Quanto de dado você pode perder? Se o último backup foi há vinte e quatro horas e o desastre acontece agora, você perde um dia de informação. O RPO define a frequência com que você precisa salvar.

Esses dois números traduzem uma decisão de negócio em requisitos técnicos. E são reveladores: muitas organizações descobrem, ao defini-los, que toleram menos perda e menos parada do que imaginavam, e que os backups que têm não atendem nem de longe.

Por que backup não é a mesma coisa que recuperação

O erro mais comum e mais perigoso: confundir ter backup com ter recuperação de desastres. São coisas diferentes, e a diferença custa caro.

Backup é a cópia dos dados. Recuperação é a capacidade comprovada de restaurar a operação a partir dela. Muitas organizações têm backups religiosamente feitos que nunca foram testados. No dia do desastre, descobrem que o backup estava corrompido, incompleto, ou que ninguém sabe como restaurá-lo, ou que restaurar leva muito mais tempo do que a operação suporta.

Um backup que nunca foi testado não é um plano. É uma esperança. A diferença aparece exatamente no momento em que você não pode mais corrigir.

Em incidentes de ransomware, essa distinção se tornou existencial. Atacantes modernos miram justamente os backups antes de criptografar a produção, sabendo que sem eles a vítima fica sem saída. Ter o backup isolado e testado deixou de ser boa prática e virou questão de sobrevivência.

O lado humano e organizacional

Há uma dimensão que planos técnicos costumam ignorar: no dia do desastre, são pessoas sob estresse que executam o plano. Se ele só existe na cabeça de uma pessoa, ou em um documento que ninguém leu, ele não vai funcionar quando a pressão estiver no máximo.

Um plano real precisa estar documentado de forma clara, com papéis definidos: quem decide, quem executa, quem comunica. Precisa ser ensaiado, como um simulado de incêndio, para que no momento crítico as pessoas saibam o que fazer sem improvisar. E precisa considerar o cenário de a pessoa-chave estar indisponível justamente naquele dia.

No setor público, isso ganha um peso adicional. Quando um sistema de saúde, de arrecadação ou de serviços ao cidadão cai, não é só a organização que sofre, é a população que depende daquele serviço. A continuidade, ali, é responsabilidade pública, não conveniência operacional.

A reflexão que muda a prioridade

A armadilha cultural é o otimismo. "Nunca aconteceu nada conosco" é a frase que precede a maioria dos desastres mal resolvidos. A ausência de incidente não é prova de segurança, é apenas sorte que ainda não acabou.

Recuperação de desastres é, no fundo, um teste de maturidade da liderança. Times imaturos investem só no que gera resultado visível. Times maduros investem também no que evita perdas catastróficas, mesmo sem aplausos. É a diferença entre administrar para o dia bom e administrar para o dia ruim que inevitavelmente virá.

Quando o desastre chega, e ele chega, a organização que se preparou tem uma história de susto e recuperação. A que não se preparou tem uma história de crise, perda e, às vezes, fim. A escolha entre essas duas histórias é feita hoje, no dia em que parece que nada vai dar errado.

Se a sua organização nunca testou de verdade o que aconteceria diante de uma perda total de dados, esse talvez seja o sinal de que está na hora. Há outros artigos no blog sobre segurança, backup e continuidade que aprofundam o tema. Se essa for uma preocupação real no seu contexto, vale conversar antes que o assunto vire urgência.