Plano de recuperação de desastres: seu sistema volta?

Pergunte a qualquer empresa se ela tem backup e a resposta vai ser sim. Pergunte quando foi a última vez que alguém restaurou esse backup num ambiente limpo, cronometrou o processo e conferiu se os dados estavam íntegros, e a conversa costuma ficar em silêncio.

Recuperação de desastres não é sobre ter cópias. É sobre conseguir voltar a operar depois que algo sério aconteceu, dentro de um limite de perda e de tempo que o negócio aceita. A seguir, como definir esse limite, quais cenários considerar, como proteger as cópias contra ataques e, principalmente, como provar que o plano funciona antes de precisar dele.

Backup que nunca foi restaurado não é backup

Cópias falham de formas silenciosas. A rotina de backup roda todas as noites e registra sucesso, mas:

• o arquivo gerado está corrompido ou incompleto;
• o banco foi copiado enquanto gravava, e a cópia está inconsistente;
• a senha de criptografia do backup estava com uma pessoa que saiu da empresa;
• o backup cobre o banco de dados, mas não os arquivos enviados pelos usuários, nem as configurações, nem os certificados;
• a restauração funciona, mas leva muito mais tempo do que a operação aguenta ficar parada;
• ninguém sabe a ordem certa de subir os componentes.

Nenhum desses problemas aparece num relatório de "backup concluído com sucesso". Todos aparecem no pior dia possível. Por isso a regra que orienta todo o resto deste texto: só existe backup depois do primeiro teste de restauração bem-sucedido, e ele continua existindo enquanto os testes continuam passando.

RPO e RTO: quanto dado perder e quanto tempo parar

Antes de escolher ferramenta, a empresa precisa responder duas perguntas de negócio, para cada sistema:

• RPO (Recovery Point Objective): quanto dado a empresa aceita perder. Se o último ponto de recuperação é de ontem à noite, tudo o que foi lançado hoje precisa ser refeito, ou se perde. Para um sistema de vendas, isso pode ser inaceitável. Para uma base de consulta atualizada uma vez por mês, talvez não faça diferença.
• RTO (Recovery Time Objective): quanto tempo o sistema pode ficar parado até voltar a funcionar. O caixa da loja, a expedição e o faturamento costumam tolerar muito pouco. Um relatório gerencial tolera bem mais.

Essas respostas não são técnicas. Quem decide é quem conhece o impacto: quanto custa uma hora sem faturar, quanto trabalho dá relançar um dia de pedidos, qual o risco regulatório de perder registros.

A engenharia entra em seguida, porque cada nível de RPO e RTO implica uma arquitetura diferente:

• Backup diário, com restauração manual, atende objetivos folgados.
• Backups mais frequentes e cópia contínua dos registros de transação do banco reduzem o RPO para minutos.
• Uma réplica do banco em outra região, pronta para assumir, reduz o RTO drasticamente, mas exige infraestrutura duplicada e processo de virada ensaiado.

Quanto mais apertados os objetivos, mais complexa e custosa é a solução. O erro comum é o contrário do que parece: não é gastar demais, é nunca ter feito a conta, e descobrir no incidente que os objetivos implícitos eram muito mais rígidos do que a infraestrutura entregava.

Uma prática útil é classificar os sistemas em poucos níveis de criticidade e aplicar objetivos por nível, em vez de tratar tudo como crítico ou nada como crítico.

Os cenários reais: ransomware, falha, erro humano e fornecedor

Um plano de recuperação precisa considerar cenários diferentes, porque cada um exige uma resposta diferente.

Ransomware. O atacante entra, criptografa os dados e, com frequência, procura e apaga os backups antes de se revelar. Se as cópias estão acessíveis com as mesmas credenciais da produção, elas vão junto. Esse é o cenário que mais exige cópias isoladas e imutáveis.

Falha de infraestrutura. Disco que queima, servidor local que para, região de nuvem com problema. É o cenário que as pessoas imaginam quando pensam em desastre, e com infraestrutura moderna costuma ser o mais fácil de tratar.

Erro humano. Um comando executado no banco errado, uma atualização em massa sem filtro, uma pasta excluída. É o cenário mais frequente e o menos planejado. Aqui a granularidade importa: restaurar o banco inteiro para desfazer um erro numa tabela significa perder tudo o que foi feito depois. Poder recuperar o estado de um momento específico faz muita diferença.

Fornecedor. O provedor de hospedagem encerra a conta por um problema de cobrança, o fornecedor de software some, a única pessoa com acesso ao ambiente sai da empresa. Esse cenário é um risco de acesso, não de tecnologia, e é o que mais pega empresas de surpresa. O roteiro para quem já está nessa situação está em herdou um sistema sem documentação.

Em quase todos os cenários, o plano também precisa cobrir a comunicação. Se o incidente envolver dados pessoais, a LGPD (Lei 13.709/2018) exige que o controlador comunique à ANPD e aos titulares os incidentes de segurança que possam acarretar risco ou dano relevante. A parte técnica dessa obrigação está em LGPD no desenvolvimento de sistemas.

Regra 3-2-1 e cópias imutáveis

A regra clássica continua sendo um bom ponto de partida:

• 3 cópias dos dados (a produção e mais duas);
• em 2 tipos de armazenamento diferentes;
• com 1 cópia fora do local principal.

