Three Free Ways to Clone Windows XP in 2012: Follow-up

Like many other technology junkies I know, I have this habit of playing with operating systems. There’s always a new or improved modified Linux distribution coming down the pipe, so on any given day you might find me replacing my Windows desktop with an Ubuntu or Linux Mint desktop, or perhaps I’ll be adding another partition of Windows or some other operating system to my hard drive. Windows 8 is on its way, so I expect I’ll soon be installing the most recent preview release of Microsoft’s next operating system just to see how well it performs on my current hardware. Sometimes I simply get a kick out of modifying whatever operating system I’m currently using, usually by randomly editing registry settings on my Windows system just to see what will happen. (I’m kidding about toying with the registry settings. That would be unwise, and I do not recommend it unless you know what you’re doing. Unless you really know what you are doing.)

Since I’m messing up making changes to my system(s) so often, I need to be certain I can easily recover my original hard drive or partition — you know, the one that works properly — and I prefer to do so from a perfect image or from a clone of my system. To satisfy this need, a few months ago I tested three free imaging/cloning solutions for Windows XP. (I focused on Windows XP because at the time I wrote the article the 11-year-old operating system was still my “daily driver“.) The article focused on the process of making images or clones using the applications I tested; I’d promised I would return with a report on how well each solution restored from those images or clones. Today I’ll deliver on that long-delayed promise of describing how well each application performed in my testing of the restoration process.

Briefly: The Differences Between Cloning and Imaging

At the time the first article was published, I was satisfied with what I’d written; now that I look back on my post, I believe it would have been helpful for me to have clarified the difference between cloning and imaging. Though no readers complained about my liberal swapping of the terms throughout the text, I feel that I may have left some readers thinking that cloning and imaging are precisely the same operations. In fact, though the end result may be the same — producing data that will enable us to restore our hard drive or partition — the way that data is manufactured and stored is considerably different in both cases. Knowing how the methods differ will produce a better understanding of the testing results I’ll be reporting in this article.

So, briefly: The term “cloning” is usually applied when making a perfect copy of a drive or partition onto another drive or partition. The clone, or reproduction, is pretty much an exact duplicate of the original drive. The size and the type of the drives may differ considerably, but data on the drives is identical. Since the clone is a perfect copy of the original drive, you can restore from it — but you can also skip that part of the process altogether and simply boot from the clone. In fact, cloning is the process that is usually undertaken when moving from one drive to another (such as when upgrading to one that has more storage).

Restoring from a cloned drive simply involves cloning the cloned drive. That is, in whatever utility used to perform the operation, simply select the cloned drive as the source drive and the original drive as the destination drive. This will restore your cloned drive to your original drive. (The same goes with partitions.)

The term imaging, on the other hand, is more properly used to describe the process of making a perfect copy of a drive or partition — but rather than producing a bootable drive, the copy is stored in a data representation of the drive or partition which can be restored from. That data representation is referred to as an image, and it can be assembled and then stored in a variety of ways, depending on the application that produces it. Images can usually be compressed to a smaller size in order to conserve storage space, and can be stored either on another hard drive or partition, or on the same hard drive or partition from which the image was created. (With one of the imaging solutions I tested, DriveImage XML, the image can even be broken up into smaller sizes so that the image can be stored on multiple optical discs.)

Restoring from an image involves selecting the image as the source and a drive or partition as the destination. Since images are composed and stored in various ways, however, the process can often be a tad less straightforward than cloning. Throughout this article I’ll note some of the differences in images the utilities I tested produced.

Though I take pains to note the differences between cloning and imaging, in much documentation and discussion the terms are used interchangeably. One reason for this is because the imaging process is, in essence, a way of cloning a hard drive or a partition. That said, I’ll do my best to use the “proper” term so as to clarify the method being tested.

On to the Testing!


With the first tool I tested, Clonezilla, the process of imaging and of recovering the resulting image are similar, though whether or not the process is perceived as straightforward depends on the user’s level of comfort using text-based user interfaces. (See Fig. 1.) Once I booted up Clonezilla, I simply accepted the default prompts in order to image my Windows drive:

