The first choice to make is whether you will back up your system while it’s running (live) or back it up while it’s booted from alternate media. Backing it up live involves using filesystem-level backup commands to back up the files on your running system.

If you’re running Windows, this choice is already made for you. You need to use the alternate boot method because, as of this writing, there is no backup format that can be written in Windows and read in Linux that also supports ACLs. There are rays of hope, though. We can now easily mount and create NTFS filesystems in Linux, the mtftar command can read NTBACKUP tapes, and the community developing the pax utility says that pax is starting to support ACLs.

The biggest advantage to backing up your system live is that it does not require downtime for the backup. Depending on your operating system, though, there may be issues with open files or system configuration databases. If it’s important that you back up your system live, just make sure you test the procedure well to make sure that you’ve dealt with all the issues specific to your operating system and platform.

If you cannot take your system down for an occasional bare-metal backup, the other option is to back up your system while it is booted from an alternate boot disk, such as a LiveCD Linux distribution, during backup. (A LiveCD is a Linux distribution designed to give you a fully functional Linux operating system by simply booting from a CD.) The alt-boot method, as this is called, also offers a number of advantages, such as not having to worry about filesystem formats. It does this by backing up at the block (or image) level, which is not possible when backing up live. It’s only disadvantage is that it requires your system to be unavailable during the entire backup. This shouldn’t be a problem for home users and some small businesses, but others may find this limitation unacceptable.

If you’re using the alt-boot method, you can access your data as filesystems or raw disk devices. If you back up the data using the raw disk device (for example, /dev/hda or /dev/hda1), we say that you’re backing up at the image level. The other option is to back up the data as filesystems by mounting them and using a tool such as tar. (You cannot perform a filesystem backup and restore of NTFS partitions.)

Backing up at the image level gives you the advantage of not having to care about the operating system that’s using the drive. As long as you back up all the bytes that are on the hard drive and restore them back to the same partition, everything will work fine. This is how we can easily back up a Windows system using Linux.

The biggest disadvantage of image-level backups is that they back up every byte on the drive whether it’s being used or not. If you’ve got a 10 GB partition, you’re going to get a 10 GB backup, even if there’s only 1 GB of files on that partition. (Compression should help get rid of those empty blocks but will probably lengthen the backup time.) Another disadvantage of image-level backups is that they are all-or-nothing. You cannot restore individual files from an image-level backup.

If you’re using the alt-boot method and have decided to back up at the image level, you have another decision to make. Will you back up the operating system drive as one large image (/dev/hda) or as separate partitions (/dev/hda1, /dev/hda2, and so on)? In order to back up at the partition level, you need to have multiple partitions on your hard drive. Read the sidebar “Partition Your OS Drive” later in this chapter.

Backing up the entire OS drive as one large partition has one major advantage: recovery is incredibly simple. You don’t have to worry about repartitioning the hard drive for recovery, and you don’t have to worry about the boot block (the master boot record, or MBR). Just back up the entire drive as one large image, and you’re done.

The disadvantage of this method is the size of today’s hard drives. If you back up the entire hard drive as one image, you may need to create a single image that’s hundreds of gigabytes—or even a terabyte. Wow! Besides the space required to store such an image, backing up hundreds of gigabytes with one backup command could take an extremely long time—and your system is down the entire time.

The other method would be to create multiple partitions and back up each partition separately. This allows you to use the bare-metal procedure only for the partitions that contain the operating system, and use filesystem backup techniques (such as Amanda, BackupPC, Bacula, rsnapshot, and rdiff-backup) for the rest of the system. It also allows you to run backups of all partitions simultaneously, speeding up the whole process.

There are disadvantages to the partition method when compared to the full disk method, all of which are about complexity. You’ll need to understand more about how your drive is partitioned, and you’ll need to worry about backing up and recovering the partition table and MBR. When you partition your hard drive for recovery, you have to create partitions of the right size to recover to. If you make them too small, the recovery won’t work; if you make them too large, you’ll be wasting disk.

The three decisions just described translate into four backup methods. Using the shorthand terms described earlier, those methods are alt-boot full image, alt-boot partition image, alt-boot filesystem, and live.

If you’re running Linux, FreeBSD, Solaris x86, or any other Unix-like operating system, you can easily back up your important metadata live.

To save the disk partition information, run these commands:

# fdisk -l >/backups/fdisk.txt
#cp /etc/fstab /backups/fstab.txt

