Backing up an entire hard drive under UNIX

Backing up an entire disk under any operating system is a necessary evil. Justin James walks you through the process needed to create an identical copy of an entire disk under UNIX.

This article walks you through the process needed to create an identical copy of an entire disk under UNIX. It is useful to create a system image for installation or backup purposes. You will need a second hard drive of the same or larger size as a destination for the backup. The disk created will be full bootable; in the event of a drive failure, this backup drive can be swapped in for the previous drive and the system will boot and be in the same state that it was in when the backup was made. While booting off a drive that believes that it is a powered-on system is not ideal, it can get you back into operation quickly. In addition, the backup disk can be used as a perfect copy of the file structure, in case of permissions problems or data corruption.

NOTE: You must be logged in as root to perform these operations.

Verify and prepare disks

The first thing to do is to verify that the second disk is being recognized by your system. To find this out, perform a directory list on /dev as shown below.

On this particular system (FreeBSD 6.1 with two IDE hard drives), the first drive is listed as ad0 and the second drive is listed as ad1. Check with your particular UNIX's documentation to find out its exact pattern for listing disks. For the purpose of this article, ad0 (the master drive on the first IDE channel) will be the source drive for the backup and ad1 (the slave drive on the first IDE channel) will be the destination drive for the backup.

Once you have verified that your disk has been recognized by the operating system, you need to properly partition and label the disk. To initialize the disk, we run the following commands:

1. dd if=/dev/zero of=/dev/ad1 bs=1k count=1

   This command writes 1024 zeroes to the disk to ensure that it is clean.

2. fdisk -BI ad1

   This command will create a disk slice that uses the entire disk and initialize it. If you wish to use a different boot loader for this disk other than the default, you will need to consult the documentation for fdisk, or manually install a different boot loader to this drive.

3. disklabel ad0s1 > /tmp/savedlabel

   Save the disk label of our source drive to a temporary file.

4. disklabel -R -B ad1s1 /tmp/savedlabel

   Write the original disk label to the new drive.

5. newfs /dev/ad1s1a
   newfs /dev/ad1s1b
   newfs /dev/ad1s1d
   newfs /dev/ad1s1e
   newfs /dev/ad1s1f

   Here, we create a new file system on each of the partitions that we created. These partition numbers are the FreeBSD defaults. You may want to perform a directory listing on /dev to ensure that you are creating a file system on each partition that you created on disk ad1.

6. mkdir -p /_bk
   mkdir -p /tmp_bk
   mkdir -p /usr_bk
   mkdir -p /var_bk

   This creates a place for us to mount the new file systems with the names for the backups. As always, your particular file system may be a bit different.

7. vi /etc/fstab

   This will bring up the fstab file in vi for us to edit. We need to edit this file so that the system is able to use the new partitions upon reboot. If you do not like vi, you may use the text editor of your choice. The original fstab file is shown below.
   

   We are going to replicate all of the information for disk ad0 so that the new partitions on disk ad1 are mounted under / with the same names as the original partitions, with _bk appended to the name, using the same names that we did in Step 6. Do not create an entry duplicating the swap partition (as noted by the FStype column). The fstab file should look like this when finished.
   

8. Now, we test the new file systems and mount them without needing to reboot, using the directory names and partitions in accordance the with fstab changes that we made:

   mount /dev/ad1s1a /_bk
   mount /dev/ad1s1e /tmp_bk
   mount /dev/ad1s1f /usr_bk
   mount /dev/ad1s1d /var_bk

9. The final step is to perform the backup itself:

   cd /_bk && dump –L -0 -f - / | restore -r -f -
   cd /tmp_bk && dump –L -0 -f - /tmp | restore -r -f -
   cd /usr_bk && dump –L -0 -f - /usr | restore -r -f -
   cd /var_bk && dump –L -0 -f - /var | restore -r -f –

   This runs the dump command which performs a full file system copy and immediately redirects its output to the restore command. The -L switch tells dump to use a file system snapshot if possible, since we are working on a live file system. You may omit the -L if you are not backing up a live file system. If we did not want to immediately image the backup disk, we can direct dump to output to a file, which can be used with the restore command to re-image a partition.

10. Edit the file /_bk/etc/fstab to remove all references to the second disk, so it looks like the original fstab file. This is so that if you ever boot off of this duplicate drive, the system will not be trying to mount file systems on a drive that does not exist, since this secondary disk will be moved to the first disk location. Alternatively, you could edit the fstab file on the backup disk (/_bk/etc/fstab) so that it has no references to the original disk, so you could remove the original disk and not move the backup disk, and it would boot normally. If you choose this route, make sure that you have a reference to ad1s1b as a swap partition. How you prefer to go about this depends wholly upon how you prefer to perform the switchover in the event of disk failure.

At this point, if you perform a directory listing of /_bk, /usr_bk, /tmp_bk, and /var_bk you will see that they look identical to what is contained in the original directories. To test your backup, shut the computer down, physically connect the backup disk with the same hardware settings as the original disk had, and restart the computer. Your computer should reboot in the state that it was in at the time of the backup.

Final thoughts

Keep in mind, however, that this is not necessarily an ideal situation; since you performed an exact duplicate of the disk, the system is going to "think" that it had an improper shutdown. The backup disk, while bootable and usable, is best used as a near line backup of the full file system, not as a way to be able to immediately recover a down system. While it can be used for this purpose, the state of the backup, that is, still being considered powered-up (in terms of things like lock files, PID files, and so on), may not be ideal for your needs. It is also possible to write a script to be run through a crontab at a regular interval to keep your backup up to date. Using dump as the cornerstone of a backup strategy is a time tested, proven, well supported and well documented technique.