Um backup que ninguém restaurou é uma hipótese

Quase todas as empresas têm backups. Pouquíssimas têm restaurações. E até que alguém restaure, o que existe não é uma cópia de segurança: é uma hipótese com boa reputação.

O trabalho diário reforça o mal-entendido. O agente de backup informa “bem-sucedido” todas as noites, o painel fica verde e ninguém pergunta mais nada. Mas esse “bem-sucedido” diz que o arquivo foi gravado, não que o negócio consiga voltar a funcionar com ele.

O que aparece na primeira vez que se restaura de verdade

O primeiro teste de restauração de um ambiente que nunca foi testado quase sempre encontra algo. Não porque a equipe tenha feito algo errado, mas porque há coisas que só aparecem ao restaurar:

Dependências que ninguém anotou. O banco de dados volta, mas a aplicação não inicia porque faltam certificados, strings de conexão, tarefas agendadas ou um serviço que ficava em outra máquina.
A ordem. Restaurar a aplicação antes da identidade, ou os dados antes do armazenamento onde devem ficar, transforma uma recuperação em duas.
O tempo real. Acreditava-se que eram “umas duas horas” e acabam sendo seis, quase todas esperando a cópia do armazenamento frio.
O que não estava no backup. Um disco adicionado depois de configurar a política. Uma máquina nova que ninguém incluiu. Um arquivo de configuração que ficava fora da pasta da aplicação.
Quem sabe fazer. Se o procedimento existe só na cabeça de uma pessoa, o plano de continuidade depende de essa pessoa atender o telefone.

Por que vai no contrato, e não nas boas intenções

Um teste de restauração custa tempo das pessoas e uma janela de trabalho. Como tudo o que custa e não é urgente, ele acaba sendo adiado. Por isso, nos nossos serviços gerenciados, o teste trimestral é uma obrigação escrita, com sua evidência e sua data, e não um compromisso verbal: por escrito, alguém tem que executá-lo e alguém tem que verificar que foi executado.

É a mesma lógica de tudo o mais que medimos. A disponibilidade é informada por servidor, com a causa de cada evento; a segurança, com a evolução do Secure Score; os backups, com uma restauração que aconteceu de verdade. O que não é verificado, com o tempo, deixa de ser verdade sem que ninguém perceba.

O que uma política que realmente funciona deveria incluir

Backup separado por tipo de carga: o sistema operacional, a aplicação e os dados não são a mesma coisa, e não têm a mesma frequência nem a mesma retenção.
Retenção declarada em dias, semanas e meses, alinhada ao que o negócio exige e ao que o órgão regulador exige, que nem sempre coincidem.
Uma cópia fora do alcance das credenciais do dia a dia. Um backup que pode ser apagado com a mesma conta que administra o servidor não protege do cenário que mais preocupa.
Teste trimestral com evidências: o que foi restaurado, onde, quanto tempo levou e o que falhou.
Um tempo objetivo de recuperação acordado com o negócio, e não herdado do catálogo do fornecedor.

O valor não é o arquivo: é o número

No fim, o entregável de uma boa política de backup não é uma pasta cheia de cópias. É uma frase que alguém pode dizer em uma reunião sem cruzar os dedos: “se isto cair hoje, voltamos em tantas horas, e sabemos porque fizemos isso em julho”.

Se você não tem esse número, ou tem mas ninguém o comprovou este ano, vamos conversar.