Imaging, also known as Ghosting in the Windows world, is the act of creating a sector-by-sector copy of a hard-drive and saving it to a file, or transferring it to another hard-drive. Such uses for imaging include:

• Backup to an image file
• Clone to another hard-drive (eg: building multiple identical workstations) either directly or via an image file
• Data recovery (it’s safer and easier to examine an image file than risk further damage to the hard-drive itself)

Linux has a neat little command that can do this for us called simply “dd”. It is completely filesystem independent, so you can backup any hard-drive regardless of whether it was Linux formatted, Mac formatted or Windows formatted. It copies the drive bit by bit, sector by sector, not file by file.

WARNING: The following article describes commands that can destroy the information on your hard-drive with next-to-no-chance of being able to rescue what’s left. Make sure that you have full backups of your data prior to using these commands. You use these commands at your own risk!

First up, your drive/partition being backed up or written to should be unmounted before you begin. If you were trying to backup the partition containing your system’s root filesystem, you should boot up your system on a LiveCD so you can access your root partition unmounted.

You then need to determine which drive or partition you want to backup. Easiest way to do this is to fire up a terminal session and type in:

$ sudo fdisk -l

…which will list all your drives, their partitions and sizes. Note down the device name of the drive or partition you wish to backup, eg: /dev/sda for the whole of your first drive or /dev/sda1 for just the first partition of that drive, and you’re ready to begin backup.

At its simplest, backing up a drive takes two basic parameters – input device and output device or file as follows:

$ sudo dd if=/dev/sda1 of=/dev/sdb1

…will copy the content of the first partition on drive sda to the first partition of drive sdb (destroying whatever was in /dev/sdb1 previously).

$ sudo dd if=/dev/sda1 of=~/mybackup.img

…will copy the content of the first partition on drive sda to a file called mybackup.img in your Home directory.

If you wish to backup an entire drive rather than just a partition, drop the number on the drive name, ie: /dev/sda1 becomes /dev/sda instead.

To restore the image to a drive, simply reverse the parameters:

$ sudo dd if=~/mybackup.img of=/dev/sda1

How simple is that? The only issue with this method of backup, though, is that if you were to backup a 10GB partition containing only 5GB of actual data, the resulting image file will still be 10GB as dd does not simply copy active data from the drive, it copies everything.

So with that in mind, let’s compress the image, so any empty space on the drive doesn’t take up unnecessary space in the image file. We can do this by piping the data from dd into gzip before writing it to a file:

$ sudo dd if=/dev/sda1 | gzip -9 > ~/mybackup.img.gz

…and to restore, we simply pipe the decompressed data into dd again for writing to the drive:

$ gunzip -c ~/mybackup.img.gz | sudo dd of=/dev/sda1

But wait! There’s more!

This just scratches the surface of what you can do with dd. For example, you can also use dd to destroy a drive’s content before you dispose of, or sell the drive by using the following:

$ sudo dd if=/dev/random of=/dev/sda1

…which will write random data to the partition sda1 using the virtual random device, completely obliterating it.

Or, if you want a more uniform destruction, try:

$ sudo dd if=/dev/zero of=/dev/sda1

…which will – no surprises here – write zeros across the entire partition.

Or perhaps you have a drive that isn’t playing nice, for example Microsoft Windows can get stroppy when working with, or removing partitions created by a foreign OS. The easiest way to fix this is to simply destroy the Master Boor Record (MBR). You can achieve this by specifying a blocksize parameter. The MBR is inside the first 512 bytes of the drive, so all we have to do is blank those 512 bytes out using:

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

The bs parameter specifies the block size in bytes (in this case 512) and the count parameter specifies how many blocks of 512 bytes we’re doing (only one in this case, the first 512 bytes of the drive where the MBR resides).

Any PC will now view this hard-drive as a brand new, never partitioned drive.

Rescuing a dying hard-drive

The dd command is particularly useful for recovering data on a drive that’s about to become a paperweight. As long as it can power up and identify itself to the system, you can attempt data recovery by taking an image of the drive and then try to recover the files from that image.

Since dying hard-drives are typically sown with errors, we need to tell dd to ignore them and keep pulling as much data off as possible. Taking our first imaging example, we add a couple of parameters to the command as follows:

$ sudo dd if=/dev/sda of=~/mybackup.img conv=noerror,sync

This will make a full backup of all partitions on drive /dev/sda to a file called mybackup.img in your Home directory, and the conv parameter tells dd to ignore any errors found during the read by skipping over them. The sync parameter tells dd to replace the errors with null values – blanks – so that the resulting image file is the same data length as the drive.

Once the backup is complete, you can then mount the image to view its content. As long as the MBR (the first 512 bytes of the hard-drive) were not damaged, you will be able to now recover most, if not all your files, without worrying about further failure to the drive or odd behaviour due to the physical errors on the drive itself.

To mount the image file, you do the following. First we need a mountpoint – a place to reference the mounted image volume:

$ mkdir /dev/shm/myrecoveryimage

This creates a directory called “myrecoverytimage” in your system’s RAM drive. Before you point out that you have less physical RAM than the capacity of your hard-drive, don’t worry – this is just a mount-point. The image will still be physically read from wherever you put it on another drive.

Now we mount the image. Let’s say we backed up a standard Linux ext3-formatted drive:

$ sudo mount -t ext3 -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

…or for a Windows NTFS formatted backup image:

$ sudo mount -t ntfs -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

We have told the system to mount an image file of filesystem type Ext3 (or NTFS). We have to specify the loopback device because an image file is not a block device like a hard-drive is. We then specify the filename of the image we are wanting to mount, and finally where we are mounting it to.

You can now simply switch over to the mountpoint directory and see the content of the image file as though it were any normally mounted hard-drive.

$ cd /dev/shm/myrecoveryimage
$ ls -l

There are a plethora of filesystems that the mount command can manage including FAT, NTFS network filesystems etc. Refer to the man page for the mount command for more details.

When you have finished with the image, you can unmount it with:

$ sudo umount /dev/shm/myrecoveryimage

…and that will make the /dev/shm/myrecoverimage directory revert back to an ordinary empty directory again (which, being in the RAM disk, will be lost when you reboot).

Happy dd’ing!