After a few kernel panics and an accidental hot-unplugging of my Firewire Time Machine drive, I'd like to make sure that my Time Machine exactly matches my Macintosh HD, much like rsync -a. Is there a way to force Time Machine to do a deep traversal to check that the backup matches?
Knowing how to do this on Leopard, Snow Leopard and Lion would be useful.
Setting the Time Machine destination to nothing and then re-setting it to the same location as before forces a deep traversal for me. You could try rebooting between the changing of the destination and the re-adding it to increase the chance of a deep traversal being triggered.
Worst case, we could muck about in single user mode to destroy the fseventsd directory at a safe time when the system is not counting on it to be correct, so you have forced a new database that won't match. You could presumably delete this from the TM side, but I would remove the boot copy as marginally safer and less prone to destroying data you need or messing up your backup.
If you're inclined to use the command line / terminal, I'd start with tmutil compare before you even thing about forcing a deep traversal. It explicitly compares things as they exist now to the last snapshot and you can force things by specifying a specific external snapshot if you are worried about a local snapshot being compared.
tmutil setdestination requires a path as an argument, doesn't it? (Or I guess just select the backup disk then hit "Remove disk" to de-select it?) I'm stuck in an awful position. Time Machine is creating a new backup whenever I try to backup (I cancel it before it deletes my old backups), so I want to force it to perform a deep traversal so that it sees that most files in fact have not changed since the last backup.
Booting in single-user mode may cause a deep traversal. It did for me once, but not subsequent times. Deleting /.fseventsd definitely will. It should be safe to do this in single-user mode. Deleting /.fseventd on the backup volume did not trigger a deep traversal for me. (My system continued on as normal and never even re-created it.)
tmutil compare is only somewhat accurate. It seemed to accurately identify files that were not backed up at first. I triggered a deep traversal to correct this, but Time Machine is still not backing up many files. Yet tmutil compare now claims that there isn't a problem. I would trust:
rsync --dry-run --itemize-changes --checksum --protect-args -aNHAXx --protect-decmpfs --fileflags --force-change --delete path/to/source_dir/ path/to/destination_dir/
Use /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/ as either the source or destination path. --itemize-changes lets us see what is different; '--checksum' tells rsync to actually compare file contents, rather than just modification times and file size; and --dry-run tells rsync not to actually backup (so it just tells us what it would do). The rest of the arguments are flags telling rsync to make the destination identical to the source in every way, including metadata and HFS compression status. I believe that Time Machine adds bookkeeping metadata which it removes when restoring, so rsync may find spurious metadata changes.
Short answer for at least macOS 10.13.6:
Remove any .inProgress backup from the backup volume. This may require root use of /bin/rm -rf so proceed with caution.
Use the tmutil associatedisk command to rebind the backup volume to the main volume. For example:
sudo tmutil associatedisk -a / "/Volumes/Time Machine Backups/Backups.backupdb/Macintosh HD/Latest/Macintosh HD"
Then start a backup from the Time Machine menu item. In my case, instead of finishing the scan in 10 minutes (clearly not a full scan) and showing a terabyte to backup, the scan took over 30 and the backup size matched what tmutil compare had been saying.
Background:
I needed to force a deep traversal / full scan after an rogue installer (Reallusion) changed the permissions on everything in "/Users/Shared" (about 1 terabyte of otherwise unmodified files). I changed them all back, and tmutil confirmed that time machine did not need to back those files up anymore, but one of two backups disks insisted on using some cached scan that said it did.
Things that did not work:
Removing and re-adding the backup volume from system preferences
Clearing out /.fseventsd
Installing a system update
Removing the .inProgress backup without running tmutil associated disk
Running tmutil associated disk without removing .inProgress
Booting into single user mode, mounting / as read-write, and touching a file
In most cases, the backupd logs would claim to be doing a deep traversal, but would take only a few minutes and then try to backup everything. Here's the command to monitor backupd live on 10.13 at later:
log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info
That will only show new events. To logs from the last three days:
log show --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info --last 3d
