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.

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.

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 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.

Backing up to network storage: Disk image containers vs. a folder directly on the network sharepoint

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.

Figure 1 illustrates the most important benefit of backing up to a disk image when the destination is a network shared volume: performance. It's difficult, or impossible, to determine how a network appliance will perform based on its specifications. Vendors of network appliances rarely report CPU specifications, choosing instead to report performance in terms of bandwidth achieved. The actual bandwidth that you achieve, however, will be based on the number of files you're copying, the file size distribution, and the number and size of extended attributes in the source data set. Copying a single, large file to a network volume will achieve the maximum potential bandwidth, while copying lots of small files will take ages.

Network appliances are well suited to the task of serving media to multiple workstations, but they aren't necessarily great backup appliances. Media files are generally large and the required data rate for streaming media is relatively low. Consider a 1-hour, 1GB HD movie file. Streaming 1GB over the course of an hour requires only 0.27MB/s. That's easy, even over a weak wireless network! If you want to back up 100GB in an hour, and that 100GB is comprised of a million smaller files, that's when you need some more muscle behind the file server, or you need to buffer the smaller writes locally by using a disk image. The Airport Base Station folder-to-folder backup exemplifies this problem. Copying the 21GB data set to a hard drive attached to another Mac mini via File Sharing took an hour. When that same destination disk was attached to the AEBS, the same backup task took 9 hours. Backing up that same 21GB of data to a disk image on the same disk took only 28 minutes. That's an 18X performance difference!

Conclusions and recommendations

1. There is no performance advantage to backing up to a disk image when the destination volume is a locally-attached, HFS+ formatted volume.

   If your destination volume is a locally-attached, HFS+ volume, we recommend backing up directly to a folder on this volume.

2. Backing up to a disk image on a network volume offers a significant performance advantage.

   If you are backing up to a network volume, we strongly recommend that you back up to a disk image on that network volume. To make this easier and more transparent, CCC offers a preference to automatically create a disk image on network volumes. Choose "Preferences..." from the Carbon Copy Cloner menu to access this setting.

3. Backing up directly to a remote Macintosh offers a modest performance advantage over backing up to a disk image on the same disk accessed via file sharing.

   Backing up directly to a remote Macintosh can also yield a bootable backup. If this is not required, however, or if the setup required for backing up to a remote Macintosh is too daunting, we recommend backing up to a disk image on the other Macintosh accessed via File Sharing.

4. Performance of network storage appliances varies wildly. Caveat emptor.

   Network file sharing is a CPU-intensive task, so targeting an actual Mac or PC hosting the network sharepoint will likely offer a significant performance advantage over cheaper network appliances.

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. The Performance suggestions section of the documentation explains how to disable Spotlight indexing for your destination volume.