I don’t know if it’s just me, but before I rebuild a machine I have that awful feeling that there’s something I’ve forgotten to backup. It doesn’t matter how many times I check and re-check, desktop or server–the feeling remains. Ordinarily, of course, everything is fine and there was really nothing to worry about. Now and then, however, you overlook something, and it’s as soon as you’ve answered yes to the format prompt that enlightenment can be found! Even if it’s not anything important, it’s frustrating.

Good practice would be to use a new disk (or disk set if running with RAID) and not overwrite the original disks until a predetermined amount of time has passed—but this is not always possible. An alternate solution, which is extremely simple and also very effective, is to use dd. The dd utility very simply copies a standard input to a standard output. As with all core Linux/Unix tools it can be daisy chained with others to perform more complex tasks. One of the things that dd does best is to create flat images of either disks or partitions. All you need is a suitable place to store the disk image and you’re away. Most Linux LiveCD distributions (Backtrack is my favourite) will include dd, USB mass storage support, and also netcat (more on this in a minute). It’s certainly best to boot from a LiveCD on the host machine so that there is no process attempting to read or modify the very disk you are going to clone.

Let’s create a scenario: Server A has an 18-GB SCSI disk (running on an LSI controller); the machine runs Windows Server 2003 and we want to splat it (yes, splat, a wonderfully technical term!). Server B is our file dump running Ubuntu with lots and lots of disk space to spare for exercises like this; it has a fixed IP of 192.168.0.1. Both machines are linked via a Gigabit switch / network. Despite having taken backups of everything and anything useful on Server A, we still want to make sure nothing has been missed (belt-and-braces approach), so will dump an image of the hard disk in Server A to a flat file on Server B. Let’s get to it.

The first step is to boot up Server A with Backtrack (or your Live distribution of choice). This is pretty self explanatory, and if you have trouble with that, then it’s most likely best to give up now! Once the system has booted, you need to check that you have:

  1. Network connectivity
  2. Disk access
  3. dd
  4. netcat

1) Pretty simple: first check whether or not you have an address:

# ifconfig –a

eth0 Link encap:Ethernet HWaddr 00:0C:29:DF:EA:F7
inet addr:192.168.0.106 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fedf:eaf7/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49 errors:0 dropped:0 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6425 (6.2 Kb) TX bytes:8109 (7.9 Kb)
Interrupt:18 Base address:0x1400

Luckily you do; however, if that isn’t the case simply execute:

# dhcpcd

If you want to enable the ssh server then:

# sshd-generate
# /usr/sbin/sshd

2) Disk access: You need to check that the disk you want to clone has been recognised by the live environment. It won’t have been mounted, so you can check the output of dmesg for any mention of a SCSI device and then verify that it’s the disk you are looking for with fdisk.

# dmesg|grep scsi

[42949418.410000] sd 2:0:0:0: Attached scsi disk sda

root@nagios:~# fdisk /dev/sda

The number of cylinders for this disk is set to 2212.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 18.2 GB, 18200739840 bytes
255 heads, 63 sectors/track, 2212 cylinders

Device Boot Start End Blocks Id System
/dev/sda1 * 1 2211 17759826 7 HPFS/NTFS

This is the disk you are after: you can see the disk size is 18.2 GB and it contains one NTFS partition.

3) & 4) It’s easy to check for dd and netcat :

# dd –help
# nc –h

If either of these produces a ‘command not found’ message, then try another LiveCD distribution. It is worth noting that some seem to have netcat installed as ‘netcat’ rather than just ‘nc’ so give that a try before condemning your current CD to life as a desk top coaster.

Okay, let’s get going. In this example, you will create an entire disk image of /dev/sda in Server A and save it in a file called ‘image.dd’ on Server B. You’ll use dd to create the data stream, netcat to pass the data over the network, and then again dd to convert the received data stream in to a flat file:

On Server B (receiving):

# nc –l –p 1010 | dd of=/tmp/image.dd

This will now sit and wait for incoming data and write it to the image file.

On Server A, you need to start sending that data:

# dd if=/dev/sda | nc 192.168.0.1 1010

If all is well, this will start to stream the image across the network. Once the transfer has finished, dd will display information about the amount of data that has been written. Netcat won’t automatically exit, so upon seeing this information, you simply need to Ctrl[C] to quit. There we have it, a complete flat file image of the original disk to give you peace of mind and a good night’s sleep! It is also possible to save the image to a USB storage device—simply mount the drive and then create the image with dd (without netcat):

# dd if=/dev/sda of=/mnt/usb1/image.dd

If recovery from the original image is required (maybe the new installation failed and you want to roll back) then the reverse can be applied:

On Server A (receiving):

# nc –l –p 1010 | dd of=/dev/sda

On Server B (sending):

# dd if=/tmp/image.dd | nc 192.168.0.106

Next week I’ll take a look at a few tricks that will allow us to boot this flat file image as a virtual machine with the help of VMware—this really can be a lifesaver. Having the ability to mount old machine images on your desktop (or notebook) is extraordinarily convenient and can be much more practical than a bare metal recovery. You may even decide that several legacy systems, which have previously been archived in this way, should be reintroduced in a virtualised environment.