Clonezilla modes

Fig. 1 — Clonezilla’s device-image and device-device mode selection screen

Clonezilla offered many choices, but following the default path produced an image I was able to transfer to various storage devices until I required it. When it came time to restore the image, I simply followed the default path once again until I reached the following mode selection screen:

Clonezilla mode selection

Fig. 2 — Another of Clonezilla’s mode selection screens

Rather than selecting the default (as I had done to create the image), I selected the restoredisk option to restore the image to the hard drive.

Once the process was completed, I had no problem booting right back into my now-restored Windows XP system. Clonezilla seems to create both an image of your drive and its master boot record (MBR), the latter being an essential part of the boot process. (To put it simply: without a master boot record, Windows will not boot. One of the other two other tools I tested, DriveImage XML, failed to restore the MBR, causing me quite a bit of consternation before I discovered a relatively simple fix that enabled my computer to resume booting Windows XP.)

In my first article I mentioned that Clonezilla imaged my system quickly; now I can report that it restored the image in a similarly fast fashion. One thing I noticed this time around was how well Clonezilla had compressed the image, reducing my system’s size considerably. In my most recent test, Clonezilla produced a 10 gigabyte image out of a 15.7 gigabyte system. As noted in my first article, however, Clonezilla can seem a bit disorienting at times. Once in a while the application might display some funky stuff. In my testings, strings of characters would often overlay menu items that needed to be read. If you can get past its funkiness, though, you’d be hard-pressed to find a better free solution, performance-wise.

Clonezilla funkiness

Fig. 3 — An example of Clonezilla’s “funkiness”

Clonezilla’s device-device mode (see Fig. 1) is this solution’s implementation of cloning, providing disk to disk or partition to partition cloning or restoring. Running this mode produced a perfectly cloned drive from which I was able to boot and restore from. (As mentioned earlier, restoring from a cloned drive is simply a matter of cloning the cloned drive. That is, in order to restore your cloned drive to your original drive, simply select Clonezilla’s device-device mode again, this time selecting the cloned drive as the source drive and the original drive as the destination drive.)

DriveImage XML

DriveImageXML is an entirely different beast than Clonezilla. As with Clonezilla, the software allows both image and clone creation, but the way it presents the process is considerably different. Unlike Clonezilla, DriveImage XML uses a graphical user interface (GUI) to guide the user through the operation and it delivers an image that can be worked with in a unique way. (More on that in a minute.) Though this solution’s GUI ain’t the prettiest I’ve ever seen, it’s certainly better looking than Clonezilla.

DriveImage XML's welcome menu

Fig. 4 — DriveImage XML’s welcome menu

The utility’s Drive to Drive option works much the same as Clonezilla’s device-device mode, producing a perfect clone of a hard drive or partition. You can then simply boot from the clone or repeat the cloning process to restore the clone back to the original drive. For example, if you initially cloned your C drive to your G drive:

DriveImage XML drive to drive -- first example

Fig. 5 — DriveImage XML’s Drive-To-Drive (cloning) operation

You would simply run the Drive to Drive option again when restoring the drive, this time cloning your G drive to your C drive. (Or, as mentioned earlier, simply swap your original drive with your clone.)

Where DriveImage XML truly differentiates itself from its competitors is with its Backup option (its implementation of imaging), by which it produces an image that is accompanied by an XML file. The XML file provides the ability to browse the image and extract files from it using either the DriveImage XML application (see Fig. 6) or a third-party XML reader. It was certainly a different way of working with a backup image.

DriveImage XML browsing

Fig. 6 — DriveImage XML’s image can be browsed due to its included XML file

Another distinguishing feature of DriveImage XML was its ability to clone or image a drive even while the drive was currently in use. The following video produced by the application’s developers provides an excellent demonstration of how this works:

