FlippedBITS: Booting Your Mac from a Duplicate
In this first installment of FlippedBITS, I want to look at what happens when you boot your Mac from a duplicate (or “clone”) of your startup disk. In doing so, I hope to clear up several common points of confusion, particularly regarding ongoing backups and syncing other types of data.
For years I’ve recommended a three-pronged backup strategy consisting of versioned backups (such as those produced by Time Machine or CrashPlan), bootable duplicates (complete copies of everything on your startup disk, stored on an external drive), and offsite data storage (either in the cloud or by rotating physical media to other locations). Together, this combination can protect your data against almost any disaster, while making recovery as painless as possible. (For complete details about my suggested strategy, including the steps to create a bootable duplicate, see “Take Control of Backing Up Your Mac.”)
It’s simple enough to make a duplicate using a tool such as Carbon Copy Cloner or SuperDuper; having done that, you can use the duplicate to boot your Mac either by selecting it in the Startup Disk pane of System Preferences or by holding down Option while restarting and selecting the volume containing the duplicate. Doing so enables you to get back to work immediately if anything goes wrong with your startup disk; running from the duplicate makes your Mac behave as though nothing had happened. So far, so good.
But, based on numerous email exchanges I’ve had with people who have read my various books and articles about backups, what happens once you’ve booted from the duplicate is sometimes unclear. Some people expect a duplicate to behave entirely like the original in every situation, which turns out not to be quite true. Others worry that the duplicate will cause all sorts of problems because it’s not enough like the original, resulting in extra, unnecessary steps. To untangle things, let’s start with the least ambiguous situation.
Swapping Your Startup Drive — Suppose your Mac’s internal hard drive dies completely, so you remove it from your Mac and replace it with the drive on which you’d previously stored your bootable duplicate. Your Mac doesn’t care about the fact that the new hard drive may have a different brand, capacity, or speed. All it knows is: here’s a disk with exactly the same data in exactly the same place. It is, for all practical purposes, the same disk. You can carry on as if nothing happened; everything, including your backups, should simply pick up where they left off, which is almost certainly what you want.
Now, there is one little catch. What if there was a time lag between when you made the duplicate and when you started using it? And what if, during that lag, you created or edited data on your startup disk — and backed it up to a destination other than where your bootable duplicate is stored? Now you have a startup disk that’s somewhat out of date, and to make it current, you’ll have to go to that other backup to locate and restore any important files that were changed after you last updated the duplicate. This, I’m sorry to say, is often an entirely manual procedure. In many backup apps (and again, I’m thinking especially of Time Machine and CrashPlan), there’s no simple way to say, “Show me all and only the
files that changed and were backed up after time x.” You may have to dig through folders one by one in your backup archive to find these files. You could ask the software to restore everything backed up after a certain time, overwriting any existing files, but that would take quite a while. It’s a pity that many otherwise highly competent backup apps don’t account for this usage case.
Booting from an External Drive — Although the situation I just described is the least ambiguous, it’s also relatively infrequent. The most likely scenario, which gets more confusing, is when your regular startup disk is still present and functional but you hook up your duplicate and boot from it temporarily. Perhaps you’re doing this to verify that the duplicate works (in which case you may be running from the duplicate for only a few minutes), or perhaps your startup disk is having problems and you want to run a disk repair utility while carrying on with your regular work.
Either way, let me start by saying what isn’t a problem in this scenario. For one thing, it doesn’t matter if your startup disk is external. Apart from speed differences, your Mac should behave identically whether the startup disk is connected via an internal SATA port, USB, FireWire, Thunderbolt, or whatever. So, don’t let that trouble you in the least.
For another thing, it doesn’t matter if data happens to sync with the cloud while you’re booted from the duplicate. For example, if you use iCloud, your calendars, contacts, bookmarks, and so on will sync in the background. You need not worry that the outdated data already on your duplicate will somehow overwrite what’s in the cloud; on the contrary, the cloud has the “master” copy (sometimes called the “truth”), so it will bring the data on your duplicate disk up to date. Similarly, if you use Dropbox or another cloud-based file storage service, it will bring your disk up to date with the latest truth from the cloud, and it’s unnecessary for you to fret over that in the slightest.
(You do need to fret if you use POP for email, or if you have any rules or filters that file incoming email from IMAP or Exchange servers into local mailboxes. That could get messy, with the duplicate being changed in ways that can’t easily be applied back to the original, so if in doubt, refrain from checking your email at all while booted from the duplicate.)
You need not even worry about aliases — usually. When you create an alias to an item that’s on your current boot drive (that includes items in the Finder’s sidebar and in your Login Items list), Mac OS X creates relative links. That means if you make a duplicate, boot from the duplicate, and open an alias, the item that opens is the one on the duplicate, not on the original disk. (And that’s probably what you want.) That’s not to say your Mac might not have a script, a symbolic link you created in Terminal, or some other pointer that references a file or folder by disk name, and if it does, you could accidentally open the wrong copy of a file or application, or save data to the wrong disk. (If you’re concerned and
want to be absolutely sure which item you’re opening, navigate manually from the top level of your disk when booted from a duplicate.)
However, at least one significant thing is most likely different, even though you may not notice it. If your duplicate had the same name as your startup disk (presumably the most common case), something slightly weird can occasionally happen. Mac OS X won’t let two mounted volumes have exactly the same name. In the Finder, they may look like they have the same name, but if you already have a volume called “Macintosh HD” mounted and then you mount a second one, behind the scenes, the second one gets a different working name (in this case, “Macintosh HD 1”). That’s because many things that happen on your Mac depend on being able to locate a disk by name, and if there were any ambiguity, a file might get put in the
Ordinarily, this on-the-fly renaming just works, but it’s not foolproof. What if, during the time you have both “Macintosh HD” and “Macintosh HD 1” mounted, another user on your network connects to your Mac and copies a file to what is now “Macintosh HD” — your duplicate? You might not notice it, and when you switch back to your usual startup disk, the file would be missing. Similar things can happen with file-synchronization apps, software downloads, and other operations. Furthermore, sometimes Mac OS X gets confused and doesn’t correctly update its behind-the-scenes list of volume names, so you could, for example, encounter a situation in which “Macintosh HD” is a volume you mounted after “Macintosh HD
On the other hand, renaming your duplicate doesn’t necessarily solve these problems. If your normal startup disk is named “Cindy” but you’ve booted temporarily from “Kate,” you may avoid mismatched name issues right now — but later, if you have to start using “Kate” permanently, apps and users that were still trying to save data to “Cindy” could get confused. All in all, I think you’ll get the best results if your duplicate has the same name as the original disk, but you should follow a few steps (just ahead) to avoid problems while running from the duplicate.
Meanwhile, you may have to think about another subtle background process: backups! After all, your backup software is probably configured to run automatically — perhaps once an hour (like Time Machine) or continuously (like CrashPlan). Backups usually don’t begin immediately when you boot your Mac, but they could easily kick in within 10 or 15 minutes. What if you’re planning to run your Mac from the duplicate for longer than that, but not permanently? Should you let your backups proceed — meaning they’ll be backing up the duplicate — or should you turn them off?
In general, there’s no harm, and considerable benefit, in letting backups run. Your backup software should act as though your duplicate is your regular startup disk and keep copying files to its normal destination as though you had restarted normally. That’s probably what you want, because if you create or modify a file while running from the duplicate, it can then be backed up. The problem is, in fact, with the opposite case: what if you modify a file but it isn’t backed up (perhaps because the time for the next periodic backup run hasn’t rolled around yet)? When you switch back to your regular startup disk, the file won’t be there (or won’t be current), and it won’t be in your backups either. It will still be on your
duplicate — but only if you think to check there before you update your duplicate the next time; doing so will probably delete the new file because it’s not on your startup disk.
Taking all this into account, here are my recommendations for what to do when you must boot from a duplicate for a short period of time:
- If you can avoid creating, modifying, or downloading files, do. If you can’t, make sure they’re synced to the cloud, copied back to your regular startup disk, backed up, or otherwise made available to yourself when you return to your usual disk later.
- Let regular, versioned backups (such as Time Machine and CrashPlan) run normally. But if (per the last point) you can’t avoid creating files, make sure your backup software has in fact backed them up before switching back to your customary disk.
Turn off any scheduled updates to your bootable duplicates. The last thing you want is for your duplicate disk to clone itself back onto your main startup disk while you’re testing it, or for the software to freak out in trying to clone the original over the now-booted duplicate.
Avoid letting other users connect to your Mac, especially to upload files.
Booting a Different Mac — There’s one more scenario to consider: booting one Mac with a duplicate of another Mac’s startup disk. For example, imagine that you created a duplicate of your iMac’s startup disk and then you had to take your iMac to the shop for repairs. In the meantime, you hook up your duplicate to your MacBook Pro so it can “pretend” to be the iMac. As long as the MacBook Pro supports the same version of Mac OS X your iMac was running, this arrangement should work fine — with, as you might have guessed, a couple of qualifications.
First, although this situation is ostensibly similar to the last one — booting a Mac temporarily from another drive — the time frame involved could be longer (days or weeks instead of hours). So, it’s impractical to avoid modifying files, checking your email, and the like. Therefore, I recommend that you use the duplicate disk on your MacBook Pro as you normally would use the internal drive on your iMac, and then — once your regular iMac is back in service — hook up the external duplicate and reverse the cloning process (copy everything from the external drive back to the iMac’s internal drive it started on).
Second, while your MacBook Pro is running from the duplicate, it will by almost every measure appear to be the iMac. It’ll even use the iMac’s name for file sharing, screen sharing, and the like. However, every Mac has several unique identifiers, including a serial number, a UUID (universally unique identifier), and a MAC (media access control) address for each network interface. Some pieces of software check one or more of these unique identifiers to verify that they’re still running on the same Mac on which they were authorized or licensed.
The most common example is iTunes. If you authorize your iMac to use your iTunes account and then start up your MacBook Pro with a duplicate of the iMac’s disk, that doesn’t mean the MacBook Pro is automatically authorized. You must authorize it manually, if you haven’t done so previously (in iTunes, choose Store > Authorize This Computer). But, if you’ve already run out of authorizations — Apple limits you to five — you may be out of luck unless you can deauthorize one of your other computers or reset all your authorizations, the latter being something that Apple allows you to do only once per year. Other software may make you jump through similar (or worse) hoops.
Don’t Sweat It — As convoluted as this all may sound, booting your Mac from a duplicate is usually a simple and problem-free operation. But it never hurts to have a better grip on what’s going on behind the scenes, just in case. In particular, think about whether you’re going to be using the duplicate long enough to add or modify files on it manually. If not, there’s no harm in simply switching back to the original. But if you are going to be working from the duplicate for any significant period of time, you’ll need to clone it back to the original when you’re done.
A final note: keep those duplicates up to date. It would be overkill to update them every hour, but once or twice a day is not a bad idea. Remember, the longer the gap between the last time you updated your duplicate and when you discovered you needed to boot from it, the greater the chance of missing or outdated files that you may have to laboriously restore.
Another thing to consider when booting from a clone is how you access items in the sidebar, including and especially applications.
If an app on the normal internal boot drive is acting up, and you boot from your clone to see if the app is ok there, you must be sure to NOT use the sidebar or any similar shortcut to open the app.
You must go into the "Appications" folder on the clone, and then open the app from there.
It's easy to forget. After years of working wih clones, I still sometimes do it.
As a novice user I don't think I understand. Do items in the sidebar "point" to the applications on the internal boot drive?
You've both brought up an important point that I'll need to address in an updated version of the article.
The short version is this: If you create an alias—and that's essentially what you're doing with Sidebar items and Login items too—to an item on the volume from which you have booted, that alias is a relative location. That is, it says, "On the current startup volume, whatever that happens to be, follow this path to get to this file or folder." However, if you create an alias to something on another volume, you get an absolute path: "On this particular volume name, follow this path to get to this file or folder."
Usually, this arrangement produces exactly the desired result: when you boot from your duplicate, your aliases point to things on the duplicate, not on your original volume. But there are some edge cases where it doesn't, and the problem is that it's not always visually obvious where an alias's target is, when you have two identical volumes mounted. So if you want to be absolutely safe and certain, you always navigate from the top of the desired volume to the item you want. (Because remember, sometimes you may WANT to open something on the non-boot volume, although most of the time you won't.)
Thanks Joe. I didn't see anything I hadn't figured from my own mistakes, but you put it all together in a concise, readable article.
Good stuff Joe - think I'll update my bootable duplicate on a daily basis now.
There are issues as well with the frequency of backups. If something goes wrong with your system and you update your cloned backup before you notice the issue, the problem may be transferred to the backup. This is particularly relevant if you don't do regular, routine maintenance on your boot drive. Problems with the original drive may even cause the backup to fail. For this reason, though it may seem like a hassle to do so, you should, at a minimum in my opinion, use Disk Utility to repair permissions and validate your hard drive before you update your clone. I also run those routines on my backup drive before updating the clone. However, these procedures are impractical if you back up twice or even once a day.
For this reason, I use SuperDuper! to maintain my clones and Time Machine for more frequent backups. This way I can update my clones less often (say once a week) and still be sure I have access to all my files should something go wrong in the meantime.
The reverse case arises for those who don't back up before making important modifications to their system, like major software and system updates. If your system is not in the best possible shape, an update can fail and even put your system out of commission. Without a recent backup, you're SOL. In this case, a clone is more practical than Time Machine because, as is the theme of this article, you can boot from the backup immediately and get back to work. Restoring from a Time Machine backup when your boot drive is hosed is time consuming and, I've found, not always reliable. Reinstalling over the network will put you even more behind the eight ball. In addition, if you cannot use your system because the drive itself has failed, you won't be able to access the Recovery HD partition either, which will mean even more work before you can return to work (or play). While a cloned backup won't include the Recovery HD partition, it will keep you going while you either reformat and reinstall OS X on your original drive - or replace the drive.
Another way around the clone frequency issue would be to use one backup drive for daily updates and another drive to update once a week or so, which would likely be the case if you follow Joe's advice to keep a copy of your boot drive off site. You're not going to update an off-site drive twice a day.
I will add my two cents here that while cloud backups may be convenient in some ways, they may be no more reliable than your own in-house backups. Cloud backups are, after all, done on someone else's computer, one likely to be even more heavily used than your own. Cloud providers not infrequently suffer service outages and hardware failures as well. And restoring from the cloud, even if it's possible, will be agonizingly slow. And who can afford to pay for the volume of cloud storage that would be required to back up an entire system? Cloud storage may be great for collaboration or those who use more than one computer - but for archival purposes I think the drawbacks are prohibitive.
It seems we have a number of points of disagreement, but I want to mention just one thing that particularly stuck out: you can have unlimited cloud storage for backups for $4 a month with CrashPlan or $5 a month with Backblaze, and there are other similarly inexpensive, unlimited options out there. Cost alone should not be a deterrent to cloud storage for most people.
I use Carbon Copy Cloner to make back-ups. I make a Recovery Partition before cloning my Mountain Lion HD.
Great job, Joe. I think that we wil all benefit from flipbits as you proceed. Can't wait for the next one
Thanks for the explanation, Joe.
One idea that might deserve mention: store your bootable clones as disk images on a big external drive. Then you can keep several of them in case the most recent one has inherited a problem from your boot drive.
I presume this would work: pick the clone image you want to boot from, and expand it to a separate partition on the external drive. Then you should be able to boot that partition.
It would be better simply to make multiple partitions and store bootable duplicates directly on each one. You can't boot from a disk image, after all, and it could take quite a few hours to restore an image onto a partition so that you could boot from it—which, in my view, nullifies the main point of having a bootable duplicate (that you can get back to work instantly).
In my experience, creating bootable disk images takes hours but restoring them is much faster. A compressed disk image containing ~20GB of data would restore in maybe 30 minutes on a 2008 MBP, faster on faster hardware.
OK, but I'd counter that very few people have startup disks with only 20 GB of data. The one I'm using right now has 509 GB, for example. Since we are talking about duplicates of one's main startup disk, we're looking at significant restore times. Not sure what benefits a disk image offers over multiple partitions.
Another factor is the cloning program. I use Super Duper which tells you that it copies everything but the files that Apple says not to copy. I don't know what those files are. I do know that when I had to replace the hard drive on my 2010 iMac, I used that drive to migrate my data on to the new drive.
The result was the new hard drive somehow had 70,000 fewer files than the old one. I also find that booting from a cloned drive makes some programs (Dropbox for one) think you are on another computer so there is reauthentication to be done.
My suspicion is that most of those 70,000 files are caches, logs, and similar things that are irrelevant to the operation of your Mac.
As for Dropbox, yes, what you describe can happen, because Dropbox checks some of those unique hardware identifiers. However, once you log in with the same account and password, everything quickly returns to normal.
Thanks for this illuminating article, Joe. I use duplicates with the same name as the source volume but with the word “duplicate” appended to the name.
I notice that the problems you allude to with having different names for the source volume and the duplicate are to do with using the latter as a “permanent” substitute for the former. I haven’t had to do this, but I guess I would have to rename the duplicate then, in line with your recommendation.
I like having a different name for the duplicate when I’m using it “temporarily”, though. For one thing, I can see clearly which disc is which in the Finder. How about it, if I start to use the duplicate “permanently”, then I change the name to “Macintosh HD” and the name of my source disc to “Macintosh HD OLD”. Wouldn’t that give me the best of both worlds? Would I have other problems?
I don't see a particular problem with your solution. That might be a reasonable approach.
I was having problems with my internal drive, so I am now booting from an external drive that had been a backup via SuperDuper. I had to update some files because of a time lag since my most recent backup.
However, some of my applications will not open: namely, Adobe Photoshop, Adobe Illustrator, and Adobe Dreamweaver. I believe the problem is copyright protection. I believe that I will be able to solve this problem by contacting Adobe, but it is still annoying. Other applications also do not recognize that I am running them from the same computer. It seems that there should be a way of showing the application world that I am only changing the boot drive - not the computer.
I've never encountered that problem, and I must say that surprises me. If you contact Adobe and find a way to solve the problem, I'd be very interested to know what they suggest.
The error warning suggested that I uninstall and reinstall Adobe Photoshop (or Illustrator or Dreamweaver, depending on which program I was trying to open). I finally got around to trying this today.
The Adobe uninstall utilities did not work, so I simply moved Illustrator CS5 to the trash. When I tried to open the dmg file, I got the warning that it was from an unrecognized developer! Adobe? Anyway, I did open the file using control click (probably right clicking would be the same). I did successfully install Illustrator. And it will now open.
And guess what? Both Photoshop and Dreamweaver opened successfully without repeating the uninstall and reinstall procedure for those applications.
In all cases, I needed to reenter the registration serial numbers for all of these applications plus older versions (since they were upgrades).
The problem is now resolved.
My internal drive seems to be okay now. Fortunately, I had two local backups via SuperDuper. My first backup was not good because of an apparently bad file on the internal drive. I booted with my second backup, updated some files from the internal drive, backed to my other backup disk, then backed to the internal drive. All seems to be well now.
I'm so glad to hear the problem was solved, and relatively easily at that!