Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
An extra-safe (but time-consuming and bit pricy) option would be to start a fresh backup disk. – Thilo May 30 '12 at 9:44

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.

share|improve this answer
How do you set the Time Machine destination to nothing? 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. – Gary Oct 21 '12 at 1:33
Okay so I just used the Time Machine interface and hit "Remove Disk", then re-added it. I still don't get a deep traversal. I know this because the "Preparing backup" phase took 12 minutes, when yesterday I actually did perform a deep traversal when it took 120 minutes to complete, which is exactly what I want now but am unable to figure out how to do so. – Gary Oct 21 '12 at 1:55

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.