| |
 |
|
Frequently Asked Questions |
| |
[CCC Help] [Browse Help Topics]
What happened to the "Repair permissions" option?
"Repair permissions" is not what I consider to be a task associated with backing up one's hard drive. It is at most a maintenance task, and more suitably a troubleshooting tool that should be used judiciously.
I just backed up my Boot Drive to a partition on an external hard drive. However, the volume capacities do not match. Should they? Should I be concerned there's more than a GB missing?
There are a couple legitimate explanations for a mismatch between the capacities reported in Disk Utility. First, when cloning using the "Incremental backup of selected items" cloning method, there is a list of items that are excluded from the backup either because they are ephemeral items regenerated every time your machine reboots, or they are not appropriate to back up or because they actually reduce the portability of your OS to another computer. An exhaustive list of those items is included in the CCC Help section labeled Configuring filters in CCC to limit what is backed up
While I don't recommend it, you could modify the list of items that CCC ignores by editing the "defaults.plist" file within the CCC application bundle. Note that these items are not ignored when using the "Backup everything" cloning method (that cloning method references a smaller, very conservative subset of items, also referenced in the defaults.plist file).
While the exclusion of these items explains much of the disk capacity discrepancy you may discover in Disk Utility, it does not explain it all. A user suggested the following scenario after performing a "Backup everything" clone to his target drive:
Boot drive - 39.67 GB used
Backup drive - 38.55 GB used
Should I be concerned there's more than a GB missing? Could this be a swap file or something? Is there an easy way to isolate what files are not on both?
A GB seems like a lot, but it's not surprising, not for 40GB used (the discrepancy increases with the amount of data on your boot volume).
I spent about 3 months head-down in the HFS+ filesystem specification trying to figure out why the contents of a cloned volume is always less than the boot volume (and it really is only that large of a difference when the source is the boot volume). I still can't explain it entirely, however I noticed that if I booted from the cloned volume, the difference was suddenly in the reverse.
The issue is that Disk Utility (and Finder Get Info for the volume) is misleading. The value that Disk Utility reports is indeed the amount of space consumed on your hard drive, however, it is not the amount of space consumed on the drive by all the files and folders that you can see. And I'm not referring to the other files as simply "invisible", these other files and directories that make up the rest of the space you're "missing" are simply not presented to the operating system. These items are filesystem implementation details, and it isn't possible to copy them directly with file-level copying tools.
Does this mean you're losing data? Absolutely not. It's pretty easy to prove it to yourself too, just boot from your cloned volume and take a look at the capacity reports in Disk Utility. Here's an example I performed on my test machine:
** Booted from the original source volume
Source: 5,258,776,576 bytes
Clone: 5,025,562,624 bytes
**Booted from the clone volume
Source: 4,996,599,808 bytes
Clone: 5,250,097,152 bytes
Weird, eh? Having stared at this issue for three months, having developed a utility that would carefully analyze every single file that I could find and copy, I am 100% confident that I'm not losing a scrap of information with my file-level copy engine for the "Backup everything" cloning method. What I have learned and I am confident in saying is that Disk Utility can't really be used as a good measure of success for your clone. That's not to say that what it reports is wrong, it is simply misleading.
Can I use CCC to back up my BootCamp (Windows) partition?
Backing up non-HFS+-formatted volumes is not currently supported. I am investigating how to provide this support in a future release.
CCC requires an HFS+-formatted target volume. Why? And how do I format my new hard drive as HFS+?
Mac OS X is installed on an HFS+ filesystem. The HFS+ filesystem defines many types of metadata that describe non-data attributes of your files. Creation date, access control lists, permissions and ownership, Finder flags, and extended attributes are among the various metadata types defined in the HFS+ standard. To adequately back up all of your files and their associated metadata, CCC requires that your backup volume is also formatted as HFS+.
Additionally, Macintoshes can only boot from hard drives partitioned with either the Apple Partition Map (APM) scheme (PowerPC- or Intel-based Macs) or the GUID Partition Table (GPT) scheme (Intel-based Macs). The hard drive icons that you see in the Finder are volumes. The partition scheme of a hard drive describes how volumes are physically defined on the hard disk. Every hard drive has exactly one partition scheme and at least one volume. When you "partition" a hard drive, you simply create multiple volumes on that hard drive.
See the section of CCC's documentation labeled "Formatting your hard drive for use with Carbon Copy Cloner" (in the "Tips for people getting started with CCC" section) for step-by-step instructions for partitioning and formatting a new hard drive for use with CCC.
What are "Input/output" errors, and how can I resolve them?
When copying to or from damaged media, or a disk with a damaged filesystem, CCC may report "Input/output" errors. If no other major errors are encountered, CCC will produce a dialog box indicating:
"CCC detected "Input/output" errors during the clone. These errors are indicative of filesystem damage or hardware trouble with the source or target volume. Examine the CCC.log to determine the nature of these errors and consider replacing the affected hard drive if filesystem repair is unsuccessful."
Correspondingly, the CCC.log file will list the files that CCC was attempting to read or write when the error occurred:
02:13:49 rsync: read errors mapping "/Applications/Keynote.app/Contents/Resources/Themes/Shared/flowers_h.jpg": Input/output error (5)
02:14:39 rsync: read errors mapping "/Applications/Keynote.app/Contents/Resources/Themes/Shared/flowers_h.jpg": Input/output error (5)
02:18:20 rsync: read errors mapping "Users/bombich/Movies/1984.mov": Input/output error (5)
02:18:24 rsync: read errors mapping "Users/bombich/Movies/1984.mov": Input/output error (5)
02:18:24 ERROR: Users/bombich/Movies/1984.mov failed verification -- update discarded.
The exact errors may vary, and some may be duplicated. If the affected file path begins with a "/" and CCC reports a read error, it is probably your source volume (e.g. the boot volume) that is affected. Errors affecting the target volume often indicate that "mkdir" failed or other write errors occurred, or the path will indicate the name of target volume.
Occasionally these errors are reported because your filesystem is damaged, but these errors typically indicate that your hard drive is dying. You have a narrow window of opportunity to back up the data from that disk to another hard drive. Time is precious; components could fail at any moment rendering the drive completely unmountable. Read activity is stressful on a dying volume, especially a full-volume backup. When I run into these errors on a hard drive that has not been backed up, I immediately back up the files that are most important. Once the most important data is backed up, I then try to do a full-volume backup. Once all important data is backed up, I then may try a filesystem repair utility (e.g. Disk Utility or Disk Warrior) if signs of imminent faliure are not present (e.g. particulary noisy drive, or loud, repetitive clicks).
What if the dying drive's volume won't mount?
More often than not, you're completely out of luck. I provided tech support at a University many years ago and had the opportunity to witness many failed drives. Occasionally we were able to revive a hard drive for small amounts of time by letting the drive cool down (somewhere cool and dry, not cold) and then powering it up attached to a service workstation (e.g. don't attempt to boot from it, you may not have enough time). When a drive doesn't mount, it typically goes to the recycle center or to DriveSavers if the data is worth the recovery cost. If you're reading this paragraph now because you're in this situation, my heart goes out to you.
How do you check the accuracy of the backup?
From a statistical perspective, booting from the cloned volume is an excellent way of sampling the efficacy of the clone. If the OS consumes 10% of the data on the volume for example, and booting requires that the clone be accurate (and it does), then you have a really good sample. If the cloned volume boots, you can reasonably conclude that the clone was executed accurately.
While you're booted from the cloned volume, launching applications, checking your email, firing up iPhoto, etc. will increase your "sample" size and give you more confidence that the clone was executed accurately.
Can I do other things when the backup is being done?
Yes and no, it really depends. Performance will be affected during the clone (especially the first one) as CCC reads the entire source volume and writes to the target volume. If your work is "disk bound" -- that is your applications are reading or writing to either the source or target, then you'll notice a performance hit. If you're just reading email or writing a Pages document, then you probably won't notice the performance hit.
Affecting the accuracy of the backup task is something else that should be considered. Typically it's OK to work from the source volume while you're copying it, with the understanding that if CCC copied a file, then you open it, make changes, save it, then CCC completes the backup task, the modified version of your document is not backed up (this time around). Typically that's no big deal, the modifications will get backed up the next time the backup task runs. More importantly, though, if you're working with large files (mounted disk image, Entourage email database, VMWare/Parallels container) during the backup operation, it is possible that those large files could be modified while CCC is backing up that file. This won't affect the source file, but there's a good chance that the backup version of that file will be corrupt. For this reason it is a good idea to stop using applications that may be modifying large files.
What makes a volume bootable?
Bootability comes down to a few simple rules:
- The hard drive enclosure must support booting a Macintosh (applies to external hard drives only)
- The computer must support booting from the hard drive's partition format (e.g. APM vs GPT vs MBR)
- The cloned filesystem must have all the required components of Mac OS X
- The cloned operating system must be properly "blessed"
When you buy a hard drive enclosure that you intend to use to boot your Mac, caveat emptor -- not all enclosures will boot a Mac (or any machine for that matter). Be sure to check that the manufacturer or vendor supports booting a Mac with the enclosure. You may even have to pay attention to whether they support booting your particular architecture (e.g. PowerPC vs. Intel). Some Western Digital enclosures had this problem. If you can't find solid proof that an enclosure will boot your Mac, don't buy it.
Once you have your new hard drive (in an enclosure or installed into your computer), you need to a) apply a partitioning scheme to the disk and b) format one or more volumes on the disk. Even if you do not plan to "partition" the disk, that is, slice the disk into smaller volumes, you still need to apply the correct partitioning scheme to the disk. Every disk has a partitioning scheme, even if it only has a single volume. I go into plenty of detail on this in this section of the documentation, so I won't rehash it here. Suffice it to say that PowerPC Macs and Intel Macs boot from different partition schemes, and each from a different partition scheme than what the overwhelming majority of hard drives ship with.
Rules #1 and #2 are external to the functionality of CCC. CCC will not apply a partition scheme to your disk, nor will it affect or modify your partition scheme in any way*. Also, if a hard drive enclosure won't boot Mac OS X, there's no software solution that will resolve that problem. Once you're sure you have those rules in hand, we can look at rule #3.
* OK, there's a small caveat to this for complete transparency. When doing a block-level clone, CCC will reformat the target volume. As a result, it must update the partition table entry for the target volume. Functionally, however, CCC is having no substantive effect on the partitioning of your disk.
Rule #3 is pretty intuitive -- if you want the operating system to boot, it must be whole. If you've cleared rule #2, CCC will tell you whether your target will have all the necessary components to boot Mac OS X. I should be clear that this is not exhaustive -- CCC will verify that the following items are present on the source and will be copied in their entirety to the target volume:
/Library
/System
/bin
/etc
/mach_kernel
/private
/sbin
/tmp
/usr
/var
So, if you choose to exclude /Applications or /Users for example, the cloned volume would still very likely boot. How much functionality you'd have is another story. Likewise, if the source volume's OS is not whole and, as a result, not bootable, CCC doesn't do an extensive analysis of the OS to confirm that it will boot. The bottom line, though, is that CCC will give a pretty good indication about whether your target volume will have the right OS components to actually boot.
Rule #4 is perhaps the least understood, so I'll do my best to explain it here. When a Macintosh boots, this happens:
- The computer performs a Power On Self Test. When that test succeeds, you hear the characteristic Macintosh startup chime.
- The computer's pre-boot firmware (software that is embedded in a chip on the computer's motherboard) takes account of the hardware that is present, builds a device tree, and determines which hardware device to boot from (more on this in a bit). For the sake of simplicity, let's suppose a machine is configured to boot from particular volume on a particular hard drive.
- The firmware of the computer accesses the filesystem of that volume and determines the location of the file, or folder containing the file, that is "blessed" to initiate the operating system.
- That file is executed by the firmware and control of the hardware is handed over from firmware to the booter.
- The booter executes the kernel of the operating system and pre-loads a kernel extensions cache.
- The kernel initiates the rest of the boot process (primarily by executing launchd)
The gist of all of this is that every bootable volume must indicate the location of the system folder. The path of the folder turns out to be irrelevant, because the HFS+ filesystem simply stores the "inode" of this particular folder. The inode is basically like a street address for the file, it indicates where on the disc platter the folder is located. This information is stored in the HFS+ Volume Header, but you can easily see the current state of this information using the "bless" command in the Terminal application. For example:
bash-3.2# bless --info /
finderinfo[0]: 116 => Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 546345 => Blessed System File is /System/Library/CoreServices/boot.efi
finderinfo[2]: 0 => Open-folder linked list empty
finderinfo[3]: 0 => No OS 9 + X blessed 9 folder
finderinfo[4]: 0 => Unused field unset
finderinfo[5]: 116 => OS X blessed folder is /System/Library/CoreServices
The relevant information in this case is that the blessed system folder is at inode 116, and that path (for the human reader) is /System/Library/CoreServices. PowerPC-based Macs need only this piece of information to boot. PPC Open Firmware will find that directory, then execute the file named "BootX" within that directory. Intel-based Macs also use the "Blessed System File" information. In this case, that is the file at inode 546345 and (again, for the human reader), that file is located at /System/Library/CoreServices/boot.efi.
It is important to note that blessing a volume is different than specifying a boot device. Blessing a volume simply updates the information in the HFS Volume Header that indicates where the blessed system folder and file are located. When you specify a particular volume as the startup disk, on the other hand, the computer stores a reference to that volume in the "Non volatile RAM" -- basically a small section of RAM whose contents are not lost when the machine loses power or is shutdown. The importance of this disctinction, and all four of these rules for that matter, is that simply setting a volume as the startup disk may not be sufficient to actually boot from that volume.
Can I backup directly to an AFP or SMB network file share? How about to a Time Capsule?
CCC can back up directly to an HFS+ formatted local volume, or to a disk image on any writable network volume. CCC cannot, however, backup directly to a network filesystem (e.g. AFP, SMB, Airport Extreme "Airdisk", or Time Capsule). There are significant technical limitations to backing up an HFS+ filesystem to a non-HFS+ filesystem (most notably preservation of ownership and permission information), therefore I recommend and support backing up only to a disk image on non-HFS+ filesystems.
How do I make the banners go away?
Please see the section of CCC's documentation labeled "What does CCC cost?" for complete details on this subject.
How do you pronounce "Bombich"?
Like the pen, not the dog. (Bombick) ;-)