Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: Reconnect Time Machine backup after drive swap System 10.5
This hint is inspired by and uses tricks introduced by the hint Repair Time Machine after logic board changes, and is used for a similar purpose. In this case, I used this hint to re-connect Time Machine after migrating a partition from one hard disk to another one. I know it works with an image copy of your partition.

DISCLAIMER: Do this at your own risk! Have a backup of at least your most important files on a separate medium! Do not attempt this if you are uncertain about any of the consequences or circumstances here! There are no guarantees that the following will work for you!

Start from a different disk if you want to copy the system partition (use the System DVD if necessary). In Disk Utility, select the target disk (which must have been partitioned so your Mac can actually boot from it!), click Restore, drag the target partition to the Target field, and the old partition to the Source field. Don't forget to select Erase Destination, or it will in fact just make a file copy. Progress will then be shown as copying blocks instead of copying files.

The copy will be almost identical to the original -- only the drive ID (UUID) will be different, and that is why Time Machine would try to make a complete backup if we didn't do something to prevent it. I have not tested whether a mere file copy of a partition can be re-connected successfully so that only incremental backups are made. It does seem to work with an image copy, though.

After the image is done, remove the old drive/partition, or otherwise disable it, so that you're not confused by its presence -- all commands that follow will refer only to the new partition, and a change will be made only to a folder in the Time Machine backup.

Important: First, disable Time Machine.

Next, open Disk Utility, select your new partition and press Command-I to display the partition's information. You will need the Universal Unique Identifier value; select it with the mouse, copy it, and paste it somewhere for use later. Then open Terminal and go to the last Time Machine snapshot:
$ cd /Volumes/my_backup/Backups.backupdb/my_mac/Latest
Replace /Volumes/my_backup with the full path to your (new) Time Machine drive/partition, and replace my_mac with the name of your Mac as shown on the Time Machine drive. This directory will hold one (or more) folders, each named after one of your drives or partitions. For safekeeping, display the old partition's UUID before you do anything else -- this is the one that Time Machine has attached to your backups:
$ sudo xattr -p com.apple.backupd.SnapshotVolumeUUID my_partition
Replace my_partition with the name of the partition that you'll be swapping the UUIDs on. The command will print out a UUID, just like the one displayed in Disk Utility above. If the UUIDs are identical (which they won't be, yet), Time Machine will make an incremental backup; If they don't match, it will back up the entire partition again.

So if you are really, really certain that your new partition is in fact just a copy of your original partition, and you want Time Machine continuity, you can reconnect the last backup of your old partition to your new partition by overwriting exactly that UUID with the one of the new partition.

First temporarily disable ACL protection for the backup drive:
$ sudo fsaclctl -p /Volumes/my_backup -d
Whatever you do, do not forget the matching command below to re-enable it again!