To back up the MBR and partition table, run the following command. It creates a backup to a file called /backups/mbr.

# dd if=/dev/hda of=/backups/mbr bs=512 count=1

This can be used later to restore the MBR and the partition table.

Unfortunately, there are no Windows equivalents to the commands just shown. You have two choices. If you use the alt-boot full image method, you can skip this step. If you want to use the alt-boot partition image method, save this information before backing up your partitions.

After booting into Knoppix, you are automatically logged in as user knoppix. This example assumes you are booting into a DHCP environment and have an NFS server called nfsserver with a share called /data08/curtis. Obviously, you need to substitute the appropriate values for your environment. In addition, if you’re using a USB drive for this procedure, you need to mount it instead of the NFS drive. Run these commands to proceed:

$ su -
#mkdir /backups

Now run one of the following two commands depending on whether you are running NFS or SAMBA:

# mount nfsserver:/data08/curtis /backups
# mount -t smbfs -o username=administrator,password=PASSWORD//servername/share /backups

Finally, save the partition information:

# fdisk -l >/backups/fdisk.txt
#dd if=/dev/hda of=/backups/mbr bs=512 count=1

If you’re using the live method, you’ll want to use tar or cpio. tar is easily the most popular choice here because it’s more portable than cpio. If you’re going to use the alt-boot filesystem method, you need to understand the filesystem types, mount the filesystems, then use tar or cpio to back them up. If you’re going to use the alt-boot full image or alt-boot partition image methods, you need to use dd.

If you’re going to back up a Windows system using the alt-boot full image or alt-boot partition image methods, you’ll need to use dd. We’ll cover the syntax that you’ll need to know. If you’re going to use the alt-boot filesystem method, you’ll need to use the ntfsclone utility that’s available on the Knoppix CD. ntfsclone efficiently clones (or copies) an NTFS filesystem to a file, copying only the used data. (Unused blocks are represented by zeros in a sparse file, so they don’t take up space.)

You can’t back up a Windows system using the live method. While you can easily download a Windows version of tar, and tar is available on the Knoppix CD, tar does not preserve Windows ACLs.

If you’re using either the live or alt-boot filesystem methods, you now need to create filesystems on the drive using the mkfs command. You need the backed up fstab file to know which filesystem types each partition is supposed to have.

If you’re using the alt-boot full image or alt-boot partition image methods, you don’t need to worry about formatting the drive; it happens automatically when you restore from the image.

If you’re using the alt-boot full image or alt-boot partition image methods, you don’t need to worry about formatting the drive; it happens automatically when you restore from the image. If you’re using the alt-boot filesystem method, the drive is automatically formatted when you restore using ntfsclone.

This method does not require this step because the metadata is backed up and restored when you back up the entire hard disk as one image.

First, place the Knoppix CD into the drive and reboot, booting you into Knoppix. By default, Knoppix starts KDE (a windowing environment) as user knoppix. After switching to the root user (which has no password initially), create a mount point, and mount an NFS directory as /backups:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

You can back up the entire disk using dd to a file in the NFS directory. This command specifies to back up the root hard drive (/dev/hda) to a file called /backups/hda.dd.

# dd if=/dev/hda of=/backups/hda.dd

Alternatively, if you want to save space, you could run this command. Depending on where your bottleneck is, this may speed up or slow down the backup.

# dd if=/dev/hda |gzip –c > /backups/hda.dd.gz

The first step in recovering this system is to place the Knoppix CD into the CD drive and boot the system. As before, open a terminal window, and switch to the root user, and then mount your NFS directory:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

This step is accomplished when you perform the dd of the entire disk.

This step is accomplished when you perform the dd of the entire disk.

To restore the entire disk, run this command:

# dd if=/backups/hda.dd of=/dev/hda

If you used the compress command during backup, you should use this command to restore instead. Depending on where your bottleneck is, this may speed up or slow down the restore.

# gzip –dc /backups/hda.dd.gz|dd of=/dev/had

Back up the MBR by running the following command:

# dd if=/dev/hda of=/backups/mbr bs=512 count =1

Place the Knoppix CD into the drive and reboot into Knoppix. By default, Knoppix starts KDE (a windowing environment) as user knoppix. After switching to the root user (which has no password initially), create a mount point and mount an NFS directory as /backups:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

You then back up the operating system to the NFS directory using dd. You can find which partitions you need and back up just those partitions using these commands:

# fdisk -l

