Falha Silenciosa de Backup: Como Ler Logs de Sucesso Que Estão Mentindo
O desafio
Um pedido de restauração acabou de falhar: o arquivo do banco de dados da semana passada não contém nada. A tarefa noturna reportou OK todas as noites e o painel ficou verde o tempo todo, então ninguém percebeu. Conecte-se ao host de backup, descubra pelo cron onde a tarefa grava o log, e leia esse log noite a noite. Uma das noites traz um aviso que se resolveu sozinho, e não é isso que você procura. Você quer a primeira noite em que o arquivo saiu vazio enquanto a tarefa ainda se declarava um sucesso. Envie essa data no formato AAAA-MM-DD.
O que você vai aprender
- Rastrear uma tarefa agendada desde sua entrada no cron até o arquivo de log que ela escreve
- Ler um log pelo valor da sua saída em vez da palavra de status
- Reconhecer falha silenciosa, quando uma tarefa é bem-sucedida mas não produz nada
- Separar um aviso transitório do ponto real de quebra
- Relacionar uma mudança de configuração à primeira noite em que seu efeito apareceu
Habilidades testadas
Pré-requisitos
- Navegação básica no shell com cd, ls e cat
- Familiaridade com o formato de agendamento do cron
Como funciona
As falhas de backup mais caras são as silenciosas. Uma tarefa que trava é percebida em um dia, porque algo fica vermelho. Uma tarefa que termina de forma limpa enquanto produz um arquivo vazio pode rodar por meses, e você só descobre isso no pior momento possível: durante uma restauração.
Este host mostra exatamente esse padrão. /etc/cron.d/backup executa /opt/backup/run.sh toda noite às 02:30 e anexa sua saída em /var/log/backup.log. Toda linha desse log começa com OK, porque run.sh imprime OK incondicionalmente. Ele mede o arquivo com du e conta entradas com tar tzf, depois reporta os dois números, mas nunca os compara com nada. tar sai com código 0 quando arquiva com sucesso zero arquivos, então não há nada para o script ou o painel detectarem.
A evidência, portanto, não está na palavra de status, mas nos números ao lado dela. Até 2026-08-16 cada noite escreve aproximadamente 430M em cerca de 129000 arquivos. A partir de 2026-08-17 toda noite escreve size=0 files=0 dur=0m e ainda diz OK. A causa é uma mudança em /opt/backup/exclude.list datada de 2026-08-16, que adicionou o padrão /* para pular um novo ponto de montagem temporário. Esse padrão corresponde a tudo, então a próxima execução, no dia 17, não arquivou nada.
Erros comuns
- Responder 2026-08-14 por causa do aviso. Aquela noite registrou pouco espaço em disco, mas ainda assim produziu um arquivo de 427M. Um aviso que se resolve não é a quebra.
- Filtrar o log por erros. Não há nenhum. Rodar grep para ERROR ou FAIL não retorna nada e reforça a falsa conclusão de que a tarefa está saudável.
- Responder a data da restauração que falhou. A restauração falhou depois; a pergunta é quando os arquivos ficaram vazios pela primeira vez.
- Responder 2026-08-16. Essa é a data em que a lista de exclusão foi editada e a última noite saudável. O primeiro arquivo vazio é a execução seguinte, no dia 17.
- Parar no log rotacionado.
backup.log.1cobre do final de julho até 2026-08-07 e está totalmente saudável; a quebra está nobackup.logatual.
Como se proteger
Backups só são reais se forem verificados. Monitore a saída de uma tarefa, não o fato de que ela rodou, e comprove a capacidade de recuperação com regularidade em vez de presumi-la.
- Alerte sobre o tamanho absoluto e relativo da saída: falhe a execução se o arquivo estiver abaixo de um piso, ou se desviar muito da média das execuções anteriores.
- Faça a própria tarefa falhar. Faça o
run.shverificar a contagem de arquivos e sair com código diferente de zero quando ela for zero, para que o cron e o painel vejam uma falha real. - Rode testes de restauração automatizados. Periodicamente descompacte o arquivo mais recente em um local temporário e verifique se os caminhos esperados existem.
- Trate padrões de exclusão como entrada perigosa. Revise-os em controle de mudanças e rejeite curingas sem ancoragem como
/*. - Alerte também sobre a ausência de sinal, para que uma tarefa que para de registrar logs completamente seja tão perceptível quanto uma que registra um erro.