DriveImage XML’s Drive-To-Drive operation took about the same amount of time as Clonezilla’s equivalent cloning operation, but the imaging process (backup) took longer than any of the tools I tested. This is likely due to the utility’s distinguishing feature, the XML file, which consumes some time in assembling. By default, the application also manufactures an image that is broken up into 650 megabyte-sized parts, so that your image can be spread out and burned to multiple CD-ROMs. The process of breaking up the image in this manner and storing its contents in the XML file certainly takes more time to produce than a standard, unbroken image without XML management would.

Speed aside, DriveImage XML performs very well, with one glaring exception: the application doesn’t restore a drive’s ability to boot. The application doesn’t seem to copy the master boot record, so in order to get your system booted you’re likely to have to do some extra work. DriveImage XML’s developers are aware of this issue (and may not even see it as an issue, since their solution is not advertising an ability to boot a device) and provide some hints that are supposed to re-enable booting, but in my tests the only way I found I was able to boot my restored drive or partition was by using another utility altogether, Gnome Partition Editor (Gparted). Using Gparted, I was able to flag my device as boot, making the drive active and restoring its ability to be boot from. Though I now feel comfortable recommending DriveImage XML as a viable imaging and cloning utility, buyer beware: the utility has some unique and potentially useful features, but don’t expect to be able to boot your system after restoring it without first having to use another utility to either fix your master boot record or make your boot device active.

Todo Backup Free

In terms of ease of use, the final utility I tested took the top prize in the category. Though cloning drives was a fairly straightforward process in all three of the solutions I tested — and the end result in each case was exactly the same, a perfectly cloned drive or partition — Todo Backup Free‘s graphical user interface was both easy on the eyes and easy to use:

Todo Backup Free cloning

Fig. 7 — Todo Backup Free’s Clone layout

As you can see in Fig. 7, Todo Backup Free has a user interface that is probably more familiar to Windows users than that utilized by Clonezilla. Ultimately a user’s preference for one type of interface over another is a subjective, but I found Todo Backup to be much more intuitive for resizing and moving partitions during the process of imaging or cloning. The utility also made imaging a disk or partition a relatively painless process:

Todo Backup Free imaging

Fig. 8 — Todo Backup Free’s Backup (imaging) layout

Using Todo Backup’s default settings, a 13 gigabyte Windows XP installation was compressed to just over 8 gigabytes, and it did so in a comparable amount of time to Clonezilla’s imaging process. Restoring from the image was an equally fast and painless process, and I was able to successfully boot from each drive I restored, using both the software’s cloning and its imaging operations. The only real drawback to this tool is that the free version lacks some of the features that can only be accessed in one of the software’s licensed versions, such as full scheduled backups, recovery to dissimilar hardware, and tech support. For simply imaging and restoring my Windows partition, however, Todo Backup Free does the job.


Ultimately, each of the three free solutions I tested offered a different experience but successfully produced the results I was aiming for: the ability to recover my drive or partition from an image or a clone. Since all three tools worked, I’m having difficulty deciding which one I’ll be using regularly; I’ve gotten used to using all three utilities and I enjoy the difference of experience each one presents.

Yet while the end result of cloning is virtually identical in each case, the imaging process of each application results in images which can be managed in quite different ways. For example, as neat as DriveImage XML’s image can be to browse using its XML file, how often will I really use this particular feature? Knowing my own personal habits, I doubt I’ll be browsing the image very often, if at all. Still, I can see how the feature would be useful to someone else.

Perhaps my habits will change, so I think I’ll continue using DriveImage XML for a while to see if I find it useful, while at the same time keeping Clonezilla and Todo Backup in the rotation. When I need a faster image I’ll likely be turning to Clonezilla or Todo Backup. Over time, perhaps one of the solutions will prove to be the most reliable, the most efficient, or simply the most pleasing to use.

The first time I wrote on this subject, several people chimed in with their opinions. I’m looking forward to hearing what you think about this report on my testing of imaging and cloning utilities, so feel free to comment away!