Disk /dev/hda: 41.1 GB, 41174138880 bytes
255 heads, 63 sectors/track, 5005 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14        4874    39045982+  83  Linux
/dev/hda3            4875        5005     1052257+  82  Linux swap / Solaris

# dd if=/dev/hda1 of=/backups/hda1.dd
#dd if=/dev/hda2 of=/backups/hda2.dd

Alternatively, you can also use compression. Depending on where your bottlenecks are, this may speed things up or slow them down.

# dd if=/dev/hda1| gzip –c > of=/backups/hda1.dd.gz
#dd if=/dev/hda2| gzip –c > of=/backups/hda2.dd.gz

You can place an & (ampersand) at the end to allow the backups to occur simultaneously by placing them in the background. However, this requires you to monitor those processes to ensure that they complete before you reboot.

The first step in recovering this system is to place the Knoppix CD into the CD drive and boot up the system. A check of the partition table at this point shows the following:

# fdisk -l

Disk /dev/hda: 41.1 GB, 41174138880 bytes
16 heads, 63 sectors/track, 79780 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Disk /dev/hda doesn't contain a valid partition table

As before, open a terminal window and switch to the root user, then mount your NFS directory:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

For restoring by partition, you need to restore the MBR and partition table and then restore each partition. You can restore the MBR and partition table by running the following command:

# dd if=/backups/mbr of=/dev/hda bs=512 count =1

In order to get Knoppix to recognize without a reboot that we had recovered the MBR, we found it was necessary to actually run fdisk /dev/hda and then choose w to write the partition to disk. A reboot works as well but takes longer.

You are now ready to actually restore the operating system. Use dd in the reverse order that you used to back up the operating system:

# dd if=/backups/hda1.dd of=/dev/hda1
#dd if=/backups/hda2.dd of=/dev/hda2

If you used the compression option in the backup, you should use these commands:

# gzip –dc /backups/hda1.dd.gz |dd of=/dev/hda1
#gzip –dc /backups/hda2.dd.gz |dd of=/dev/hda2

Again, we knew that there was nothing of value in /dev/hda3.

You can place an & at the end to allow the restores to occur simultaneously by placing them in the background. However, this requires you to monitor those processes to ensure that they complete before you reboot.

All you have to do now is remove the Knoppix CD and reboot.

Back up the MBR by running the following command:

# dd if=/dev/hda of=/backups/mbr bs=512 count=1

Create a mount point, and mount a NFS directory as /backups:

# mkdir /backups
#mount nfsserver:/data08/curtis /backups

You can use whatever method you like to back up the operating system at this point. For this example, we chose tar. Our example has one partition mounted as /boot, and the rest of the OS on /.

# cd /boot
# tar cf /backups/boot.tar .
# cd /
#tar cf /backups/system.tar --exclude /mnt --exclude /proc --exclude /boot --exclude /backups .

Alternatively, you could use compression. This may speed up or slow down the backup, depending on where the bottleneck is.

# cd /boot
# tar cfz /backups/boot.tar.gz .
# cd /
#tar cfz /backups/system.tar.gz --exclude /mnt --exclude /proc --exclude /boot --exclude /backups .

The first step in recovering this system is to place the Knoppix CD into the CD drive and boot up the system. A check of the partition table at this point shows the following:

# fdisk -l

Disk /dev/hda: 41.1 GB, 41174138880 bytes
16 heads, 63 sectors/track, 79780 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Disk /dev/hda doesn't contain a valid partition table

As before, open a terminal window and switch to the root user, then mount your NFS directory:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

For restoring by partition, you need to restore the MBR and partition table and then restore each partition. Restore the MBR and partition table by running the following command:

# dd if=/backups/mbr of=/dev/hda bs=512 count =1

In order to get Knoppix to recognize without a reboot that we had recovered the MBR, we found it was necessary to actually run fdisk /dev/hda and then choose w to write the partition to disk. A reboot works as well but takes longer.

You also need to prepare the partitions for a filesystem restore. If the fstab backup shows they were ext2 filesystems, run the following commands. (Obviously, this part varies based on the types of filesystems you’re using.)

# mkfs –t ext2 /dev/hda1 -L /boot
#mkfs –t ext2 /dev/hda2 -L /

You are now ready to restore the operating system. Mount the partitions:

# mount /dev/hda1
#mount /dev/hda2

cd to the location of the new root filesystem and run the restore commands.