Next, and this is the critical step, overwrite the UUID with the UUID you have copied from Disk Utility above (the UUID is represented by the X's in this example):
$ sudo xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX my_partition
Now re-enable ACL protection for the backup drive:
$ sudo fsaclctl -p /Volumes/my_backup -e
Now you can re-enable Time Machine, and it should recognize your new partition as the same as your old one, and only make an incremental backup. When the motherboard of your Mac has changed, proceed as described in the original Repair Time Machine after logic board changes hint.

[robg adds: I haven't tested all of this hint, only the bit about reading the UUIDs off the backup drive, which worked as described.]
    •    
  • Currently 2.86 / 5
  You rated: 2 / 5 (14 votes cast)
 
[84,005 views]  

10.5: Reconnect Time Machine backup after drive swap | 86 comments | Create New Account
Click here to return to the '10.5: Reconnect Time Machine backup after drive swap' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Reconnect Time Machine backup after drive swap
Authored by: Soybean on Feb 19, '09 09:09:30AM

Interesting. I simply cloned my hard drive (using Carbon Copy Cloner) when I was upgrading my MacBook Pro from a 250GB to a 500GB drive. Time Machine performed an incremental backup without any issue (other than my having to unplug and replug the drive into my Airport Express Base Station).



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Feb 19, '09 09:22:48AM
You probably had it make an identical disk copy block-by-block which does indeed keep the connection to the backup but it could produce problems when both drives are present at the same time or alternatingly while the "hinted" solution still keeps them apart properly.

If it's just about 1:1 replacement with immediate removal / erasing of the old partition, that is certainly an option if you're really careful. It would get problematic when you chose to swap the drives again later on — Time Machine would then "back up" the difference between the newer drive and the older one, probably "removing" all the files in the newer backup which you had created since the switch to the new drive. And Jobs only knows what would happen if both drives were present at the same time!

In my case I simply wasn't inclined to spend another several hours on a new copy of the disk after I had already been through it with Disk Utility.

There just had to be another way around the problem, and indeed there seems to be! ;-)

---
There are no problems...

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Feb 19, '09 09:41:25AM
I forgot to add: The "hinted" solution probably also works on a file copy of a partition, not just on a block copy. I have not tried that one out myself, but from the way things work it is conceivable that even a file-copied partition could be re-connected which would certainly not work otherwise.

---
There are no problems...

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: wch on Mar 02, '09 07:28:23PM

I just did a file copy of a partition using Carbon Copy Cloner, and the new partition received a new UUID, so I used the hint above. It seems to have worked -- the first backup size is only 60.7MB, after maybe 25 minutes of "preparing". The backup is running now, although it seems to be going quite slowly; after about 10 minutes, 5.5MB has been backed up. Hopefully things will be faster the next time around....



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: wch on Mar 02, '09 09:25:36PM

Update to my previous post: subsequent backups seem to run at normal speed.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 10, '09 09:06:27PM

That is because OS X keeps a record of files which have been changed recently, but this record is not infinite.

Time Machine uses this record if it can — but when it suspects that the record does not contain all the changes made since the last backup it will do a "deep traversal", basically looking at every file on both disks and checking whether it needs to be backed up or not.

After you've made your copy, the change record on the copy was not deemed consistent and complete, so it took the long road on the first backup.

After that, however, Time Machine was back in sync and on the following backup it could use the change record which was much faster.

If you should have a long gap between subsequent backups, Time Machine may still revert back to deep traversal, but that is normal and will "fix" itself automatically when the backups are closer together again.

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Feb 19, '09 11:07:39PM

In the comments of the aforementioned hint, 10.5: Repair Time Machine after logic board changes, I wrote about the value of the cookie which has to be the same on both drives, and should match the contents of the file /var/db/.TimeMachine.Cookie on your Mac. Maybe the UUIDs are important too, but in my case I simply used Finder to copy the sparse bundle and the hidden cookie file, and that was it.

Note that my set up uses a sparse bundle on USB drives connected to a Mac Mini, which are used for my MacBook Time Machine -- I never tried with attaching the drives directly to the MacBook.

If these cookies do not match then the logs will show Volume at path /Volumes/TM does not appear to be the correct backup volume for this computer. (Cookies do not match), so for whoever sees that message: for you the UUIDs are not important (and fixing those might not help); see the earlier hint.



[ Reply to This | # ]
10.5: Use multiple drives for Time Machine backups
Authored by: palahala on Feb 19, '09 11:17:02PM

By the way: I swap those two drives all the time; I use Time Machine with multiple disks. No problems (but, again: things may be different when connecting the drives directly to your Mac -- post your results here!).



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Feb 20, '09 02:03:59AM
You seem to refer to a different situation.

Basically I can think of three different issues here:

- Swapping the motherboard (that was your hint)

- Swapping the backup disks (that seems to be what you're referring to above)

- Swapping the original disks (that is my hint above)

---
There are no problems...

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: bll on Feb 20, '09 04:39:36AM

I faced the same problem by just reinstalling the system on the same drive, after reformating the drive. Reformating updated the UUID and Time Machine wanted to redo a full copy. By using the same trick (shame on me, I did not publish it), I was able to get the intended behavior.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Feb 20, '09 05:47:53AM

Well, at least that's an independent confirmation! ;-)


---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Feb 20, '09 12:19:03PM

Aha, indeed it was not clear to me that you swapped the (source) disks in your Mac that uses Time Machine (not the target disks that you use to store your Time Machine backup).

Now that you explained about this UUID, I'd imagine that the content of /var/db/.TimeMachine.Cookie might somehow be related to the UUID of the drive that is the source for the backup. On the other hand, in the Unix world, I'd expect Time Machine to back up file systems that are actually located on multiple drives (like /home could be on some other drive than the other folders). If that were true then the UUID of a single partition should not matter. But given your hint, I assume that Time Machine in fact does rely on that UUID, and thus cannot create backups of file systems that use multiple drives...

Just for the record: the 10.5: Repair Time Machine after logic board changes hint was not mine; I just commented on it.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Feb 20, '09 10:07:05PM
palahala: Aha, indeed it was not clear to me that you swapped the (source) disks in your Mac that uses Time Machine

Okay.

palahala: Now that you explained about this UUID, I'd imagine that the content of /var/db/.TimeMachine.Cookie might somehow be related to the UUID of the drive that is the source for the backup.

That sounds plausible... It is probably used to detect the connection of the currently selected backup drive ("Change Disk" in Time Machine preferences probably re-sets it).

palahala: On the other hand, in the Unix world, I'd expect Time Machine to back up file systems that are actually located on multiple drives (like /home could be on some other drive than the other folders). If that were true then the UUID of a single partition should not matter. But given your hint, I assume that Time Machine in fact does rely on that UUID, and thus cannot create backups of file systems that use multiple drives...

Or at least not directly... especially when I think of FileVault I would expect that that is intentional. But since Time Machine is ultimately based on a souped-up version of rsync, maybe a closer look to its manual can give some information about that aspect.

And with the imminent introduction of ZFS the entire Time Machine mechanism may get a significant overhaul anyway.

palahala: Just for the record: the 10.5: Repair Time Machine after logic board changes hint was not mine; I just commented on it.

Yeah, I've just noticed that after posting. :-)

---
There are no problems...

[ Reply to This | # ]

Not Mac-like...
Authored by: rgray on Feb 20, '09 06:42:13AM

It seems to me that this TM problem and the solution(s) are very unMac-like.. and a flaw in the whole TM concept that makes TM difficult for the less technically astute users. The problem stands in gross contrast to the way TM works generally to find and restore files. What would be wrong with having TM work so that one could just navigate to the desired 'archive' and double click to use??? Or am I missing something. The way it is most of my clients would be lost if a drive or a mobo was changed and that does not seem fair - besides as I said before it stands in gross contrast to the rest of the Mac experience.



[ Reply to This | # ]
Not Mac-like...
Authored by: only_solutions on Feb 20, '09 07:53:31AM

I can see where you're coming from, but Apple apparently went the way of the lowest risk (at least on the face of it).

When you're presenting a new harddisk to Time Machine, it is treated like a different harddisk. If you could assign it manually to an older backup you could wreak real havoc in case that assignment was really a mistake.

So they apparently erred on the side of caution, restricting the possibilities to accidentally mash together what's in fact not the same thing. In my case I was certain enough that it should work okay and I assumed the responsibility for any undesirable outcome; But many users would block the support hotline and/or threaten to sue because of data that was at least apparently lost to them.

On the other hand I would have lost older copies on my TM backup drive if I had just let it make another entire backup instead of a compact incremental one. Neither solution is perfect, both have their flaws and risks.

---
There are no problems...



[ Reply to This | # ]
Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: palahala on Feb 21, '09 01:11:10AM

I wonder if Time Machine will continue making incremental backups when restoring a backup to a new drive. If true, then for those who are still planning to swap the drive of their Mac for another drive: maybe a full system restore from Time Machine to the new disk will save you from having to change the UUID.

And when doing a full restore to a new disk, I am curious if Time Machine will then change the UUID of the target disk (which would not make it very unique then...) or on the backup disk.



[ Reply to This | # ]
Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: only_solutions on Feb 21, '09 01:33:04AM
According to Apple Support (yes, I actually asked them about it! ;-) ) a restore from a Time Machine backup does unfortunately result in a completely new full backup being made right again which is obviously stupid, but consistent with the way the mechanism seems to work.

I'm with you in that, of course: They should either adapt the UUID in the backup or have a separate mechanism for this purpose to avoid such a pointless double backup. It actually reduces data security because the pointless double backup pushes older backups off the disk if there's not enough space plus of course it stresses both the original and the backup harddisks much more than necessary.

On the other hand having multiple drives with identical UUIDs looks like a really bad idea – too many potentially serious consequences could ensue.

So if this information is in fact true (can anybody attest to that who has made a Time Machine restore and tried to resume Time Machine backups to the same drive?), this hint here could be very useful in that case as well.

---
There are no problems...

[ Reply to This | # ]

Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: palahala on Feb 22, '09 01:54:33AM

Giving it some more thought, I can image some people might restore a backup on another drive just for testing or whatever. One indeed does not want this to result in changing some UUID in the backup, as that would render that backup useless for the original drive.

So I guess your solution is better than having Time Machine decide when to make some changes: only people who know for sure they want the UUID of the backup changed will now be able to do so, and those will understand that removing that sticker will void their warranty ;-)

Many thanks for the info!



[ Reply to This | # ]
Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: only_solutions on Feb 22, '09 06:34:59AM

You are probably right...!

And you're welcome; Of course I owe most of the thanks to this site and to other contributors. :-)

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: logo on Mar 11, '09 01:48:52PM

Hint is really appreciated.

Worked exactly as described after my drive swap and copy from old to new drive with disk util.

Thanks a lot.



[ Reply to This | # ]
Only worked for me after a small modification
Authored by: yumbrad on Mar 12, '09 12:05:14AM
I'm not sure why this was needed, since it really should be basing it's work on the "Latest" backup (which I verified was pointing at the last date-stamped dir in the TM bundle), but I needed an alternate step. I tried the tip as is initially, and it failed with not enough room, as from console I saw it requested 300GB (all my files). Instead of the one "sudo xattr -w" step, I had to do this:

for d in ../*; do sudo xattr -p com.apple.backupd.SnapshotVolumeUUID $d/Macintosh HD/ ; done

After this, it still had to do a "deep traversal" because the "Event store UUIDs don't match for volume", but once it did, instead of the full 300GB, it only requested 600MB or so - back to incremental backup!

[ Reply to This | # ]

Only worked for me after a small modification
Authored by: only_solutions on Mar 12, '09 01:32:21PM
That is a bit strange, since your command only displays the IDs, but it does not change them.

Maybe you just hadn't switched Time Machine off before making the change, so it might have cached the old ID and just took a while until re-reading it eventually.

But anyway, good to hear the hint has been of use to you. :-)

---
There are no problems...

[ Reply to This | # ]

Only worked for me after a small modification
Authored by: yumbrad on Mar 12, '09 10:25:56PM
Whoops! Sorry - I pasted in what I used to display the UUIDs before and after. The step I replaced looked like this of course:

for d in ../*; do xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX d$/my_partition; done

And yes, thank you very much for posting this tip - quite serendipitous as I just upgraded my iMac drive from 500gb to 1.5tb. So now I'm using three non-Apple-officially-supported methods that work great together - your seamless drive upgrade tip, the one to stick my time machine backup on an "unsupported" network share (Unraid server), and one to manually limit the size of that TM bundle... Pretty soon I'll think of hdiutil as a good old friend, and won't think of these as unsupported workarounds :) ... MacOS is my third OS to learn after DOSWindows and linux, and I'm liking it!

[ Reply to This | # ]

Only worked for me after a small modification
Authored by: only_solutions on Mar 13, '09 04:56:58PM

Ah, that's more like it. ;-)
I still can't say why you needed to do that.

Undocumented procedures can be fun... as long as one never forgets that greater power comes with greater responsibility...! 8-)

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: alexliz on May 25, '09 04:55:31AM

I get stuck at the step which displays the old UUID. All I get is a complaint from Terminal, "No such xattr: com.apple.backupd.SnapshotVolumeUUID"

I've tried different variations of what I understand the command might be, all to no avail. What could I be doing wrong?

Many thanks!

---
Alex



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: TigerKR on Jun 08, '09 01:09:23PM

This is a great hint. I was able to use this hint to have TM continue to backup an external drive that I cloned to a new external drive (to get a larger capacity). Thank you!



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Jun 08, '09 01:38:14PM
Good, though I guess there are easier guides to achieve just that, like A Bigger Time Machine without Changing History.

[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Jun 10, '09 02:38:25AM
More details on Time Machine's extended attributes such as com.apple.backupd.SnapshotVolumeFSEventStoreUUID, com.apple.backupd.SnapshotVolumeLastFSEventID and com.apple.backupd.SnapshotVolumeUUID at Quarter Life Crisis: X.5 Time Machine.

[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: wjwt on Jun 11, '09 02:27:39AM

This is a great hint, works perfectly. Replaced the original 40GB hard drive (!) in an old G4 Quicksilver with a new 80GB drive, and TM wanted to back up 31GB (i.e. the entire contents of the drive). Used this hint exactly as described, and the backup dropped to 2.7GB. As another poster noted, took a long time "Preparing backup..." the first time, but subsequent backups are back to normal. Excellent hint -- thank you. I agree that it's surprising that Apple hasn't provided a more user-friendly way of doing this -- replacing original drives isn't uncommon!



[ Reply to This | # ]
No need for this!
Authored by: sunsetchaser on Jun 11, '09 07:30:55AM

I just spent a couple of hours banging my head against the wall because I couldn't believe Time Machine would handle a new drive so poorly!

Then, on a whim, I restarted my Time Capsule. Lo and behold, all my old backups appeared when I entered Time Machine. Backup status was missing -- no information about oldest backup, latest backup -- so I clicked "Back Up Now", and waiting 15 minutes while it said "Preparing backup". It did then start creating a new backup in the same location as the old backups, and entering Time Machine still showed all the old backups.

*However*, it said the size of the backup to be done was 99 GB -- about 25 GB less than the actual amount of data on my hard drive. Maybe that's everything but the OS itself? Who knows, but...

Bottom line is, no monkeying around in Terminal is necessary if all you care about is access to your old backups, *and* if you have plenty of space on your Time Machine drive. Looks like a simple restart won't save you from having to do another almost-full backup though.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: markauk on Jun 16, '09 05:36:11PM
Thanks only_solutions for the tip and yumbrad for the modification, which I needed to make it work for me. I think you have a small typo in what you suggest, though, it should be:-

for d in ../*; do xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX $d/my_partition; done

At least, I had to change d$ to $d to make it work for me.

[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: PeeWee on Jul 15, '09 07:06:16AM

Fantastic! Although I'm not a Terminal pro at all, I managed to reconnect my backup with this guide. Since I moved my Data from one MacBook Pro to a new one using Migration Manager, I did the logic board / MAC re-pairing in the same time.

Just a notice about how long the first backup after the action took: It was remarkable 36 hours in my case to write about 8 GB, but extremely slowly. Believing something went wrong, I was close to abandon it, but resisted. Since then all further backups work as fast as usual.

Thanks a lot
PeeWee



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Jul 15, '09 08:56:01AM
Since I moved my Data from one MacBook Pro to a new one using Migration Manager, I did the logic board / MAC re-pairing in the same time.

I don't want to spoil your success, but... So, you've used the Migration Assistent to copy your documents and some more (but not the whole system), after you installed Mac OS X (or, onto a system that had OS X pre-installed)? If so, then the old (and now current) backup is simply not a good representation of your current Mac. Thus: you might not be able to use it for a full restore!

I'd say this hint is only safe to reconnect a backup to its original hard disk.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Jul 15, '09 09:28:13AM
Though the 36 hours deep traversal may have fixed this after all...? In that case a full system restore may be possible, using this new backup or any newer backup (but not using backups that were created before the deep traversal, as I think those certainly do not match your current Mac).

[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: PeeWee on Jul 15, '09 03:07:23PM

Thanks for your reply. My priority was to get the new machine ready to work as fast as possible. I first did a block copy clone of my entire HD onto that last generation MacBook Pro, but it wasn't really satisfied with my System. That's why I migrated it, yes the whole, while I cloned the Time Machine Partition to another Disk before starting to fumble on it.

I will (try to ;-) ) do a full restore onto another disk asap. Wanted to try that anyway. Will let you know.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: luhmann on Jul 17, '09 04:15:09AM

I took a look at this, and thought: Surely this is not the Apple way? Sure enough, one can simply hold down the option key when selecting the time machine menu icon and one will see an option: "Browse Other Time Machine Disks" instead of "Enter Time Machine." Doing it this way you can restore from your previous backup without having to do ANY of the steps mentioned in this hint or the previous hint about new logic boards.

Of course, browsing an old backup is not the same as "reconnecting" in that Time Machine won't simply pick up where you left off. Best to buy a new drive, they are cheap enough, and save yourself the trouble. I know for a some people the above steps may not seem like trouble, but I believe most users will prefer to just hold down the option key to restore from a backup made on a previous computer/hard drive/logic board, and start over with a new backup after the switch.



[ Reply to This | # ]
As if ever hints here were for 'most people'
Authored by: hamarkus on Sep 30, '09 05:23:50AM

A large proportion of hints here are not what 'most people' would do.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: david29 on Aug 02, '09 11:33:23PM

I am amazed that no one has written some type of script or small app to handle this issue. I would gladly pay a few dollars for a solution.

I have tried the method on the page several times but cannot seem to get it to work. I am giving it another shot. Wish me luck!



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Aug 03, '09 12:22:09AM

Hmmm, for a moment I thought you're also known as hartmut... ;-)

Please note that this only applies when using the exact same harddisk contents. You should not do this to associate an old backup with a new Mac. I guess that limits the market for fool-proof fully automated solutions. There's a script for the original hint though: 10.5: A script to fix Time Machine after hardware repairs. But some troubleshooting skills are required in case things fail, so I'd not really recommend such script if the manual steps are too difficult.



[ Reply to This | # ]
"Reconnect" Tip Broken under 10.6
Authored by: WaltFrench on Sep 27, '09 05:58:28PM
This hint seems completely undone under 10.6.

First, fsaclctl seems to have gone missing. Some posts suggested there's a replacement fsacl but no man page that i could find.

Second, I'm concerned that the output of xattr showed 37 hex pairs, not the 32 hex digits and dashes. By the looks -- I've forgotten all my ASCII -- it is a hex representation of the actual hex UUID (43 41 ...) and its dashes (2D), terminated with 00. That's arguably the same as the UUID, but not quite close enough to give me the warm & fuzzies.

So, a show-stopper. Has anybody figured out how to proceed under Snow Leopard?

"Inquiring Minds Want to Know!" ©

[ Reply to This | # ]

Maybe I have a solution
Authored by: hamarkus on Sep 30, '09 03:32:51AM

From what I have gathered, an extended attribute in Snow Leopard can have as a 'default' representation hex OR ascii.
(1)Take a screenshot and run xattr -p com.apple.metadata:kMDItemScreenCaptureType Screenshot.png on it. You will get a hex representation. Run xattr -l on it and you get both hex and ascii.
(2) Create a new textfile in TextEdit and run xattr -p com.apple.TextEncoding File.txt on it. You will get an ascii representation of it. Run xattr -l on it, and you still get only ascii. Run xattr -px or xattr -lx on it and you get both hex and ascii.

This what I mean by having either a hex or a ascii representation as a default. Now how can be set things for both variants? The simple xattr -w nameofattribute value filename sets an attribute with ascii at the default view. But xattr -wx nameofattribute "valueinhex" filename sets an attribute with hex as the default view.

So far, pretty straightforward. But most extended attributes with hex as the default view run into multiple lines. I have so far only found somewhat of a kludge to set these: Create a multi-line environment variable in hex form and use this together with -wx. I'd be glad if somebody showed me a more elegant way of doing this.

Whether that makes this hint workable under Snow Leopard, I do not know.



[ Reply to This | # ]
Forget about that environment variable kludge
Authored by: hamarkus on Sep 30, '09 06:15:57AM

These newlines are not actually new lines. Just enter the full hex string as an argument to -wx.



[ Reply to This | # ]
"Reconnect" Tip Broken under 10.6
Authored by: majorminor on Oct 08, '09 05:46:36PM
My MBP was replaced with a iMac and opening Time Machine gave this;

http://img.skitch.com/20091009-1xn7hqrdcfmjxhxm8mmswgcw2s.jpg

which may work for Drive Replacement but guess it depends if it picks up the new MAC for the HD

---
honi soit qui mal e pense

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: mwittle on Oct 09, '09 12:54:23PM

I swapped my disk using the Disk Utility restore method, using the erase disk option, and that worked fine. Result was that the Time Machine sparsebundle file is now on a 1-TB drive instead of a 200-GB drive. Time Machine then ran fine nightly for a few weeks.

HOWEVER, now Time Machine posts an error message each night telling me that the disk is out of space, and is removing old backups, even though the disk still has 700-GB of space. How do I get Time Machine to recognize that the sparsebundle is now on a larger drive?



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: badtux on Nov 07, '09 09:46:34PM

This doesn't appear to work under Snow Leopard. Problem #1: fsaclctl does not exist in Snow Leopard. Solution: Install /usr/sbin/fsaclctl out of the Leopard install disk that came with my Macbook Pro, from /Volumes/Mac OS X Install DVD/System/Installation/Packages/BSD.pkg , using whatever pkg extractor you desire (I used Pacifist) to make it work (extract only the single file, not the whole thing!). Problem #2, even after executing the commands in question with the up-to-date disk UID, Time Machine did a full backup of my just-restored data anyhow the next time it ran. So obviously something changed in Time Machine between 10.5 and 10.6 that broke this hint. Sigh!



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: Bartsch Labs on Nov 26, '09 05:17:49PM

Confirmed that this doesn't work with Snow Leopard 10.6.2.

I did the steps (including locating fsaclctl), converting the UUID string to 36 hex pairs (using this converter http://www.apnapakistan.110mb.com/string__ascii.html), and adding 00 to the end. TM still does a full backup of 113GB instead of an incremental.

Maybe after the backup is done I'll check the UUID of the backup to see if it matches the value that I set the Latest backup to be.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: DougEdwards47 on Dec 10, '09 09:03:03AM

Works for me on 10.6.2
Just used the ASCI equivalent of the hex string that xattr reports report. There seems to be no way to add the trailing NULL character (00) - as I expected and it didn't appear again when I checked that the UUID attribute again. However, TM only did an incremental backup!



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: volmacman on Apr 10, '10 01:51:07PM

I was able to get the ASCII UUID from the old HD by simply mounting it in an external USB case and using Disk Utility Get Info. No need for converting the hex to ascii if you can still mount the old partition.

(10.6.3, having copied fsaclctl to usr/sbin/ using Pacifist from a Leopard DVD)



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: rkusa on Dec 11, '09 09:47:21PM

I have not been able to get this to work at all. I feel like I must be missing something. When I try the command to display the UUID from the Time Machine backup, I either get a reply like -bash $ command not found or something like that. So I've tried, on command lines where my admin account name is followed by a $, to just start the command leaving out the $. That gives me various results. Mostly I get nothing.

To get the paths to the partitions or drives, I've been dragging the icon into TextEdit so it fills in the path for me, copying and pasting it into the command given in the example.

I never could get any UUID to display from the command line. I found the Time Machine and the new source drive UUIDs from Disk Utility Info.

I pasted into Terminal the ACL command to disable,

then I pasted the new drive's UUID into the command to change the UUID,

then pasted that command for changing the UUID into Terminal,

then pasted in the ACL command into Terminal to reenable.

I hit Return after inserting each command. In each case, there was no response in Terminal after each action just a > symbol. I tried the alternate (corrected) command posted by markauk, and got a string of not found errors for each backed up volume on TM plus Shared and a couple of other things.

I also tried the script that someone referred to, and it gave me a reply that my drives are already paired, but I know that's not true because it keeps wanting to do a complete backup from scratch.

I hope someone here can tell me what I might be missing in this whole thing. BTW, I'm using 10.5.8. Any help will be greatly appreciated.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Dec 27, '09 02:44:53PM
You need both command-line tools to get this done: xattr and fsaclctl You can check for their presence with these commands:

sudo which xattr

sudo which fsaclctl

If either of these is not found, you'll need to get it first.

fsaclctl is no longer part of the system under 10.6, so it must be restored from a 10.5 backup; But it is a bit crude anyway when I've got some spare time I may check out the proper way of removing and restoring the extended attributes for each file individually.

---
There are no problems...


[ Reply to This | # ]
Update: Moving from PPC to Intel and from 10.5 to 10.6 and still keeping the backup!
Authored by: only_solutions on Dec 27, '09 04:12:10PM
Update: I just reconnected my new Intel Mac under Snow Leopard to the Time Machine backup after using that same backup of my G5 under Leopard before to transport my whole installation.

Disclaimer: Like the original hint, this is not for the faint of heart and if at all it should only be attempted after making sure there are additional backups besides the Time Machine backup we're fiddling with! I may have made grave mistakes in my conclusions and I may yet lose all data on my machine and on my backup by manipulating internal undocumented structures. It does not look like it to me at this time, but that is the inherent risk!

When I installed my new Intel Mac, I chose the offer to install it from my existing Time Machine backup. Even though the backup was from a PowerPC Mac, it went through without a hitch (well, some aditional Unix binaries had to be reinstalled separately, but that was to be expected).

So I ended up with a new Intel Mac which had basically a clone of the old G5 installation, with all applications, user data and preferences. So far so good but of course Time Machine would not have let me re-use the existing backup history across the machine swap. But we're here to not let little things like that stand in our way, aren't we? ;-)

My first step was to make an image copy of my entire Time Machine backup disk. In Disk Utility I chose Restore from my regular backup disk to a spare backup disk with the Option Erase destination active this is what makes Disk Utility do an actual image copy (A Time Machine backup would be garbled by making a file copy).

Please note that in case this spare copy was ever to be re-attached to an active machine, this hint would need to be used again, but we sure hope this won't be needed. (For me this was the better way to go, but you may be better served by making the image copy and then attaching the image copy to your new Mac instead of the original, which could then still remain with the old Mac or just be kept for safety.)

I also made an additional copy of my user folder to a separate backup medium. We're dealing with a backup mechanism here and we're making undocumented changes this is serious stuff and one definitely needs to take precautions.

So now the fun begins:

I basically used the above linked hint 10.5: Repair Time Machine after logic board changes to make the Time Machine backup accept my new machine (in the process renaming the folder within the Backups.backupdb folder on the backup drive to my new machine's name that works too!).

(Hint: I had to copy over the fsaclctl tool from the backup since it is apparently no longer present under 10.6. It worked as described, but in future it may be better to deal with the ACLs individually instead of using the sledge hammer of unhooking them completely on the entire drive and later activating them again. That is kind of crude!)

I then used this hint here to reconnect Time Machine on the new Intel Mac to the "old" TIme Machine drive with all its existing backup snapshots.

As a result, when I enabled Time Machine on the new Mac for the first time, it obviously had to do a deep traversal of the virgin file system (from Time Machine's point of view) and it predicted a pretty hefty backup size, but it nevertheless accepted the G5's backup snapshots as legitimate basis and ultimately just backed up about 17GB after all, which is in line with a completely new system (Leopard -> Snow Leopard), some changes in the folder structure I made between the two machines, a newly converted mail base under Snow Leopard plus some work I've done between migrating to the Intel Mac and actually reconnecting Time Machine again.

I guess I'm not the only one to switch from a PowerPC Mac to an Intel one and in the process migrating from Leopard to Snow Leopard and I'm probably not the only one who'd be bugged by losing one's entire Time Machine history over that.

But at least at this point it looks to me as if there's actually a way to move and to still keep the time line intact and usable. I just hope messing with the internals won't still bite me somewhere down the road... 8-) (I'm keeping an eye on the backups actually being made correctly now one cannot be too cautious!)

---
There are no problems...


[ Reply to This | # ]
Update: Moving from PPC to Intel and from 10.5 to 10.6 and still keeping the backup!
Authored by: only_solutions on Dec 27, '09 06:46:43PM

Addendum: After the first incremental backup the next backups were empty despite changes being present on the Mac.

A restart of the Mac apparently cured that as well. Which sounds like a good idea anyway when making such changes.

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: joelq on Dec 29, '09 10:23:45AM

Hi all -

I just performed a drive swap this morning (upgraded my iMac 24" to a 2TB Hitachi), and the upgrade went well. Prior to the upgrade, I cloned the original drive with Super Duper.

I just restarted Time Machine and noticed it was doing a full back-up (roughly 400GB) instead of just an incremental, and a quick search landed me on this hint.

I'm afraid that interrupting the full backup then applying this hint will leave things a mess, or will it be OK?

If I just let the full backup complete, is there a way I can go back and remove the duplicates without losing my history?



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Jan 01, '10 03:54:31PM

As far as I can tell, you can just switch off Time Machine and delete that unwanted full backup and the "Latest" alias which was pointing to it.

You can also just stop a backup in mid flight by switching Time Machine off while it is working.

Each backup snapshot is first done as a package pseudo-file as long as it is not complete. Only when it is finished successfully, it will be turned into a regular folder and renamed from <timestamp>.inProgress to just <timestamp>.

If you have interrupted a backup, this temporary package will be left behind. You can just delete it as well.

After that you can then apply this hint to re-adopt the previous backups to your new machine

From my experience Time Machine should then recognize your previous backup and only make incremental snapshots again.

Of course as I have explained above, this is kind of critical, so please make sure you have additional backups of your important data at hand on separate media.

Good luck! :-)

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: joelq on Jan 03, '10 03:34:09PM

Thanks! I decided to just let the backup finish. I figure, TM will eventually expire that backup and it should free up ~400GB some day.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Jan 03, '10 03:42:38PM

Yes, it will.

The main reason why I wanted to adopt my previous backups was that I wanted to keep as much as possible of the time line accessible for as long as possible.

The big chunk of another full backup will lead to a much earlier retirement of the oldest backups.

But if that is not seen as a big problem, it should be no problem to just let it run through.

The operations described above are indeed kind of challenging, so staying on the safe route is not a bad choice in itself.

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: cleeland on Jan 04, '10 10:15:16AM
I found that this hint was insufficient to reconnect my migrated-to hard drive to my existing backups.

The first thing missing was that in addition to replacing the UUID in the SnapshotVolumeUUID xattr, I also needed to replace the UUID in the SnapshotVolumeFSEventStoreUUID xattr. The UUIDs, however, are different.

The UUID required for SnapshotVolumeFSEventStoreUUID comes from /Volumes/my-volume/.fseventsd/fseventsd-uuid, e.g.,


bash-3.2# cat /Volumes/bobke2/.fseventsd/fseventsd-uuid 
C422D468-07D4-4669-A9D8-5D3665B3D091bash-3.2#

NOTE:the UUID ends in "1" above, just before the 'b' in the bash prompt.

Also, the value for these attributes appears to require the trailing zero byte. I could not figure out how to get the xattr command to add that zero byte, so I wrote the following C program to do it using the setxattr() call. If you do not know how to compile and run a C program then this may not be for you. Use this at your own risk; I assume no risk and make no promises. I will not provide binaries.


#include <sys/xattr.h>
#include <stdio.h>
#include <string.h>

/*
     int
     setxattr(const char *path, const char *name, void *value, size_t size,
         u_int32_t position, int options);
*/

int main(int argc, char* argv[])
{
  if (argv[1] == 0 || argv[2] == 0 || argv[3] == 0) {
    printf ("usage: setxattr path attrname value\n");
    return 1;
  }

  const char* path = argv[1];
  const char* name = argv[2];
  void* value = argv[3];
  size_t v_len = strlen(argv[3]) + 1;

  int r;

  r = setxattr(path, name, value, v_len, 0, 0);
  if (r != 0) {
    printf ("setxattr failed\n");
  }

  return (r != 0);
}

Finally, I did not find a need to set the attributes anywhere except under the Latest backup.

After updating the two attributes with their respective UUIDs I was able to complete an incremental backup rather than a completely new one, and all was good.

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Jan 05, '10 06:32:13AM

As far as I know, the SnapshotVolumeFSEventStoreUUID is only for optimization:

If it is present and if it is a match to the FSEvent database on the working volume, the deep traversal can be omitted and only the recorded events will be used for a quick backup.

If you don't touch it while reconnecting Time Machine, it will indeed do a deep traversal of the entire working volume (the new one in this case) because it finds no match.

So the first backup will take longer, it may also (incorrectly!) predict a relatively large size of that snapshot but in the end it seems to be just fine after all at least that was my experience when I migrated from my PowerMac G5 under Leopard to my iMac i7 under Snow Leopard (see my previous post above).

Did you already abort the first snapshot when it entered deep traversal or when it initially displayed an unexpectedly large backup size? Or did you let it run its course and the new snapshot was in fact full-sized?

The latter should not be the case the first backup will just take longer, but if you didn't change the arrangement of the folders on your volume, the incremental backups should remain small.

And in my experience the trailing zero termination for strings is set automatically by the xattr tool when using it as described, so I did not have a problem with that.

Tweaking the latest backup does indeed seem to be sufficient, as described. ("Latest" in the backup folder is just an alias of the actual snapshot, normally the one with the most current timestamp as its name.)

---
There are no problems...
Edited on Jan 05, '10 06:42:23AM by only_solutions



[ Reply to This | # ]
Snow Leopard
Authored by: jowie on Jan 23, '10 03:05:51AM

Hi there,

Anyone have a solution for doing this in 10.6?

Thanks,

:-Joe



[ Reply to This | # ]
Snow Leopard
Authored by: only_solutions on Jan 24, '10 05:22:12PM
It still works the same way see my post Update: Moving from PPC to Intel and from 10.5 to 10.6 and still keeping the backup! a few slots above. You just need to be sure to have the proper tools, some of which may need to be extracted from a previous installation.
---
There are no problems...
Edited on Jan 24, '10 05:27:33PM by only_solutions


[ Reply to This | # ]
Snow Leopard
Authored by: jowie on Jan 25, '10 02:58:04AM

Hi,

Thanks for letting me know, sorry I missed that original post! Ummm it's looking very complicated for someone who doesn't really know Terminal all that well, and the last thing I want to do is screw everything up. You're not the first person who has said it's difficult, so I think I'll just quit while I still have my data intact and let Time Machine do a full new backup... :-)

Cheers

:-Joe



[ Reply to This | # ]
Snow Leopard
Authored by: only_solutions on Jan 25, '10 08:15:55AM
It is not extremely difficult, but one needs to be very precise and concentrated when messing with the internals here, so I recommend treating these things with respect and caution. (And with additional backups I cannot stress this point enough!)

Properly weighing the risks against the chances is a good thing. I would not categorically advise against you trying this, but even with a detailed description at hand you will need to decide for yourself whether you feel up to it (possibly after non-destructively exploring the terrain).

This concept basically applies to many hints on this site.

One more thing: I've been describing the structures and procedures regarding a "plain" system being backed up. If you have File Vault enabled (encrypted home folder) the mechanisms should generally be similar, but some further details may need to be taken care of, and the matter of continued accessibility of the encrypted backups would also have to be verified.

---
There are no problems...


[ Reply to This | # ]
Snow Leopard
Authored by: jowie on Jan 25, '10 08:24:39AM

Not to worry thanks... I have a limited backup from my laptop anyway, so it "only" needed to backup 50GB. Therefore it only needed to remove about three months of the oldest backups in order to fit on the TC.

Unless it's really easy peasy stuff on Terminal, I think I'll steer clear ;-)



[ Reply to This | # ]
Snow Leopard
Authored by: only_solutions on Jan 25, '10 08:37:30AM

Not a bad view on things, but one can always learn more over time.

All the best! :-)

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: jtrascap on Mar 11, '10 02:01:05AM
Cannot get this to work - In the terminal, running as admin on my system (my usual account isn't), I get either:

[Errno 13] Permission denied: '../2010-03-05-163914/Volumename'

so I thought, add SUDO before the xattr call, and then I got this:

[Errno 1] Operation not permitted: '../2010-03-05-163914/Volumename'

Any ideas, anyone? Terminal isn't my thing...

[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 12, '10 02:34:04AM

When doing which step on the way, exactly?

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: jtrascap on Mar 12, '10 05:11:41AM
Sorry - it would (of course) be the "critical step":
Next, and this is the critical step, overwrite the UUID with the UUID you have copied from Disk Utility above (the UUID is represented by the X's in this example):


[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 12, '10 06:34:09AM
Had you followed all the steps before that?

This will only work in the proper sequence, particularly after disabling ACLs on the backup drive. If ACLs are still in effect, you will not be able to set the UUID; The error messages would be consistent with that.

Important: If you should have disabled ACLs for your working volume instead by mistake (you should have disabled them for the backup volume!), you should re-enable them for the working volume again, following the step indicated at the end of the instructions. Maybe that's been the mistake.

---
There are no problems...


[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: jtrascap on Mar 12, '10 09:55:00AM

I sent you the mail and went to the gym, and a little bell went off on the treadmill. Wellbell, flashing light, klaxonpermissions. I activated the root account, did the command which worked, deactivated root and set the system off to backup (and all your other steps as well, of course, including ACLs). Time Machine runs at a higher level than my usual account or the admin account, so root made sense.

So far, so good - it's gotten pas the initial error point (32K of 16GB to backup) and seems to be working fine.

So if anyone else is getting a permissions error, try running this command as root.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 12, '10 10:01:08AM

Good to hear! :-)

---
There are no problems...



[ Reply to This | # ]
10.6 super easy!
Authored by: JMoVS on Mar 12, '10 02:34:53PM

Hello,
the simplest way for me was, after Apple Care replaced my Hardrive, just to boot from the Install Disk and then restore completely from my Backup.
Then just switched Tme Machine on, let him ding a long time, displaying that TM makes a full backup, but instead, it did a normal incremental backup. Just works.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: rich k on Mar 19, '10 02:41:28PM

HD in my iMac failed - saw it coming, and was able to CCC the drive before it died. Apple replaced it under AppleCare, and I then CCC'd my data back, only to run into the full backup problem everyone here has had. I've had no luck connecting to my backup drive, which is in a Time Capsule, using Terminal and the steps outlined here. Weirdly, I can mount the sparsebundle to my desk top, and can see the virtual drive in Disk Utility, so I can see the UUID of the backup and the UUID of the new drive. I wish I had been clever enough to have restored the new drive from the Time Machine backup, but I wasn't, and now there is too much new info on the replaced drive.
What is the proper path to connect to a drive on a Time Capsule over a network with Terminal?
Could I instead change the UUID on the new drive to match the UUID on the existing back ups?
Or would that introduce a whole new world of hurt?



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 20, '10 10:00:28AM

I don't have a Time Capsule, so I cannot say much about the details.

This hint is somewhat crude in how it deals with the extended attributes, by disabling their observance for the entire drive, then making changes and finally restoring normal operation.

This might be where you're running into a problem.

In principle it should be possible to directly disable the change protection attribute of the respective folder, then make the UUID change as described and after that re-enable the protection attribute again.

I admit that this will be a necessary update to this hint which I just have not had the time to do so far.

On the other side, I actually think changing the UUID of your system disk should work.

You should just be absolutely certain that the original drive is truly gone and will never be connected to the same machine again. And I would recommend a restart right after making the change.

Having a current backup is of course absolutely mandatory, but since you've restored it from your backup, that should be the case.

I can't vouch for this being without hickups it is possible that there are some mechanisms which might have registered the present UUID and which might act up a bit. But it might just work.

Good luck! :-)

---
There are no problems...



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: rich k on Mar 21, '10 06:23:15PM

Thanks for this.
I still have the external CCC backup, but since I've been using the internal drive for a few weeks now, they no longer match. I think what I will do is another CCC clone before I try changing the UUID on the boot drive. Question though - if changing the UUID on the new internal drive DOES cause major problems, will CCCing back the contents of the external drive also revert the UUID of the new internal drive, or would I still need to change that back?
I'm suspecting the UUID won't revert, since otherwise it would have reverted when I first moved the cloned drive back.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 21, '10 07:04:06PM
I can't be certain, but I would also expect CCC to leave the UUID alone, so in case you needed to restore the backup with CCC, you might have to revert the UUID as well (be sure to make a separate note of the original UUID on the backup drive before changing it on the system drive).

I would also recommend you to make the fresh backup to a different drive than the original CCC one if at all possible.

I know I sound paranoid, but that is only proper when dealing with the entirety of your data.

Don't Panic! But nevertheless be cautious! 8-)

---
There are no problems...


[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: rich k on Mar 24, '10 03:31:03PM

Now I have to confess to being Terminally illiterate. So:
- do I boot from a different volume when I attempt to change the UUID on my normal boot drive, or can I do it while booted from that volume?
- what is the full path to the root of a boot drive?
- do I need to log in as root admin, or can I log in via my usual user account?
- is there an easier way to change this UUID?
I've searched extensively and haven't found references to any of this online - is there a reference book or source, no matter how wonky, that I can but?
Thanks so much for tolerating me. I can make a dozen major apps dance and sing, but Terminal is NOT one of them.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Mar 27, '10 04:48:07AM
- do I boot from a different volume when I attempt to change the UUID on my normal boot drive, or can I do it while booted from that volume?

That is probably a good idea in order to avoid potential confusion, although it should not be absolutely necessary. If you do it while running from that same volume, just be sure to complete the change and then restart the system right away so the change will take effect.

- what is the full path to the root of a boot drive?

Just / .

All other volumes are mounted under /Volumes/ . You can find the path by simply dropping a file, folder or even a drive into a Terminal window: The respective path is then automatically inserted into the current input line.

- do I need to log in as root admin, or can I log in via my usual user account?

Calling the respective functions via sudo already takes care of that (your account must be enabled as an admin account for this, and you will be asked for your password on execution). But there is no need to explicitly log in as root.

- is there an easier way to change this UUID?

Not to my knowledge. Normally it is not supposed to be done, so it shouldn't be easy, really. ;-)

I've searched extensively and haven't found references to any of this online - is there a reference book or source, no matter how wonky, that I can but?

I'm not aware of a book (which could well exist), but for some of the background the articles by John Siracusa on ars technica about Mac OS X are quite interesting.

Thanks so much for tolerating me. I can make a dozen major apps dance and sing, but Terminal is NOT one of them.

No problem I always recommend anyone to be careful about treading unfamiliar ground, but I'll try to help where I can. :-)---
There are no problems...

---
There are no problems...
Edited on Mar 27, '10 04:56:34AM by only_solutions


[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: rich k on Apr 15, '10 12:08:59PM

Final outcome:
I restored the FSACLCTL command using Pacifist from my 10.5 install disk. I then attempted to change the UUID of the backup sparsebundle file on my Time Capsule. This appeared to work, but didn't.
SO, after running one more CCC backup of my boot drive for safety, I changed my boot drive UUID to match the back up UUID. That nailed it. Unfortunately, in the meantime I had lost many of the older back up iterations as Time Machine, thinking the older backups to be from a different Mac, erased them one by one while methodically bringing the data "up to date". But at least I have back ups from Oct. 09 forward, instead of none at all.
Bottom line - if at all possible, use Time Machine to restore into a new drive, rather than Carbon Copy Cloner or another drive-to-drive copy. But if, like me, that is not an option, and you've been using a network-based backup scheme like a Time Capsule, changing the new drive's UUID will work.



[ Reply to This | # ]
Time Machine just does it in 10.6.3
Authored by: schwern on Sep 27, '10 10:00:36PM

I just got a new MBP, dropped the drive from my old machine into it and hunkered down to figure out how to get Time Machine to use the old backups on the new machine.

After reading all the comments and trying to figure out where to get fsaclctl I gave up and just ran Time Machine. It asked politely 'Would you like to reuse the existing backup "/Volumes/Backup/Backups.backupdb/Your Computer" with this computer?' offering "Do Not Backup Now", "Create New Backup" or "Reuse Backup".

So I guess it just does it now. This is a 10.6.3 machine.



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: bluehz on Nov 09, '10 07:30:44AM

This is basically the same procedure but spells it out a little better - this worked for me. The trick is DEFINITELY to replace both UUID as mentioned.
http://discussions.info.apple.com/thread.jspa?threadID=2292381&start=15&tstart=0



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: jb8748 on May 07, '11 05:12:30AM

I have just completed a hard disk swap using a time machine backup, Mac OS X Install DVD 10.6 and a system running 10.6.7. Time machine backup is on a shared USB drive on the network.

1) Ensure Time Machine back up is complete
2) Replace hard disk
3) Boot from install DVD, ask to restore from Time Machine back up
4) Connect USB drive containing back up directly to upgraded machine
5) Computer restores from back up
6) Reboot upgraded computer when finished
7) Return USB drive to network
8) Start Time Machine

It took a long time to process all the files and said that it had to write everything but in fact it only did an incremental backup.

I didn't have to do anything from this hint. I took a copy of the sparseimage before I connected the upgraded computer to compare and the change of UUID had already been done (I assume when the restore had been done).

The important point though - that nearly got me (and why you should have a back up of the back up) - is that you MUST have enough space on the Time Machine volume to do a COMPLETE backup. It won't do one but it will insist on having the space to do so. If there isn't enough space it will keep deleting old back ups until there is space. This could be every back up until the latest one!



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: monkeybagel on Jun 22, '11 06:44:28PM

Thank you to the OP for this hint. I am on 10.6.7 and have been trying to reconnect my external FW400 drive to Time Machine after a restore from the same drive (after trying the Lion DP4 preview). I performed a Time Machine restore booting from the 10.6.0 DVD media and all seemed to go well. The system is functioning correctly as expected, and I extracted fsaclctl from a 10.5.3 DVD I had. All seems to go well and Time Machine does not complain about a UUID mismatch, however I am still seeing what appears to be a full backup. The drive in question has about 580GB free before starting the Time Machine backup out of 1TB. It then calculates the initial backup and estimates 209GB will be backed up, which equates to the data on my entire system. Although the backup is running very slow, it is running currently with no errors. I have seen where people have posted that it is normal for Time Machine to estimate the wrong size during the first backup and that it essentially sorts it out on its own, but I don't seen any clarification as to when this happens and how it is observed. For example, should I see the number decrease in System Preferences? Right now, I am seeing 113.73GB of 209.08GB backed up, and the 209.08 has not changed. Will this change before it gets finished? Also, the free space on the FireWire drive has went down by 113GB so it appears to be using that amount and not doing a delta backup. Just wondering what to expect and how to confirm that it has indeed performed a delta backup.

Thank you



[ Reply to This | # ]
10.5: Reconnect Time Machine backup after drive swap
Authored by: partyinmyvance on Feb 01, '12 08:18:38AM

Hello all, thanks in advance, for the time and help. Does any one know if this will work with 10.7?

Have a good one...



[ Reply to This | # ]
10.6.8 Snow Leopard
Authored by: mschmitt on Aug 09, '12 05:25:23PM
This hint does work on Snow Leopard, but it may not be apparent that it is working.
  1. The "Event store UUIDs don't match for volume" and "Node requires deep traversal" messages are nothing to be alarmed about; it just means that Time Machine is out of sync with the fsevent queue and needs to rescan. This can happen for any number of reasons.

  2. Some of the hints advise also updating the FSEventStoreUUID. I do not think this is a good idea. If the FSEvent queue is out of date, you really do want Time Machine to rescan -- otherwise it could miss files.

    Some users reported that they needed to fix FSEventStoreUUID to keep it from doing a full update. It may have had that effect, since it would cause Time Machine to think nothing has changed in that backup. But as soon as it scans a folder or drive for any other reason, it could still do an unnecessary file backup, if due to the other UUID issues it still thinks the old backup is a different drive.

  3. I first applied the hint to update the Latest SnapshotVolumeUUID. I started the backup, Time Machine reported (after doing the full scan) that it wanted to backup an amount equal to the entire drive. I let it run for awhile, just in case, but quit it after it was clear that it really was backing up way too much.

  4. I then applied the hint to recursively change the UUID in all of the backups. I started the backup, but again Time Machine (after full scan) reported it wanted to backup the same amount of data. So I canceled it.

  5. Next I tried changing the UUID to be in hex, with the trailing 00. It still wanted to backup the same amount of data, so I canceled again.

    In retrospect I do not think that was necessary. Another post says that the ASCII UUID is really the same as the hex version; the only difference is how it is displayed.

  6. After hours of frustration and failed attempts, I gave up and let the backup run to completion. It only backed up the incremental changes!
That's the key: There is no way to tell whether the backup is really a full backup or incremental without actually letting it perform the backup. There are no log messages or Time Machine displays that will reveal the difference.

My conclusion is that in Snow Leopard it is necessary to update the UUID on all of the backups (but I'm not 100% sure of that), but it isn't necessary to do anything more than that.

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: Davidgorch on Nov 25, '12 08:20:38PM

I know it's three years later, but I still run my PowerMac G5 and I added a SS Hard Drive so this tip came in very handy. Took me a while to get everything right, but my incremental Time Machine back-up is finished and I am saved from having to either lose my backups or get a new larger drive for Time Machine. Thank you!



[ Reply to This | # ]
10.6.8: How I did it & Could it be better?
Authored by: xantron on Dec 02, '12 03:26:04PM

I just replaced a non-boot drive in my 2008 Mac Pro with an SSD. I cloned the old drive to the new drive using SuperDuper and assigned the new drive's UUID to the old drive's backup (* details in comment to follow). For what's worth, I gave the new drive has a different volume name from the old drive.

The good news: My first Time Machine backup with the new SSD in place amounted to something like 18 MB. Yay! (A full backup would have been in excess of 300 GB).

The not-so-good news: when perusing backups in Time Machine, if I want to see a file revision dating from old drive, I have to select my computer's name and navigate to a date before the drive changeover, then navigate to the old drive and to the desired directory. In other words, if I'm in the Finder in a folder (e.g., "Client Work") on the new drive, and I enter Time Machine, TM shows me only Client Work's post-changeover backups; there is a disconnect between the post- and pre-changeover revisions.

It would be nice to be able to peruse pre- and post-changeover file revisions in one place in Time Machine. Anyone think it's possible to bridge the gap?

Maybe I should have given the new drive the old drive's name?

Maybe it would have made more sense to give the new drive the old drive's name and UUID instead of changing the backup's UUID?



[ Reply to This | # ]