Introduction
Note: These instructions provide the command-line instructions for manual backups or clones. Carbon Copy Cloner follows the rules laid out below — you do not need to follow any of these instructions if you use Carbon Copy Cloner.
There are a few basic rules that you need to follow when cloning a disk with Mac OS X System files in order to get a bootable clone:
1. File permissions must be preserved.
Many files belong to the root user, so you cannot simply copy these files from the Finder. There are other issues with permissions, such as the setuid bit (in English, that is a feature of a file that, when executed, gives the file or application
the same privileges as the owner of the file; if the owner of the file is root, then root privileges are granted during the execution of this file). Copying via the Finder sets the owner of the new files to the user that copied them and assigns a default set of permissions. Many applications and system files will not work properly with the default Finder settings.
2. The invisible Unix system files must be copied.
Mac OS X is driven by a Unix flavored operating system called Darwin. Darwin system files reside at the root level of the derive in four folders: /private, /bin, /usr, and /sbin. These directories hold all the critical files that allow the computer to boot up and have basic functionality.
3. Unix-style links must be preserved.
Symbolic links and hard links are different from the Mac aliases we are familiar with. Likewise, the way we deal with them will not be the same. Because there are some critical symbolic links on a Mac OS X disk, the integrity of these files must be preserved by the utility you use to clone/backup the disk. Some people are very familiar with the error upon booting that states “/etc/master.passwd: Not a directory”. This is because the /etc symbolic link to /private/etc was broken.
4. Some directories are populated by the System after booting, and are thus unnecessary to preserve, however, although empty, they may still have to be present.
Some directories are populated by the System. For example, the Volumes directory is populated with directories corresponding to the names of Volumes you have on your system. If you insert a Zip disk, a new directory in /Volumes is created with the name of the Zip disk. These directories are called “mountpoints”, and are created “on-the-fly” by Apple’s autodiskmount utility. Because these directories do not contain data on your boot volume, they do not need to be copied during a clone operation. The Volumes directory is just a placeholder (and the OS will recreate the Volumes directory on bootup, so it is unnecessary to recreate). The /dev directory is also a placeholder for system devices, such as disk drives, output devices, and communications devices. The list of devices in this directory is created each time the computer is booted up and when new hardware is added, so it is unnecessary (and a little difficult) to copy the items in this directory. Because this is a Unix system directory, however, you will not have a bootable volume unless this directory is recreated on the cloned disk. Creating an empty directory is sufficient. Likewise, it is important to backup mach_kernel (the most important file in the system), but “mach” and “mach.sym” are destroyed and recreated each boot by the /etc/rc boot script. Finally, the Network folder at the root level does not need to be backed up because it is populated by the System on startup.
5. Resource forks must be preserved
While Apple is trying to move away from Resource Forks, there are still many applications and documents that use them. Because of this, any backup or cloning utility must preserve the resource forks. If you try to clone a Mac OS X disk without preserving resource forks, many of your personal documents will be damaged.
* Pre-flight checklist
1. Make sure the “Ignore privileges on this volume” setting is not checked for your source or target volume (Note: this setting is called “Ignore ownership on this volume” in Jaguar). To check this setting, click on the target volume, choose “Show Info” or “Get Info” from the File menu in the Finder and select the Privileges menu (Jaguar: click the disclosure triangle next to ownership and permissions). Make sure the box at the bottom is NOT checked, otherwise permissions and ownership settings will not be preserved, no matter what tool you use to copy files.
2. Run Disk Utility on the target and source volumes before cloning. This is not required, but is a good idea to avoid disk or directory-related problems during cloning. If you are cloning an operating system with ditto or asr, I recommend that you erase the drive with Disk Utility prior to cloning.
* Cloning a disk or backing up your drive with ditto, rsync, hdiutil and asr:
Ditto is a command-line utility that ships with Mac OS X. Ditto preserves permissions when run as root and preserves resource forks by default. Ditto can be used to clone your system with the following step:
sudo ditto -X / /Volumes/Backup
rsync can be used to make a bootable clone as well. In addition to basic file copying, rsync also offers the ability to synchronize the source and target volumes — it can copy only the items that have changed, thus subsequent clones, or backups, are much faster. The syntax is pretty easy:
sudo rsync -xrlptgoEv –progress –delete / /Volumes/Backup
That will backup your entire drive, deleting anything from the target that is not on the source drive (synchronizing, that is). Rsync also preserves resource forks (that’s what the “E” argument is for) and will give you a bootable backup just as well as ditto. Learn more about using rsync to regularly backup your drive to a remote machine.
While it doesn’t give you a bootable clone, backing up to a disk image does offer flexibility in the location of your backup as well as backup portability — your entire volume is located in a single file. Restoring from disk images is pretty easy as well, just mount the disk image and treat it like any other volume. Backing up a volume to a disk image (UDZO means a compressed disk image in this case) is simply done with this one command:
sudo hdiutil create /Volumes/Backup/mikes_laptop.dmg -format UDZO -nocrossdev -srcdir /
Finally, the ideal tool to use for creating bootable clones of your volumes is Apple Software Restore. Apple Software Restore, or asr, is also a command-line tool built-in to Mac OS X. While asr essentially functions like ditto in its file-copy mode, it also has the ability to clone a volume at the block level, preserving every last bit of data on the volume.
asr syntax for volume cloning is also pretty easy:
sudo asr -source / -target /Volumes/Backup -erase -noprompt
The “-erase” argument is optional, though recommended when cloning an operating system. Merged OSes are not usually very happy. To use asr in block-copy mode, you must be able to unmount both the source and target. That is, you can’t block-copy your boot volume. Learn more about this in the CCC documentation about asr.
* The Command-Line-Free version
I have developed a utility that encapsulates the power of asr and rsync and performs all the necessary steps to clone a drive. Download Carbon Copy Cloner here.
* Disclaimer
These instructions require the use of command line utilities. Using command line utilities without experience can have unpredictable consequences including loss of data. Please be mindful of this — the author makes no claims to the fitness of these instructions, and makes no warranties explicit or implied to their effectiveness or safety.
Created July 11, 2001
Updated for Mac OS 10.1 on November 4, 2001
Updated on December 18, 2001 with general info and principles behind successful Mac OS X backups.
Updated January 7, 2002: removed incorrect comment about ditto mishandling symbolic links
Updated January 18, 2002: added info about hfspax, minor modifications to ditto instructions, and comment about resource forks
Updated February 28, 2002: minor modifications, added info about blessing the target, added comments on unlocking files on source.
Updated March 17, 2002: corrected terminology about the setuid bit.
Updated October 9, 2002: Added disclaimer.
Updated January 25, 2007: Removed the overwhelming bulk of code, it’s so much easier than it used to be. Also added rsync and asr alternatives.
