Short answer: check the date on the newest file in the backup, not the date on the folder. A folder's timestamp changes for reasons that have nothing to do with a backup finishing.
If the newest file inside it is older than yesterday, the backup has not been running, whatever the tool is telling you.
Most backup advice is about the wrong disaster. It imagines a dramatic one: a disk dies, a laptop is stolen, a flood. Those are rare and everybody understands them.
The common one is boring. The drive was unplugged to make room for something else and never went back. The NAS rebooted after a power cut and the share did not remount. The laptop was closed at the moment the job was due, every night, for a month. A script exited with an error nobody read because nobody reads a log that has been fine for a year.
In every one of those, nothing is broken. No error is raised anywhere a person looks. The backup folder is still there, still full of files, still the right size. The only thing that has changed is that it stopped getting newer, and nothing in the system considers that worth mentioning.
Point this at your backup destination. It finds the most recently modified file anywhere inside it and prints its date:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5The first column is a Unix timestamp. To read it directly:
find /Volumes/Backup -type f -newermt '-2 days' | headIf that prints nothing, nothing has been written in two days. That is the answer, and it is more trustworthy than any status screen, because it is a property of the files themselves.
For Time Machine specifically:
tmutil latestbackupwhich prints the path of the newest snapshot, with its date in the name, or an error if there is not one.
The instinct is to look at the backup folder in Finder and read the Date Modified column. That number is not what you think it is.
A directory's modification time changes when something is added to it or removed from it, and not
when the contents of a file inside it change. Spotlight indexing, a .DS_Store being
rewritten, an antivirus scanner, a cloud client touching its own metadata: any of these can make a
stale backup folder look like it was written to this morning.
The files inside are the record. The folder is not.
launchd job with
StartCalendarInterval does not run while the Mac is asleep, and does not catch up
afterwards unless you asked it to. A laptop closed at midnight has a midnight backup that has
never once happened.launchd job writes its complaint to a file, and the file is the only thing that
knows.If you are doing this yourself, the fix is a dead man's switch: something that complains when a backup has not happened. That is a different event from one failing, and only the first one covers the cases above.
The simplest version is a job that checks the age of the newest file and shouts if it is too old:
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"'
fiRun that on its own schedule, separate from the backup, so a broken backup schedule does not also break the thing watching it. That last point is the one people get wrong: a check that runs inside the backup job cannot report that the backup job did not run.
What you actually want is for the absence to be the alarm, and for the tool to name the thing that is missing.
Copy Shelter is built on that. It tracks when each destination was last written to and last checked, and it speaks up after seven days without a backup that worked. It names the location, so you get "the drive in the drawer has not been seen since 14 August". And because it reads the backup back and checks every piece against the hash it was stored under, a backup that is running but producing unreadable output is also caught, which is the failure one step beyond this page.
The score it shows counts only what has been verified recently. A backup that has not run is not a backup you have, and the number says so.
You should not have to. That is the point of the page: a check you perform by hand is a check you will stop performing, usually about three weeks after you set it up. Automate the absence alarm, and let checking by hand be the thing you do when it tells you to.
It helps, and it is bounded. Time Machine warns after it has not completed a backup for ten days, and the notification is easy to dismiss and easy to stop noticing. It also cannot tell you that the backup it did complete is unreadable, because on a local disk it does not check.
That is the permissions case, and it is nastier because every status indicator says success. Compare the number of files at the destination with the number at the source. If a backup that should hold tens of thousands of files holds forty, macOS is refusing access to the folders and the job is not being told.
Differently, and yes. Sync clients sign out, hit quota, and pause themselves, and the badge that would tell you is a small icon in a menu bar you are not looking at. The files also stay exactly where they were, so nothing looks wrong.
Largely, yes. Two destinations that fail for different reasons, checked separately, is worth more than any amount of monitoring on one. Monitoring tells you the copy is gone; the second copy means it did not matter. See the 3-2-1 rule.
Related: checking a backup is actually readable, and the 3-2-1 rule.