Com ransomware no cenário, acrescenta-se um elemento essencial: pelo menos uma cópia imutável ou isolada. Imutável significa que, durante o período de retenção definido, ninguém consegue apagar ou alterar aquela cópia, nem mesmo com credenciais de administrador. Os principais provedores de nuvem oferecem armazenamento de objetos com bloqueio de retenção para isso.

Outros cuidados que separam um backup sólido de um frágil:

• Credenciais separadas. A conta que grava os backups não deve ser a mesma que administra a produção, e de preferência fica em outra conta ou projeto de nuvem.
• Criptografia com chaves guardadas com cuidado. Backup criptografado sem a chave é só ruído. A chave precisa estar acessível para quem vai restaurar, e não só na cabeça de uma pessoa.
• Retenção pensada. Guardar só a última cópia não ajuda quando o problema começou há dias e foi copiado todas as noites. Mantenha pontos de recuperação diários, semanais e mensais, conforme o risco. Considere também o que a LGPD pede sobre eliminação de dados que já não têm finalidade.
• Tudo o que compõe o sistema. Banco, arquivos, configurações, segredos, certificados, filas e agendamentos.

Infraestrutura como código para reconstruir o ambiente

Restaurar dados é metade do problema. A outra metade é ter onde restaurar. Se o ambiente foi montado à mão ao longo dos anos, com ajustes que ninguém documentou, reconstruí-lo depois de um ataque pode levar muito mais tempo do que restaurar o banco.

Infraestrutura como código resolve isso. Servidores, redes, bancos, filas, regras de firewall e permissões ficam descritos em arquivos versionados, com ferramentas como Terraform ou equivalentes. Recriar o ambiente inteiro, em outra conta ou outra região, vira a execução de um processo conhecido, e não um exercício de memória.

Os ganhos vão além do desastre:

• o ambiente de homologação fica igual ao de produção;
• mudanças de infraestrutura passam por revisão, como código;
• o conhecimento deixa de depender de uma pessoa.

Se a empresa ainda roda em servidor local e está considerando a mudança, esse é um dos argumentos mais fortes para fazer a migração de forma organizada, como descrevemos em migrar servidor local para a nuvem.

Teste de restauração com data marcada

O teste é o que transforma o plano de documento em capacidade. E teste bom tem características claras:

• Data marcada no calendário, com responsável, e não "quando der".
• Ambiente isolado, para que a restauração não interfira na produção.
• Cronômetro ligado. O tempo medido é comparado com o RTO definido. Se não cabe, ou o objetivo muda ou a arquitetura muda.
• Verificação de integridade. O sistema sobe, o login funciona, os registros mais recentes estão lá, as funções críticas executam.
• Registro do resultado, com o que deu errado e o que foi corrigido.

Vale variar o cenário a cada teste: restaurar o banco inteiro num momento, recuperar uma única tabela apagada por engano em outro, reconstruir o ambiente completo a partir da infraestrutura como código num terceiro. E, pelo menos de vez em quando, fazer o teste com alguém que não montou o backup. Se só uma pessoa consegue restaurar, o plano depende dessa pessoa estar disponível no dia.

Quem decide e quem executa no dia do incidente

No meio de um incidente sério, a pior situação é todo mundo esperando alguém decidir. O plano precisa dizer, por escrito:

• Quem declara o desastre e aciona o plano.
• Quem coordena a recuperação técnica.
• Quem comunica internamente, a clientes e, quando necessário, a autoridades.
• Quem decide entre esperar a recuperação completa ou operar em modo de contingência.
• Como se comunicar se o e-mail e o chat corporativo também estiverem fora do ar.

Junto disso, um procedimento passo a passo para cada cenário principal, com a ordem de restauração dos componentes, onde estão as credenciais de emergência e como validar que o sistema voltou. Guarde uma cópia desse documento fora da infraestrutura que ele protege.

Se um fornecedor cuida do sistema, os objetivos de recuperação e os testes devem estar no contrato, ao lado do SLA de suporte e sustentação.

Como medir se o plano é real

• Data e resultado do último teste de restauração de cada sistema crítico.
• Tempo de restauração medido comparado com o RTO definido.
• Idade do ponto de recuperação mais recente comparada com o RPO.
• Existência de pelo menos uma cópia imutável ou isolada.
• Quantas pessoas diferentes já executaram uma restauração com sucesso.

Checklist para começar

• RPO e RTO definidos por sistema, com participação de quem conhece o negócio.
• Inventário do que precisa de backup além do banco de dados.
• Pelo menos uma cópia imutável, com credenciais separadas da produção.
• Chaves de criptografia guardadas de forma recuperável.
• Ambiente descrito como código, ou ao menos documentado passo a passo.
• Teste de restauração no calendário, com responsável e registro.
• Papéis definidos para o dia do incidente e plano de comunicação.
• Contas de nuvem, domínios e repositórios em nome da empresa.

Preparado antes de precisar

Na Pervian Tech, recuperação de desastres faz parte do nosso trabalho de cloud e DevOps: definição de objetivos com quem conhece o negócio, backups com cópia imutável, ambiente reconstruível por infraestrutura como código e testes de restauração com data marcada e relatório.

Os objetivos de cada empresa são diferentes, então o plano é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito do que você tem hoje. Se ninguém lembra quando o backup foi restaurado pela última vez, comece por essa conversa.