![]() |
How long should the clone or backup take? |
||
The speed at which Carbon Copy Cloner transfers data from one volume to another depends on numerous factors such as:
- The interface through which those hard drives are connected to the computer
- The speed of the source and destination hard drives (RPMs, seek time)
- The method used to transfer data from one volume to another (file-level copy, block-level copy, backup to a disk image)
- The chipset in an external hard drive enclosure
- Fragmentation of data and how close the source volume is to full capacity
- The size distribution of files on the source volume
- The health of the source and destination hard drives
- The quality of cables that connect the source and destination volumes to your computer
- The architecture and speed of the computer's processor(s) and any CPU or disk-based activity that the backup task must compete with
Below we will discuss how these factors affect performance, and what you may (or may not) be able to do to improve the speed of your backup.
Hardware interface performance (USB, Firewire, SATA)
When shopping for an external hard drive enclosure, you have a choice between USB, Firewire (400 and 800), and eSATA interfaces. When given the choice, we recommend purchasing a hard drive enclosure that supports multiple interfaces, but at least Firewire 400 and ideally Firewire 800. The results of several (non-scientific) benchmark runs are provided in the table below, illustrating that Firewire offers better performance for your backup.
Bandwidth achieved during a block-level clone |
||||||||||||||||||||||||||||||
|
Table 1: Results from several benchmark runs using Carbon Copy Cloner 3.3.4 on a PowerMac G5 (Dual 1.8GHz, 1.25GB RAM) running Mac OS X Leopard, 10.5.8. Each test involved a block-level copy between two identical Hitachi Deskstar 750GB, 3.5-inch 7200RPM SATA hard drives. A block-level copy was chosen to reduce as many variables as possible, especially file size distribution, hard drive seek time, and OS/CPU performance factors. The resulting values should be very close to what the interfaces in question were actually capable of. Two external hard drive enclosures were used for the tests: a MacAlly G-S350SUA and a NewerTech Voyager Q. The source and destination volumes were swapped between the enclosures in several of the tests and it was determined that there was no substantive performance difference between the two enclosures. SATA = the internal SATA slots in the PowerMac. The achieved bandwidth is an approximate (+/- 0.50MB/s) average determined using samples of disk activity reported by the Activity Monitor application.
The speed of the source and destination hard drives
Traditional hard disk drives (HDD) have platters that spin at very high speeds — 4200, 5400, 7200, 10,000 and even 15,000 RPM. Most laptop systems typically have a 2.5-inch drive that spins at 5400RPM while desktop systems typically have a 3.5-inch drive that spins at 7200RPM. The faster a hard drive's platters spin, the faster data can be read from and written to them. While the 2.5-inch "mobile" external hard drive enclosures are very convenient and portable, you'll see faster backup times to a larger 3.5-inch hard drive enclosure.
Solid-State Drives (SSD) store data on solid-state memory rather than magnetic rotating platters. SSDs are less susceptible to physical shock, quieter, and have lower access time and latency. Due to the lower latency and faster seek times of SSDs, you will see considerably higher performance when backing up to a volume that resides on an SSD hard drive. SSD hard drives are still quite a bit more expensive than HDD-based hard drives, so we don't recommend running out to buy one to be used only for backup purposes.
The method used to transfer data from one volume to another
Backing up data usually consists of copying files directly from one hard drive to another. While this is certainly the most common and often the most appropriate method of backing up data, it isn't the only choice. Carbon Copy Cloner offers several different methods of backing up data: file-level copies from one hard drive to another, block-level copies, where blocks of data are copied from one hard drive to another, disk image backups to a locally-attached or network shared disk, and backing up directly to a disk attached to a remote Macintosh. Each of these backup methods has strengths and different applicabilities, and each has different performance characteristics.
The following figure compares the performance of a file-level backup to that of the other backup methods.
Time to completion |
||||||
|
||||||
Hours |
Figure 1: Results from several benchmark runs using Carbon Copy Cloner 3.3.4 on a PowerMac G5 (Dual 1.8GHz, 1.25GB RAM) running Mac OS X Leopard, 10.5.8. The source volume in each case was a Hitachi Deskstar 750GB SATA hard drive with 166 GiB data. To remove any effect of the underlying hard drive's performance, the destination volume (or underlying destination volume) was an identical Hitachi Deskstar 750GB SATA hard drive attached directly to the applicable machine via Firewire 800. Except for the first case, each backup leveraged the "Incremental backup of selected items" cloning method with no additional options. Each disk image was a new sparse disk image created by CCC during the backup. 1: The remote Macintosh was a Mac Mini, 2.4GHz Intel Core 2 Duo, 4GB RAM running Mac OS X 10.6.4 Server. The two machines resided on the same gigabit ethernet network. 2: The network shared filesystem was hosted via AFP on the aforementioned Mac mini and across the same network.
Block-level cloning
As illustrated by the results in Figure 1, block-level cloning with CCC is considerably faster than file-level copying methods. To understand the difference in how a hard drive behaves during a block-level vs. file-level copy, consider this analogy. Suppose you're at the grocery store and you're picking up groceries for the week. In the first scenario, you have a list that is organized by aisle so you can cruise up and down each aisle only once, ending at the checkout. In the second scenario, your list is organized alphabetically, so you end up making frequent visits to the same aisles multiple times. In the end, you get all the groceries that you need, but the first scenario is clearly faster. When your hard drive's reading and writing heads move from one aisle to the adjacent aisle, they copy the data much more efficiently than if they are darting all over the disk getting the files in alphabetical order. Block-level copies tend to complete the backup in 50% to 75% of the time that an equivalent file-level backup takes.
While block-level clones of an entire volume are quite a bit faster than an equivalent file-level copy, they do have some disadvantages in certain scenarios. For example, if the destination volume already has a considerable amount of data on it from a previous backup, a file-level backup will copy only the items that are different on the source and destination. This subsequent file-level backup will often be much faster than re-cloning the entire volume. Block-level clones also require that the source and destination volumes both be unmounted for the duration of the clone. While this typically is not a hardship, it automatically excludes your startup disk. It is generally not worth putting the time and effort into procuring a third volume from which to boot while cloning your startup disk. Unless you are transferring hundreds of gigabytes from one volume to an empty, new, and larger volume, we recommend file-level copies for backing up your startup disk.
Lastly, please keep in mind that block-level clones and file-level backups offer the same level of fidelity for your data. Do not seek a block-level clone for comfort at the cost of time or convenience.
Backing up to a disk image
Disk images are handy filesystem containers. Rather than having the entire contents of a filesystem exposed in a folder or at the root-level of a hard drive, everything is stored in a single file. This allows you not only to store a backup of your Mac on a non-Apple formatted disk without losing important filesystem metadata like ownership and permissions, it also allows you to store your backup on a network shared filesystem (e.g. a disk attached to an Airport base station, another Mac's disk accessed via AFP, a PC accessed via SMB). You can back up to a new or existing disk image in CCC by choosing the appropriate menu item from the Destination menu.
While you can browse and restore files from a disk image just like any other volume, you cannot boot from a disk image. This makes full-volume restores a little bit more involved than restoring from a direct-to-volume backup. You can restore the OS from a disk image to an actual hard drive and the resulting restored volume will be bootable, but that is an additional step. Further, backing up to a disk image is always slower than backing up directly to a hard drive, especially when backing up to a disk image on a network shared filesystem.
Backing up to a remote Macintosh
CCC offers a feature to back up directly to another Macintosh via the "Remote Macintosh..." item in the Destination menu. With this backup method, CCC copies your data over a secure network connection directly to a hard drive connected to another Mac. As demonstrated by the benchmarks in Figure 1, backing up to a remote Macintosh over a gigabit network connection rivals the performance of backing up to a locally-attached hard drive. The performance gain is even more marked when leveraging CCC's "Compress data passed over the network" option with a slower network connection. In one test we were able to achieve data rates of 5.4MB/s over a connection with a theoretical max of 1.25MB/s. "Your mileage may vary", achievable compression depends on the nature of the data that you're backing up, but this functionality is especially ideal for setting up automated offsite backups.
Other factors that affect performance
More files = more seeking = longer backup times
Anything that increases the amount of seeking that your hard drive must do will have a noticeable impact on your backup performance. A source volume with a high level of fragmentation, for example, will require a lot more seeking than a volume with little fragmentation. The size distribution and total number of files will also affect the amount of seeking required. For every file that is copied, the heads of the drive must first seek to the filesystem directory at the beginning of the volume to determine where on disk the file resides, then seek out to that section of the platter to retrieve the file's data. In general, the more files that you copy, the longer your backup time. Suppose, for example, that you have 10GB of data to backup: transferring one hundred 100MB files will copy much faster than 100,000 100KB files. Putting this to the test using the same gear as in Table 1, it took about 7 minutes to copy the 100 files whereas copying the 100,000 files took nearly 12 minutes. To carry on the grocery store analogy from earlier, you can imagine that it would take a lot longer to get all the rice that you needed if you had to purchase it by the kernel vs. by the bag.
Hard drive health can affect throughput and reliability
The health of the source and destination hard drives will also have an effect on your backup performance if their health is poor. SMART status monitoring is one method of tracking drive health, though it only reports "fail" and "prefail" conditions, it won't report on pre-threshold conditions that will start to degrade your backup performance (such as the number of sectors that have failed). To track your hard drives' performance over time, you can periodically copy some large files to your disks while monitoring disk activity in the Activity Monitor application to determine if their performance characteristics have begun to change.
You get what you pay for — purchase quality cables and enclosures from reputable dealers
The quality of the cables that connect the source and/or destination volumes to your computer, as well as the quality of external hard drive enclosures will not generally have a direct effect on performance, but bad cables and poorly architected enclosures can cause erratic behavior during various stages of the backup. During some of the benchmarking tests performed for this article, for example, we encountered a USB cable that consistently caused the "Erasing the destination" stage of a block-level copy to hang. It caused the same behavior in Disk Utility, and the behavior was resolved by replacing the cable.
We've also seen cases where a particular hard drive enclosure works fantastically over one interface but fails at random locations during backups over another interface. While "one good interface" is technically sufficient, we recommend warranty replacement of enclosures that are defective on any interface.
Finally, some enclosures claim support for daisy chaining, but don't necessarily perform well in scenarios that involve high-bandwidth data transfer between any two interfaces. This is purely anecdotal, but something to consider if you're experiencing erratic behavior while daisy chaining devices off an external hard drive enclosure.
Competition can inhibit performance — try disabling bandwidth-hungry services like Spotlight on the destination volume
Lastly, the architecture and speed of the computer's processor(s) can have an effect on backup performance, but usually only if the computer is particularly slow, busy with other tasks, or if the source and destination volumes are capable of very high-bandwidth transfers (e.g. hardware RAID). Considering other reasons not to back up your data while you are heavily using the system, we recommend that you schedule your backup tasks to occur when you are not actively using your computer.
Spotlight indexing is one particular process that CCC typically must compete with for disk bandwidth. As you copy new data to your destination volume, for example, Spotlight wants to read those "new" files so it can index their contents. Having a Spotlight index of your backup volume may be unnecessary as you probably want to search for files only on your source volume. To address performance problems during a backup task, CCC will suspend Spotlight indexing for the duration of the backup, then re-enable it when the backup task has completed.