Resposta curta: confira a data do arquivo mais novo dentro do backup, não a data da pasta. A data de uma pasta muda por motivos que não têm nada a ver com um backup terminar.
Se o arquivo mais novo lá dentro for mais antigo que ontem, o backup não está rodando, diga a ferramenta o que disser.
A maioria dos conselhos sobre backup trata do desastre errado. Imagina um desastre dramático: um disco morre, um notebook é roubado, uma enchente. Esses são raros e todo mundo os entende.
O caso comum é sem graça. O disco foi desconectado para dar lugar a outra coisa e nunca voltou. O NAS reiniciou depois de uma queda de energia e o compartilhamento não foi remontado. O notebook estava fechado na hora em que a tarefa deveria rodar, toda noite, por um mês. Um script saiu com um erro que ninguém leu, porque ninguém lê um log que está bem há um ano.
Em todos esses casos, nada está quebrado. Nenhum erro aparece em nenhum lugar que uma pessoa olhe. A pasta de backup continua lá, ainda cheia de arquivos, ainda do tamanho certo. A única coisa que mudou é que ela parou de ficar mais nova, e nada no sistema acha que isso vale ser mencionado.
Aponte isto para o seu destino de backup. Ele encontra o arquivo modificado mais recentemente em qualquer lugar lá dentro e imprime a data dele:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5A primeira coluna é um timestamp Unix. Para lê-lo diretamente:
find /Volumes/Backup -type f -newermt '-2 days' | headSe isso não imprimir nada, nada foi gravado em dois dias. Essa é a resposta, e ela é mais confiável que qualquer tela de status, porque é uma propriedade dos próprios arquivos.
Para o Time Machine especificamente:
tmutil latestbackupque imprime o caminho do snapshot mais novo, com a data no nome, ou um erro se não houver nenhum.
O instinto é olhar a pasta de backup no Finder e ler a coluna Data de Modificação. Esse número não é o que você pensa.
A data de modificação de um diretório muda quando algo é adicionado a ele ou removido dele, e não quando o conteúdo de um arquivo lá dentro muda. A indexação do Spotlight, um .DS_Store sendo regravado, um antivírus, um cliente de nuvem mexendo nos próprios metadados: qualquer um desses pode fazer uma pasta de backup parada parecer ter sido gravada hoje de manhã.
Os arquivos lá dentro são o registro. A pasta não.
launchd com StartCalendarInterval não roda enquanto o Mac está dormindo, e não recupera depois a menos que você peça. Um notebook fechado à meia-noite tem um backup da meia-noite que nunca aconteceu nem uma vez.launchd grava a reclamação num arquivo, e o arquivo é a única coisa que sabe.Se você mesmo está fazendo isso, a solução é um dispositivo de homem morto: algo que reclama quando um backup não aconteceu. Esse é um evento diferente de um backup falhar, e só o primeiro cobre os casos acima.
A versão mais simples é uma tarefa que confere a idade do arquivo mais novo e grita se ele for velho demais:
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fiRode isso numa programação própria, separada do backup, para que uma programação de backup quebrada não quebre também a coisa que a vigia. Esse último ponto é o que as pessoas erram: uma verificação que roda dentro da tarefa de backup não consegue avisar que a tarefa de backup não rodou.
O que você realmente quer é que a ausência seja o alarme, e que a ferramenta diga o nome do que está faltando.
O Copy Shelter é construído sobre isso. Ele acompanha quando cada destino foi gravado pela última vez e conferido pela última vez, e avisa depois de sete dias sem um backup que funcionou. Ele diz o nome do local, então você recebe "o disco da gaveta não é visto desde 14 de agosto". E como ele lê o backup de volta e confere cada pedaço com o hash sob o qual foi guardado, um backup que está rodando mas produzindo algo ilegível também é pego, que é a falha um passo além desta página.
A pontuação que ele mostra só conta o que foi verificado recentemente. Um backup que não rodou não é um backup que você tem, e o número diz isso.
Você não deveria precisar. Esse é o ponto da página: uma verificação que você faz à mão é uma verificação que você vai parar de fazer, normalmente umas três semanas depois de configurá-la. Automatize o alarme de ausência, e deixe a verificação à mão ser o que você faz quando ele mandar.
Ajuda, e é limitado. O Time Machine avisa depois de passar dez dias sem concluir um backup, e a notificação é fácil de dispensar e fácil de parar de notar. Ele também não consegue dizer que o backup que ele concluiu está ilegível, porque num disco local ele não confere.
Esse é o caso das permissões, e é mais traiçoeiro porque todo indicador de status diz sucesso. Compare o número de arquivos no destino com o número na origem. Se um backup que deveria ter dezenas de milhares de arquivos tem quarenta, o macOS está negando acesso às pastas e a tarefa não está sendo avisada.
De outro jeito, e sim. Clientes de sincronização saem da conta, batem na cota e se pausam sozinhos, e o selo que te avisaria é um ícone pequeno numa barra de menus que você não está olhando. Os arquivos também continuam exatamente onde estavam, então nada parece errado.
Em grande parte, sim. Dois destinos que falham por motivos diferentes, conferidos separadamente, valem mais que qualquer quantidade de monitoramento num só. O monitoramento te diz que a cópia sumiu; a segunda cópia quer dizer que isso não fez diferença. Veja a regra 3-2-1.
Relacionados: conferir se um backup pode mesmo ser lido, e a regra 3-2-1.