Testar uma restauração: uma tarefa verde não é prova

As tarefas de backup rodam toda noite e estão todas verdes. Isso prova que o arquivo foi escrito. Não prova que ele pode ser lido, não prova que a máquina lá dentro liga, e muito menos que o serviço daquela máquina funciona. A distância entre essas coisas aparece no dia em que você realmente precisa.

Três níveis de teste

Primeiro: dá para ler? Uma verificação de que o backup está íntegro. É barata, dá para automatizar, e ao menos pega a corrupção silenciosa. Sozinha, ainda não diz "a máquina liga".

Segundo: ela liga? Restaure o backup com uma identidade nova em um alvo de teste, ligue com a rede desconectada e olhe a tela de acesso. A maioria das pessoas nunca chega a esse nível, embora custe uma pausa para o café e ensine muito.

Terceiro: ela faz o trabalho? A aplicação sobe, os dados estão lá, falta a última hora. Em máquinas críticas essa é a pergunta real, porque uma máquina que liga mas liga vazia não salva ninguém.

A regra para testar sem quebrar nada

Restaure sempre com uma identidade nova, nunca por cima da máquina em funcionamento. E faça o teste com a rede desconectada: duas máquinas com a mesma identidade e o mesmo endereço brigam na mesma rede, e o preço não é pago pela sua cópia de teste, e sim pelo original em serviço.

O que as pessoas encontram quando finalmente testam

O que os que testam pela primeira vez encontram é surpreendentemente parecido de uma instalação para outra. O backup tem três semanas porque a tarefa parou em silêncio e ninguém olhou. A máquina liga mas a aplicação pede uma chave que morava em outro lugar. A restauração precisa de mais espaço do que o alvo tem. Nada disso é visível enquanto o backup é feito; tudo é visível enquanto ele é restaurado.

Surpresas na hora de restaurar

Conflito de identidade: esse número já está em uso. Nome do armazenamento: o backup se refere a um nome que não existe mais nesta máquina. Nome da ponte: a definição de rede no backup aponta para uma ponte que este servidor não tem, então a máquina liga sem rede.

Nenhuma dessas é uma falha, são efeitos da mudança. Mas encontradas pela primeira vez no dia de um desastre real, não se distinguem de uma falha.

Frequência e calendário

Um teste de restauração feito uma vez por trimestre vale mais do que uma política de backup impecável que nunca foi exercitada. Amarre o teste a uma data; testes deixados para "quando der tempo" não acontecem. Anote o que você encontrou, porque se o próximo teste encontrar a mesma coisa, o problema não é o backup, é o processo.

O ponto é o ensaio

No dia de uma perda real você não vai ter tempo de aprender nada disso. A única coisa a fazer naquele dia é repetir um trabalho já feito. O teste é o ensaio daquele dia, e é exatamente isso que um ensaio vale.

O que o Atlas faz

O Atlas mostra quais backups existem, onde ficam e quando foram feitos, então a pergunta "eu tenho backup e de quando ele é" se responde olhando em vez de adivinhando. Esse é o primeiro passo do teste acima: garantir que há algo para testar. A restauração em si é feita pelas telas do lado do Proxmox; o Atlas não se mete no caminho, ele torna visível o que você tem em mãos.