A tua cópia de segurança diz que correu bem: como sabes que é verdade?
Em resumo
Um relatório de cópia de segurança diz que um trabalho correu, não que os dados são utilizáveis. As cópias param em silêncio — o trabalho nunca arrancou — e o relatório continua verde ou deixa de chegar. Duas verificações resolvem quase tudo: o trabalho anuncia-se quando termina, e vigias a idade da última cópia boa.
Quase todas as empresas têm cópias de segurança. Menos são as que têm uma cópia que as traria de volta amanhã de manhã. A diferença raramente está no software de cópia de segurança: está em que uma cópia que deixa de funcionar fá-lo em silêncio, e o silêncio é parecido com estar tudo bem.
O que é que um relatório de cópia bem-sucedida prova, na verdade?
Prova que um trabalho correu, e nada mais do que isso. Não prova que os ficheiros estão completos, que o destino tinha espaço, que a chave de encriptação está disponível, nem que alguém conseguiria restaurar a partir dele.
Entre profissionais de informática as histórias são quase intermutáveis, e o que dói são os prazos: um mês sem uma cópia boa porque os alertas iam para a caixa de correio de alguém que já tinha saído; um conjunto de cópias que se descobriu estar corrompido havia cerca de quatro meses, descoberto na hora do restauro; fitas que estavam em branco porque o trabalho nunca tinha chegado a ser posto a correr.
Nenhum desses sistemas estava a gritar por ajuda. Cada um parecia normal até alguém precisar dos dados.
Quais são as duas verificações que apanham quase tudo?
São duas: pôr o trabalho a anunciar-se quando termina, e vigiar um número que diga a idade da última cópia boa.
Primeira: põe o trabalho a falar. No fim do teu script de cópia de segurança, manda-o chamar um URL. Se a chamada não chegar dentro da janela esperada, recebes um alerta. Esta única mudança vira o problema ao contrário: deixas de depender de que a falha seja comunicada, passas a reparar no silêncio. Apanha o trabalho que nunca arrancou, a máquina que estava desligada, o serviço que rebentou, o script que morreu a meio.
Segunda: vigia um número. Põe um pequeno comando a imprimir algo que te interessa — horas desde a última cópia bem-sucedida, ou o tamanho do ficheiro mais recente — e trata esse número como um valor vigiado, com um limite. Um trabalho pode terminar e não escrever nada; um número apanha isso, um relatório verde não.
As duas funcionam em qualquer sistema capaz de correr um comando ou de fazer uma chamada HTTP, o que inclui quase todos os produtos de cópia de segurança, scripts ou agendadores que já usas.
Porque é que o NAS não te salva aqui?
Porque um NAS não levanta o braço sozinho, e o resultado dos trabalhos de cópia não o publica de maneira nenhuma. O próprio guia MIB da Synology afirma que o DSM não suporta traps SNMP: o equipamento não consegue enviar um alerta por iniciativa própria. Pode ser interrogado — saúde dos discos, estado do RAID incluindo degradado e em falha, espaço livre — mas apenas por algo que esteja fora dele e que o consulte.
E o resultado dos próprios trabalhos de cópia de segurança não é exposto de todo. Portanto «o NAS avisa-me» tem dois problemas: só te avisa se for interrogado, e nunca te avisa sobre o trabalho.
O que fazer esta semana
- Acrescenta a linha do anúncio no fim do trabalho de cópia de segurança, e define a janela esperada.
- Imprime um número — horas desde a última cópia boa — e vigia-o.
- Vigia o destino: espaço livre e saúde dos discos, para ficares a saber de um volume cheio antes de o trabalho falhar.
- Marca um teste de restauro. Põe-no no calendário com um nome, não com «alguém devia».
Uma cópia de segurança que nunca restauraste é uma esperança. Uma cópia de segurança que te diz todas as manhãs que continua lá, e que idade tem, é um sistema.
O que não te podemos dizer
- Não conseguimos ler o resultado de um trabalho de cópia de segurança dentro de um NAS: o software NAS comum, doméstico e de empresa, não o expõe pela rede, e não vamos fingir o contrário.
- Não te podemos dizer que uma cópia de segurança é restaurável: só um teste de restauro prova isso.
- Só conseguimos ver o que o teu sistema nos diz: um trabalho que se anuncia, um número que o teu script imprime, ou um equipamento que responde.
As perguntas que se fazem mesmo
Porque é que as cópias de segurança falham em silêncio em vez de darem erro?
Porque a parte que daria o erro é muitas vezes a parte que parou. Um trabalho agendado que nunca arranca não envia nada. Um serviço que rebentou não envia nada. Uma caixa de correio que rejeita o alerta engole-o. O silêncio é igualzinho ao sucesso, e é por isso que tantas falhas duram meses.
Qual é a verificação mais simples que funciona mesmo?
Fazer com que o trabalho de cópia se anuncie quando termina, e alertar quando o anúncio não chega a tempo. Inverte a lógica: em vez de esperares por más notícias que talvez nunca sejam enviadas, passas a reparar no silêncio. É uma linha no fim do script que já tens.
O que devo vigiar além do próprio trabalho?
A idade da última cópia boa, como número: horas desde a última execução bem-sucedida, ou o tamanho do ficheiro de cópia mais recente. Um trabalho pode terminar e produzir um ficheiro vazio. Um número que vigias todos os dias apanha isso; um relatório verde não.
Com que frequência se deve testar um restauro?
Pelo menos duas vezes por ano, numa máquina que não seja a de produção, com um cronómetro na mão. Ficas a saber duas coisas que nenhum relatório te diz: se os dados voltam, e quanto tempo o negócio estaria parado. Escreve as duas.