Time Machine "Event store UUIDs don't match for volume" after swapping disk

4

4

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?

Jules

Posted 2011-10-04T18:23:17.203

Reputation: 381

The problem is that your Mac's disk UUID doesn't match the one stored on the TM volume. You are probably creating a new backup instead of incrementally updating the old one. The solution would involve changing the UUID on the TM volume. I have to look if I can gather some information, should be solvable. – slhck – 2011-10-04T18:43:35.417

That makes sense, look forward to your solution. I did try this http://web.me.com/pondini/Time_Machine/A4.html which deletes com.apple.TimeMachine.plist which hasn't helped.

– Jules – 2011-10-04T18:49:11.990

1It also says Backing up 32kb of 92.25GB after about 20 minutes :( – Jules – 2011-10-04T19:06:41.580

And was this indeed full restore to the old disk, hence completely wiping out the old contents of that old disk? (In other words: just like if it were a totally different disk?) – Arjan – 2011-10-04T19:39:46.507

Yes it was a full restore using the option from the setup program from my grey dvd. – Jules – 2011-10-04T19:45:59.143

It was my original disk that I restored to, the disk provided my with my mac mini, with snow leopard pre-installed – Jules – 2011-10-04T19:46:53.650

@Jules, I assume the full restore wiped anything that was on that old disk. Anyway: your edit clearly shows new event db, indicating that OS X either had no FSEvents database at all after the restore (makes sense) or somehow invalidated it itself because it knew a restore might have messed up with its state. I really think you'll have to wait...

– Arjan – 2011-10-04T19:50:59.360

OK, whats your best guess as to how long it will take ? – Jules – 2011-10-04T19:52:46.530

That may range from a couple of hours to one day (from what I've experienced and read). – slhck – 2011-10-04T19:59:13.777

92GB made me think it was an incremental backup. But: how much data is on your harddisk? – Arjan – 2011-10-04T20:12:03.210

The hard disk is 120gb and about 100gb used. – Jules – 2011-10-04T20:14:58.093

Well, 109.39 GB were requested, and 92 GB after thinning, that should be fine. – slhck – 2011-10-04T20:15:36.740

Ah, that seems like a full backup after all then. If you want to avoid that (but: I guess you might NOT want to avoid it, as you want a good backup to restore to the new disk that you're about to install; waiting now might be more secure...?), see the answer @slhck posted.

– Arjan – 2011-10-04T20:18:37.037

Ooooo it just shot up to 169mb of 95.29gb :) – Jules – 2011-10-04T20:19:05.280

Generally, give it time. I've had my issues with Time Machine as well, and it sort of fixed itself eventually. – slhck – 2011-10-04T20:56:28.280

Copied 42 KB of 88.7 GB, 61 of 340988 items, Copied 161.7 MB of 88.7 GB, 11926 of 340988 items – Jules – 2011-10-04T21:11:20.887

Did this meanwhile complete? ;-) – Arjan – 2011-10-07T14:10:22.517

Answers

9

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.

Arjan

Posted 2011-10-04T18:23:17.203

Reputation: 29 084

Yes it does also say 'Node requires deep traversal'. Since my comment above, 7 minutes ago, it now says 35kb of 92.25GB, at this rate I'll be a year older by the time it finishes ? – Jules – 2011-10-04T19:15:27.043

In fact I started the backup this afternoon and after an hour it had done 52kb. Surely there must be something I can do, or is it lying to me? – Jules – 2011-10-04T19:18:11.037

TM only knows if something changed for each directory. That 92.25GB might be the total size of all changed directories, but the files that have actually changed might be smaller in total. So maybe the 35kb is not really 35kb of 92.25GB. Don't know. – Arjan – 2011-10-04T19:21:49.283

Are you sure it's not the issue in my answer (currently deleted below)? Jules changed their disk, therefore the UUIDs won't match. – slhck – 2011-10-04T19:26:03.803

I've added the full text from TM Buddy to my question – Jules – 2011-10-04T19:31:20.207

@slhck, what I am reading is: changed disk, restored backup (wiping old disk contents; won't include the FSEvents database), waited a week, running backup to same backup disk. Also, the message mentions Event store UUIDs, not disk UUIDs. But I could be wrong... (As an aside: I assume this was a full restore, hence a new FSEvents database.) – Arjan – 2011-10-04T19:34:07.327

(That was a nice answer, by the way, @slhck. But indeed I think it does not apply, but I admit I had to read the question twice before answering, to get an idea of the events...) – Arjan – 2011-10-04T19:35:24.720

I see, you have a point. Maybe I'm confused by the fact that I've had similar issues with different partitions before. "Node requires deep traversal" usually means that things will sort out eventually. – slhck – 2011-10-04T19:35:45.903

By the way: My answer found a new home in case you'd like to quickly peer review it!

– slhck – 2011-10-04T20:02:01.760

Be sure to read that, @Jules. I might have been wrong. (Maybe waiting just gets you a full new backup, rather than an incremental backup!) – Arjan – 2011-10-04T20:15:52.953

Right, erm, can I do that now, confused ? – Jules – 2011-10-04T20:17:50.680

I don't what to advice you, @Jules. Waiting won't hurt. The other trick might speed up things. But if Time Machine feels it cannot safely use the old backup as a base for the backup of your restored Mac, then maybe that's for a good reason. See also Apple's Mac OS X 10.5: Time Machine performs full backup after a full restore.

– Arjan – 2011-10-04T20:27:10.360

1

I found that the UUID issue is resolved and the backup continues after many messages like this:

3/15/12 1:49:35.010 PM com.apple.backupd: Waiting for index to be ready (100)

BUT, only IF there is enough space on the backup drive. My drive was very full, and this 'waiting for index' lasted forever until I reclaimed some space on the drive.

Jack

Posted 2011-10-04T18:23:17.203

Reputation: 11