Recuperação de desastre: o que definir antes da estratégia

Backup e recuperação de desastre costumam ser tratados como o mesmo assunto. Backup é uma cópia dos dados. Recuperação de desastre é a capacidade de voltar a operar, o que envolve dados, infraestrutura, configuração, acessos e as pessoas que executam o procedimento.

Dois objetivos que orientam a estratégia

Tempo até voltar a operar. Quanto tempo o serviço pode ficar indisponível sem consequência inaceitável para o negócio.

Perda de dados aceitável. Qual intervalo de informação pode ser perdido entre a última cópia consistente e a falha.

Os objetivos devem ser definidos com o negócio e avaliados tecnicamente quanto à viabilidade, às dependências e ao custo. Eles costumam variar por sistema dentro da mesma empresa. A folha de pagamento e o painel interno raramente exigem o mesmo. Definir um valor único para tudo tende a produzir custo alto em sistemas que não precisam e proteção insuficiente nos que precisam.

Esses objetivos ajudam a comparar alternativas, considerando os cenários de falha e as dependências do ambiente. Objetivos mais exigentes podem demandar recursos previamente preparados e maior esforço operacional. O custo depende da estratégia.

O que precisa ser recuperado além dos dados

Um plano que cobre apenas o banco costuma falhar no momento do uso. Vale mapear:

• Definição da infraestrutura e o que dela existe apenas no console.
• Configuração de aplicação, variáveis e segredos.
• Certificados, domínios e registros de DNS.
• Identidades, permissões e chaves de acesso a serviços externos.
• Imagens de container e artefatos de build.
• Dependências externas e o que acontece quando elas também estão indisponíveis.

Cada item precisa de uma resposta sobre onde está guardado, quem consegue recuperá-lo e em quanto tempo.

Cópias que existem e cópias que funcionam

Uma rotina de backup em execução descreve a cópia, e a capacidade de voltar a operar precisa de verificação própria. Uma restauração testada produz evidências sobre o cenário exercitado. A recuperação do serviço também depende dos demais componentes e das condições da falha.

Pontos que costumam aparecer no primeiro teste real: credencial de restauração que ninguém tem, cópia consistente para um serviço e inconsistente entre serviços relacionados, tempo de restauração muito acima do estimado, e ausência de procedimento escrito para quem estiver de plantão.

Vale definir com que frequência a restauração é exercitada e em qual ambiente, já que o teste consome capacidade e tempo.

Isolamento da cópia

A cópia precisa sobreviver ao evento que motivou a recuperação. Falha de hardware, erro humano e ação maliciosa têm exigências diferentes.

As dimensões a avaliar são separação de conta ou assinatura, separação geográfica, permissões distintas das usadas na operação diária, e proteção contra exclusão ou alteração durante um período definido.

Escreva o procedimento antes de precisar

O documento que importa descreve quem decide acionar, em que ordem os sistemas voltam, quais dependências precisam estar de pé antes de cada etapa, e como confirmar que a recuperação funcionou.

Ordem de retorno costuma ser o ponto mais esquecido: um serviço que sobe antes da dependência dele falha e consome tempo do time durante a recuperação.

Uma revisão inicial

1. Liste os sistemas e defina os dois números com quem responde pelo negócio.
2. Mapeie o que precisa ser recuperado além dos dados.
3. Verifique onde cada cópia está e quem consegue restaurá-la.
4. Planeje e execute, quando autorizado, um teste de restauração em ambiente apropriado, com escopo, impactos e critérios de verificação definidos.

A diferença entre o tempo estimado e o tempo medido costuma ser a informação mais útil dessa revisão.

Práticas de backup e recuperação podem integrar o recorte de um Diagnóstico de plataforma. Testes de restauração e acompanhamento recorrente exigem definição específica de atividades e condições de execução.