# cd /mnt/hda1
# tar xpkf /backups/boot.tar
# cd /mnt/hda2
#tar xpkf /backups/system.tar

Or, if you chose compression, run these commands:

# cd /mnt/hda1
# tar xpkfz /backups/boot.tar.gz
# cd /mnt/hda2
#tar xpkfz /backups/system.tar.gz

All you need to do now is eject the Knoppix CD and reboot.

Back up the MBR by running the following command:

# dd if=/dev/hda of=/backups/mbr bs=512 count =1

This procedure also requires you to know which partitions are which format, especially the Windows partitions. You should record this data by backing up the output of fdisk -l, backing up the fstab file, and making a text file that contains any additional necessary information.

In our example, /dev/hda1 is /boot, /dev/hda2 is /, and /dev/hda3 is the Windows partition.

Insert the Knoppix CD, boot into Knoppix, and open up a terminal window. Knoppix, by default, starts up KDE (a windowing environment) as user knoppix. You then need to switch to the root user (which has no password initially).

knoppix@0[knoppix]$ su -

The first thing you have to do for this procedure to work is to mount an NFS directory as /backups:

# mkdir /backups
#mount nfsserver:/data08/curtis /backups

You then need to mount the various partitions as filesystems.

# mount /dev/hda1
#mount /dev/hda2

You can use whatever method you like to back up the operating system at this point. For this example, we chose tar for the Linux partitions and ntfsclone for the Windows partition. While you could use tar on the Windows partition as well, we felt that ntfsclone was more likely to preserve any Windows ACLs.

Our example has one partition mounted as /boot, and the rest of the OS on /:

# cd /mnt/hda1
# tar cf /backups/boot.tar .
# cd /mnt/hda2
#tar cf /backups/system.tar --exclude /mnt --exclude /boot --exclude /backups .

Alternatively, you could also use compression. This may speed up or slow down the backup, depending on where the bottleneck is.

# cd /mnt/hda1
# tar cfz /backups/boot.tar.gz .
# cd /mnt/hda2
# tar cfz /backups/system.tar.gz --exclude /mnt --exclude /proc --exclude/boot --exclude /backups .

Now you need to back up the Windows partition. ntfsclone is not a filesystem utility per se because it does not back up on the file level. It’s really an image backup utility that understands NTFS filesystems.

# ntfsclone --save-image --output /backups/ntfs-clone.img /dev/hda3

The first step in recovering this system is to place the Knoppix CD into the CD drive and boot the system. A check of the partition table at this point shows the following:

# fdisk -l

Disk /dev/hda: 41.1 GB, 41174138880 bytes
16 heads, 63 sectors/track, 79780 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Disk /dev/hda doesn't contain a valid partition table

As before, open a terminal window and switch to the root user, then mount your NFS directory:

knoppix@0[knoppix]$ su -
# mkdir /backups
#mount nfsserver:/data08/curtis /backups

For restoring by partition, you need to restore the MBR and partition table and then restore each partition. You can restore the MBR and partition table by running the following command:

# dd if=/backups/mbr of=/dev/hda bs=512 count =1

In order to get Knoppix to recognize without a reboot that we had recovered the MBR, we found it was necessary to actually run fdisk /dev/hda and then choose w to write the partition to disk. A reboot works as well but takes longer.

You also need to prepare the partitions for a filesystem restore. Since our fstab backup showed that /dev/hda1 and /dev/hda2 were ext2 filesystems, run the following commands:

# mkfs –t ext2 /dev/hda1 -L /boot
#mkfs –t ext2 /dev/hda2 -L /

You do not need to prepare the NTFS partition; it’s restored with the ntfsclone command.

You are now ready to actually restore the operating system. We use tar to restore the Linux partitions and ntfsclone to restore the Windows partition. You need to mount the partitions:

# mount /dev/hda1
#mount /dev/hda2

Now cd to the location of the new root filesystem and run the restore commands:

# cd /mnt/hda1
# tar xpkf /backups/boot.tar
# cd /mnt/hda2
#tar xpkf /backups/system.tar

Or, if you chose compression, run these commands:

# cd /mnt/hda1
# tar xpkfz /backups/boot.tar.gz
# cd /mnt/hda2
#tar xpkfz /backups/system.tar.gz

Now you need to restore the Windows partition that’s on /dev/hda3. Use the ntfsclone utility to do that:

# ntfsclone --restore-image /backups/ntfs-clone.img  --overwrite /dev/hda3