Among the many tools out there for cloning drives and performing full-system backups, one came to my attention for being both free (and open source) and powerful: Clonezilla, a product of the Free Software Labs of the National Center for High-Performance Computing in Taiwan.
Clonezilla's power, however, is matched by complexity. You can get a lot out of it, but at the cost of paying close attention to what you're doing. Here's a guide to getting just what you need from Clonezilla -- without wreaking havoc on your system or being swallowed by the monster.
Clonezilla performs two basic kinds of disk-copying operations: disk-to-disk and disk-to-file. Disk-to-disk is exactly what it sounds like -- a way to directly copy the contents of one disk or partition to another. Disk-to-file copying allows a disk or partition to be saved to a series of files, which are kept together in a directory located on either a network-attached disk or a locally mounted one (for example, a USB-connected hard drive).
Clonezilla comes packaged in an ISO image file, which can be burned to a CD and booted. It can also be unpacked to a USB flash drive and booted if your system supports that; late-model systems generally do.
During boot, the screen will be flooded with various Linux system messages, most of which you can ignore until "Choose language menu" comes up. After you choose a default language and a keymap (again, the best option for that is usually "Don't touch keymap"), you'll be brought to the actual Start Clonezilla menu. From there, select your copying method.
- If you want to back up a disk to a file, choose
- If you want to clone a disk to another disk, choose
- If you want to restore a disk from a file, choose
device-image. You can also use this option to restore to multiple local disks at once.
The hard drive alphabet soup
Before copying disks with Clonezilla, Windows users should note that the program doesn't use the standard Windows drive-letter notation for the drives and partitions in your system, but rather the Linux method. The first physical drive is called
/dev/sda, the second
/dev/sdb, and so on. Partitions are referred to by number: the first and second partitions on the first drive would be
/dev/sda2, the partitions on the second drive would be
/dev/sdb2, and so on.
One way of sorting out the potential confusion over which drives are which is to pay attention to both the size and the manufacturer information that Clonezilla reports back about each drive. This usually provides enough information for most people to differentiate between drives. If you're still confused, you can use a tool like SIW in Windows to learn which drives have which make, model, and serial information associated with them.
Clone a disk to a file
When you clone a disk to a file via
device-image, you need to specify a target location for the file. These are your options:
local_dev-- A local disk such as another hard drive (or partition) or a locally attached external USB drive.
ssh_server-- A remote SSH server. Note that "remote" doesn't have to be on the Internet somewhere; it can be another network-attached machine on your own LAN. This is the standard method I've adopted for cloning to a file across the network.
samba_server-- A remotely mounted SAMBA (Microsoft Windows Network or Network Neighborhood) server. I don't recommend this option unless you're a whiz at getting SAMBA to work in Linux; you can get SSH working with less effort.
nfs_server-- An NFS server somewhere on the network. Again, this one's mainly for pros who already know NFS and are comfortable working with it. If you're not, this isn't a good place to start your crash course.
Most people will want to use one of the first two options for the sake of simplicity. A locally attached drive of some kind is easy to work with and quite fast. An SSH-attached server is not as fast, but more flexible. You can put the file on any system running SSH, including Windows.
Windows doesn't include an SSH client by default (barring the additional Windows Services for Unix package). I've used the freeSSHd server, which has proven to be a handy way to allow a Windows system to act as an SSH server for an instance of Clonezilla. Here are a few tips worth keeping in mind if you use the two programs together.
To make it easy for Clonezilla to connect, set up a local user in freeSSHd named
root since that's the default name Clonezilla attempts to use for SSH connections. Use the "Password stored as SHA1 hash" option, not "NT authentication."
Clone a disk to a disk
With device-device cloning, you have two options. With local-to-local, you can copy disks or partitions between locally attached drives, while local-to-remote lets you boot Clonezilla on another machine somewhere on the network, then use that machine as the target for the first machine's disk image. (If you want to perform one-to-many cloning, where you use one image to build multiple systems, you may want to go with the server edition of Clonezilla.)
One major annoyance: With local-to-remote cloning, Clonezilla will print some commands on-screen for you to use on the target machine, but doesn't provide an actual menu option for those same commands. You have to type them in manually.
Copying a whole disk to another whole disk is typically easy enough, especially if the target disk is larger than the source disk. One of the expert options during the restore process is "Try to resize the file system to fit partition size," but you can also use the Disk Management tool in Windows for FAT and NTFS partitions or the Parted tool in Linux to accomplish the same thing after the fact.
Copying partitions between disks is also usually pretty easy, although two major caveats apply. First, you have to make sure the target disk has enough room for the partition you're copying. It seems obvious, but it's an easy mistake to make. Second, copying individual partitions may not produce the results you expect if you're dealing with an operating system. With many Windows Vista and Windows 7 systems, for instance, simply copying the main system partition won't give you a bootable computer. You may need to copy the boot loader and the rescue partition as well, which works only if you copy the whole disk. If you perform a full-disk copy operation with Clonezilla on an OS disk, you'll be prompted to copy the boot loader as well (and you should).
If you choose a network cloning option, like SSH, Clonezilla will ask you to configure the network for the local machine via DHCP, a static address, or PPPoE. The first option should work in most cases; the second is only if you have no DHCP server or you need to punch in a network address manually for some reason.
Beginner vs. expert
Clonezilla gives you two basic options when performing a cloning operation: beginner and expert. Beginner handles most everything automatically. Pick expert only if you need to do any of the following:
- You want to select which programs Clonezilla uses to perform the cloning process. By default, Clonezilla will automatically detect the file systems being backed up and select the appropriate programs to accomplish this. You need to override this only if you have some arcane partition type that Clonezilla can't automatically detect for some reason.
- You need to manually set options for handling Windows volumes. Clonezilla can automatically remove page and hibernation files from clone images (since they're rarely needed), but only in expert mode.
- You want to manually set the compression options. The default compression options are optimized for modern multicore processors, but if you want to force another compression option (or disable compression entirely), you can do that.
- You need to split the image into chunks of a size other than 2GB. By default Clonezilla saves disk images in pieces no larger than 2GB to ensure compatibility with FAT32 volumes.
- You want to set other corner-case options. These include such things as not using DMA for the hard drive (to work around certain disk controller bugs) and forcing Clonezilla to skip over disk errors.
Clonezilla has a number of habits that should appeal to experts. When you set up a cloning operation, for instance, Clonezilla saves a copy of the command-line sequence used to trigger the same operation to the
/tmp directory and allows you to access it from the console. Command-line actions are also echoed to the display right before the copy operation starts, providing another handy way to make note of them.
The copy operation
Once you answer enough options to begin the actual copy operation, you'll be bombarded -- that's the best word for it -- with a lot of informational text about the choices you've made. Fortunately, Clonezilla gives you a convenient way to filter the signal from the noise.
Commands being executed by Clonezilla are displayed in green. Green text also includes things like the exact command-line options passed to subprograms within Clonezilla, which you can note down and reuse in the future.
Key information will be displayed in yellow. Pay close attention to these, because they consist of either choices you need to confirm or information about operations you're going to commence.
Any alerts -- problems with the copy operation, for instance -- are displayed in red. If something in red pops up, it's not always a sign of disaster, but you'll want to pay close attention to it.
An estimated time of completion for the copy operation will be shown onscreen as the process unfolds. Keep in mind that, if you're copying multiple partitions, the time estimate you see will be for only the current partition, not the entire job.
As noted above, Clonezilla's power comes at a price. You have to pay close attention to what you're doing, or you could find yourself (or, more precisely, your data) in deep trouble. Apart from the general word of caution, a number of specific caveats deserve to be spelled out.
Going back a step in the cloning process is nearly impossible. This is my single biggest beef about Clonezilla. If you enter the wrong information at any stage of the process, you usually have no choice but to quit the whole thing and start over. Proceed with caution at every step and don't hurry, especially when restoring an image.
It can be difficult to figure out why something failed. A Clonezilla failure will typically be due to a disk error on either side of the copy process; a network failure, if you're copying across a network; or not enough free space on the target drive. The program suggests the last of those three as a default possibility if the copy process is interrupted since it's one of the more common reasons for a botched backup operation. But it's not always the reason, and you will often have to conduct your own troubleshooting to figure out what went wrong.
The blizzard of messages during the copy operation can be distracting. Rely on the previously described color-coding to avoid being overwhelmed. Most of the stuff Clonezilla prints to the console is for the sake of completeness. The really important stuff will be in yellow, with crucial informational data in green and warnings in red. Everything else can be more or less ignored.
Pay double attention to all prompts in yellow. Why? Because everything you agree to in yellow is most likely irreversible. If you're about to overwrite a drive with an image, take the time to make sure it's the right drive. A few moments now can save you a lot of grief later.