Macos – Time Machine “Event store UUIDs don’t match for volume” after swapping disk

backupmacososx-snow-leopardtime-machine

My new hard drive died the last week and had to put my old drive backup into my Mac Mini, which is running Snow Leopard. I was then able to restore my latest Time Machine backup.

When I upgraded a few months ago I used Carbon Copy and I had permission problems.

So I have my old drive in my system at the moment, but when I try to do a Time Machine backup, it's VERY slow. It's using the same settings / locations as before. I download TM Buddy, which says…

Starting standard backup
Backing up to: /Volumes/Mac Time Machine/Backups.backupdb
Event store UUIDs don't match for volume: Macintosh HD
Waiting for index to be ready (100)
Waiting for index to be ready (100)
Node requires deep traversal:/ reason:must scan subdirs|new event db|
No pre-backup thinning needed: 109.39 GB requested 
      (including padding), 121.15 GB available

I'm trying to do a backup so I can put in another new drive, so I can do a Time Machine restore, like I did last week.

What can I do to fix this problem?

Best Answer

To fix this: wait.

  • After performing a full restore, Time Machine will always create a full backup, by design. Without knowing why Apple thinks this is required, I'd favor a reliable backup over time and disk space. See also Apple's Mac OS X 10.5: Time Machine performs full backup after a full restore.

  • In all other cases: Time Machine has detected that it cannot tell what's on your backup, and what's not, and needs to compare both. You're probably also seeing Node requires deep traversal.

This is not related to the ID of the disk (the hardware) itself. TM keeps the FSEvents ID it used for the last backup in the "extended attribute" com.apple.backupd.SnapshotVolumeLastFSEventID on the disk. Normally, all it takes to determine what has changed is to compare that value to the ID known by OS X. However, if for some reason the OS X FSEvents database can no longer be trusted, it creates a new one, which changes its unique UUID. TM checks to see if the FSEvents database can be used for a specific backup disk by comparing that unique UUID to the UUID that is stored with the backup, in com.apple.backupd.SnapshotVolumeFSEventStoreUUID. So after a new FSEvents database is created, these UUIDs no longer match and TM needs to compare the harddisk with the backup, or might need to create a full backup.

Related Question