Views

Linux & Windows Bare Metal Recovery

This Wiki is brought to you by Backup Central, where you can find the Mr. Backup Blog, Forums, and a mailing list for each forum!

Backup FAQs Service Providers Backup Software Backup Hardware Backup Book Wiki Free Stuff Miscellaneous


O'Reilly & Associates graciously agreed to allow us to publish this chapter from Backup & Recovery. It explains a home-grown procedure for achieving bare metal recovery in Linux.

Contents

Linux/Windows Bare Metal Recovery Chapter

This chapter explains how to perform a bare-metal recovery of Linux or Windows running on a standard Intel system. Parts of it should be able to be used to recover any other operating system that runs on standard Intel systems. It has been tested with CentOS 4.0.2 (also known as RedHat Enterprise 4), Windows 2000, and Windows XP. (This procedure does not work with Macintosh Intel systems because they are customized for Mac OS. See Chapter 14 for the Mac OS procedure.) The procedure requires only open-source tools.

This procedure works for a Windows-only system, but it does use a Linux distribution that can run straight from a CD. Windows users will have to run a few Linux commands, but we do our best to keep them simple. If we found an open-source bare-metal recovery tool that runs on Windows, we would have written a separate chapter for it. Unfortunately, at this writing, that doesn’t exist.

If you’re a Windows user who has never touched Linux, we urge you to at least try the procedures in this chapter before giving up on the idea. If you still find them too difficult, we also cover G4L, which is an open-source product that is similar to the commercial product Ghost. It uses Linux but requires much less interaction with operating system. Finally, we also mention a few commercial products at the end of the chapter.

Due to the availability of inexpensive disk and the ease of recovery disk brings to the table, this is an entirely disk-based procedure. You can use a Unix NFS share or a Windows share as a target. Any disk-like target that can be mounted before a backup or restore works with this procedure. If you’re interested in other disk targets, it would be worthwhile to read through the complete backup and recovery HOWTO on the Linux Documentation Project at http://www.tldp.org/HOWTO. This HOWTO has helpful hints on how to reduce the amount of information being backed up for a minimal OS restore.

How It Works

Most system administrators are familiar with the typical bare-metal recovery answer: install a minimal operating system and recover on top of it. However, this answer presents several problems. It takes too long, you could run into open-file conflicts, and it is difficult to document and recover operating system customizations. Like the other bare-metal recovery procedures in this book, this procedure does not require a reinstallation of the operating system in order to recover it. It breaks down into six major steps.

Back up the important metadata

  1. Back up the operating system with a native utility.
  2. Boot from alternate media.
  3. Prepare the new root drive.
  4. Restore the boot block to the new root disk.
  5. Restore the operating system information.

We’ll start with some background and then describe the general aspects of each of these six steps. Ultimately, we will provide a detailed procedure for each method we describe. Before you can choose a backup and recovery method, though, you have some decisions to make, as outlined in the next section.

Booting from Alternative Media

In order to easily recover your operating system, you need a limited root shell (also known as a mini-root) where you can run fdisk, mkfs, gzip, and pax/tar/cpio, dd, ntsfclone, and so on. You also need support for whatever backup media you have chosen. This functionality is provided via rescue floppies or a bootable Linux distribution on CD, also known as a LiveCD. Rescue floppies, like TomsRtBt, contain a minimal version of Linux and usually contain the recovery utilities listed previously. They also have several drivers for popular backup media, such as parallel-port Zip drives, SCSI tape drives, NFS, and SMB/CIFS. LiveCDs are more complete versions of Linux and come in a variety of flavors. They typically have support for more drivers and utilities than the rescue floppies. This expanded support and flexibility combined with the now ubiquitous nature of CD-Rs is what caused us to select a LiveCD for our examples.

A list of Intel rescue floppies may be found at http://metalab.unc.edu/pub/Linux/system/recovery/index.html. A list of LiveCDs may be found at http://www.frozentech.com/content/livecd.php. The Linux LiveCD that we chose to use is Knoppix (http:// www.knoppix.org).

If Then GOTO

This chapter spends the next several pages explaining a lot of the theory and manual steps behind a bare-metal recovery of an Intel system. Just like a lot of manuals, the good stuff is at the end. If you just want to jump right to the method that applies to you, this section should give you just enough detail to know which section to jump to.

If you’re running Windows and have never typed anything at a Linux prompt, you should probably jump right to Automate Bare-Metal Recovery with G4L. It describes a menu-driven method of bare-metal recovery. (If you want a menu-driven method, this is the only one we discuss.)

If any of the following apply to you, you must use either G4L or the alt-boot full image method.

  • If you’re running the Linux Volume Manager (LVM) or other software RAID system
  • If you’re using an IA64 system
  • If your partition tables contain references to an extended partition table

If any of the previous conditions apply to you, the following conditions do not apply to you.

For a manual method, see “Alt-boot Full Image Method”; for an automated method, check out Automate Linux & Windows Bare-Metal Recovery with G4L

If you’re running Linux and want to try to create live bare-metal backups, you should jump right to “Live Method” later in this chapter.

If you’re using a dual-boot Linux/Windows system and you don’t mind a little down time to get a bare-metal backup, you should probably check out the alt-boot filesystem or alt-boot partition image method. These methods can also be automated using the tool discussed in “Automate Bare-Metal Recovery with G4L” later in this chapter.

Choosing Backup Methods

Our goal was to perform a bare-metal backup of an Intel system without using commercial tools. To use the procedures we developed, you have to make three decisions:

  • Will you back up while the system is running (live) or while it is booted from an alternate boot disk?
  • If using an alternate boot disk, will you back up at the block/image level or the filesystem level?
  • If backing up at the image level, will you back up the entire drive as one image or back it up as separate partitions?

Live or alternate boot?

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 supports Windows access control lists (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 it is starting to support ACLs.

There's a new, untested idea I discussed in a blog entry. I'm not sure if it will work, but it talks about using vmware's converter to create the image backup. The idea needs testing and refinement, but I'd thought I'd throw it out there.

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 and you can’t make the live backup method work for you, read “Commercial Solutions” at the end of this chapter.

If you have the ability to take your system down for an occasional bare-metal backup, the other choice 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. We use the terms live and alt-boot as short hand terms for these two backup options.

Image level or filesystem level?

If you’re using the alt-boot method, you have the ability to 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 like tar. (You cannot perform a filesystem backup and restore of NTFS partitions.) We’ll use the terms image or filesystem as short hand terms for these two backup options.

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.

Complete disk or separate partitions?

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 called “Partition Your OS Drive.”

We’ll use the terms full or partition as short hand terms for these two backup options.

Partition Your OS Drive

Many people have one large partition for their operating system, applications, and data. Partitioning your hard drive in this manner limits your bare-metal recovery options. A better idea would be to partition your hard drive with one partition just big enough to hold your operating system and its applications and a second partition to hold all your data. Having partitions like this also allows you to back up the data drive using standard filesystem backup techniques (such as Amanda, BackupPC, Bacula, rsnapshot, and rdiff-backup), and only use bare-metal recovery procedures for the operating system partition.

If this idea interests you, you can use a tool like Partition Magic in Windows or QTParted for Linux to repartition your drive with multiple partitions. (If you haven’t seen QTParted, it’s great. It works almost exactly like Partition Magic, but it’s Linux-based and free!)

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 upeach 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 your backup.

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 master boot record (MBR). When you partition your hard drive for recovery, you’ll 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.

Four backup options

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

Alt-boot full image

This method consists of booting to a LiveCD and creating an image of the entire OS disk. This is the simplest of all the tasks and the one that works for the most people, but it requires enough downtime to back up the entire OS drive—and enough space to hold that backup.

Alt-boot partition image

This is similar to the alt-boot full image method, but we make an image of just the partitions we need to back up. This method can save a lot of time and space if your hard drive is properly partitioned, but it requires down time and a more extensive knowledge of your hard drive contents.

Alt-boot filesystem

This method consists of booting to a LiveCD such as Knoppix and then using filesystem-aware utilities to back up the hard drives. tar and cpio are available in Knoppix. This can save you a lot of space if your filesystems aren’t very full, but it’s the most complicated of all the tasks, and still requires downtime.

If you’re going to use the alt-boot-filesystem or live backup method, you need to use utilities that are available in the LiveCD that you’re using. We’ve chosen Knoppix because of its popularity and great device support. Knoppix also gives you a wide variety of utilities. tar, cpio, dd, and ntfsclone are all available. (ntfsclone, also available in Knoppix, is really an image utility, but it is NTFS filesystem-aware, so it gives you the ability to back up only the part of the image that contains files.)

Live

If you’re running Linux, are not running LVM, software RAID, or using an IA64, you can back up the operating system while it is being used, then use alternate boot media just for the restore. You can use whichever filesystem level backup utility you wish. Remember that this method does not easily support dual-boot systems because they don’t have a common filesystem. It also won’t support Windows-only users because the commands that they would use to back up their system won’t be available from the media we use for restore. However, if you can’t take your system down for an occasional OS-level backup, this may be your preferred method. (With a dual-boot system, you can back up your Windows partitions while you’re booted into Linux, of course.)

All of the examples in this chapter use the directory /backups as the backup target. This can be an NFS or CIFS mount or a local removable hard drive. The drive must be writable as root, so you add the option -o rw,root to any NFS shares.

The Steps in Theory

Later in this chapter you’ll find specific procedures for each of the four methods we’ve described. This next section takes a closer look at the six general steps involved in our bare-metal backup and recovery process.

Step 1: Back Up Important Metadata

The first data that you need to save is the metadata. Metadata is the data about that data, that is, the information about how the system is physically configured. In this case, it’s how the operating system disk is partitioned. This information is not typically included in a normal backup. Making a copy of the master boot record (MBR) and partition table is a way to maintain this information in a format that can be used to recreate the root disk partition. The MBR and partition table are contained in the first 512 bytes of your hard drive. An MBR has three parts. The boot block is stored in the first 446 bytes, the paritition table is stored in the next 64 bytes, and the boot code signature takes up the remaining 2 bytes.

Linux, FreeBSD, and Solaris x86

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

If you are using Linux LVM, software RAID, extended partitions, or IA64 systems, you need to use the alt-boot full image method, which allows you to skip this step.

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.

Windows

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’ll need to mount it instead of the NFS drive. Run these commands to proceed:

$ su -
# mkdir /backups

While Knoppix is booted from read-only media, it’s an entire OS running from RAM, so you can indeed make directories or even install software into this RAM environment. Of course, everything goes away when you reboot. 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

This procedure assumes you are not using Windows dynamic disks for your operating system drive.

Step 2: Back Up the OS with a Native Utility

If you are going to restore the operating system without reinstalling it, you need to use a utility that is always available.

Linux, FreeBSD, Solaris X86

If you’re using the live method, you’ll want to use tar or cpio. tar is easily the most popular choice here since it’s more portable than cpio. If you’re going to use the alt-boot filesystem method, you’ll 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, then you’ll need to use dd.

Windows'

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, then 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.

Step 3: Boot the System from Alternate Media

In order to easily recover your operating system, you need a limited root shell, which you get when you boot into Knoppix. Once you boot into Knoppix, you can perform the rest of this procedure from a fully functional root shell.

Step 4: Restore the Boot Block Information

The boot block is a special part of the disk that is used to load the operating system by its “bootstraps,” hence the name. It contains just enough executable code to locate and load the kernel. On the Intel platform, this boot block is referred to as the Master Boot Record (MBR), and you can restore it with dd, using the the backup we created in the previous step. If you are using the alt-boot full image method, you can skip this step because the MBR is included in your image.

If you previously backed up the MBR and partition table using dd, as explained earlier, you can now use dd to restore the MBR and partition table by running the following command. Since the file /backups/mbr contains the MBR, partition table, and MBR signature, restoring this file to the hard drive partitions it just like the one you backed up and makes it bootable. Once this is done, you’re ready to restore the operating system.

# 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 that 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.

Restoring to Larger Hard Drives

This procedure can be used to restore a smaller hard drive to a larger hard drive; you simply end up with a large unused section at the end of the drive. You can then extend or reorganize your partitions to utilize the extra space inside the Knoppix environment. QTParted is available in Knoppix, and it works a lot like the well-known Partition Magic, automatically expanding and contracting partitions and filesystems as needed. As of this writing, QTParted does not support NTFS, so you’ll need to do expand any NTFS partitions manually. (You still need to do it inside Knoppix, as you cannot expand a drive in Windows if it contains the swap file.) It’s relatively simple, though.

This procedure will only work if the partition you need to expand is the last (or only) partition on the hard drive. If there are any partitions after it, you will need to use a commercial solution like Partition Magic. (That is until QTParted fully supports NTFS.)

  1. Use fdisk on the Knoppix CD to access the partition table on the new hard drive. Display the current partition table using the p key. Take note of the starting and ending cylinders of the partition you plan to extend, whether or not it is bootable, and the partition type. Also take note of the total number of cylinders in this hard drive, and whether or not there are any partitions after the one you want to expand. If the partition you want to expand is not the last partition on the drive, you cannot use this procedure.
  2. Delete the partition you plan to expand using the d key.
  3. Use the n key to create a new partition starting with the same starting cylinder as the original cylinder, and ending with the last cylinder on the drive that you discovered in step one.
  4. If the partition in question was bootable, you’ll need to make it bootable again. You do this by pressing the a key and entering the number of the partition in question.
  5. You also need to set the partition type using the t key followed by the L key to list the partition types, and locate the hex code for the partition type you saw in step 1. Then specify the partition type using its hex code.
  6. If you’re sure you did all those steps correctly, write the partition table using the w key and exit fdisk. (If you’re not sure, you can quit fdisk at this point without doing any damage.)
  7. Run the ntfsresize command against the partition (e.g. ntfsresize /dev/hda1). If you confirm you want it to do so, it will automatically grow the NTFS partition to the end of the partition. You’re done!


Partition and Format the New Root Drive

The steps in the previous section restore both the MBR and the partition table, so there’s no need to repartition the drive. All the partitions will already be created for you. If you’re using the live or alt-boot filesystem methods, you have the additional flexibility of restoring from a smaller drive to a larger drive. You also have the opportunity of rearranging partitions as you see fit.

Linux, FreeBSD, Solaris X86

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.

Windows

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.

Step 6: Restore the OS to the New Root Drive

First, you must have access to the backed-up data. Our examples use an NFS directory. You may have to do one of the following:

  • Mount a Zip or Jaz drive as a filesystem.
  • Install a second hard drive of equal or greater size.
  • Load network and NFS drivers, configure your network interface, and mount an NFS filesystem.
  • Load network and SMB/CIFS drivers, configure your network interface, and mount an SMB/CIFS filesystem.

Our example backups were sent to an NFS filesystem. The drivers and tools that we needed to do this were all available on Knoppix.

Assumptions

The following sections provide procedures for each of the four methods we’ve discussed: alt-boot full image, alt-boot partition image, alt-boot filesystem, and live. The procedures are based on a few assumptions, which are explained here.

  • We assume DHCP is available
  • We assume for our examples that your environment has a DHCP server supplying IP addresses so that you do not need to choose an IP address and configure the interface each time you boot into Knoppix. If DHCP is not available, you need to manually configure your IP address. To do this, run the following commands:
$ su -
# ifconfig eth0 ipaddress up
# route add default gw ipaddress-of-gateway

You then need to use IP addresses to communicate with other machines, or enter a valid IP address of a DNS server into the /etc/resolv.conf file (in the form of nameserver ipaddress-of-dns-server.)

  • We assume you’re using NFS
  • We assume for our examples that you have an NFS server in your environment with sufficient space to store the data on your server. If you’d like to back up your data to a Windows share instead, you can use this command:
# mount -t smbfs -o username=administrator,password=PASSWORD //servername/share /backups

Alt-boot Full Image Method

This example is the simplest of all the procedures, making it the most likely procedure for Windows users who are not familiar with Linux. This method requires the the system to be offline (booted into Knoppix). This process works regardless of what operating system you’re using. It does require the system to be down and requires enough space for a copy of the entire root drive.

Create the Bare-Metal Backup

Use the following steps to create a bare-metal backup of your system.

Back up the important metadata

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.

Boot the system from alternate media

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

See Assumptions if either DHCP or NFS isn’t available.

Back up the operating system with a native utility

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 the backup or make it take longer.

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

Perform a Bare-Metal Recovery

Use the following steps to recover your system from bare-metal.

Trash Your Hard Drive!

If you’re trying to test the recovery of your operating system hard drive, you might want to trash it before you start to make sure the procedure works. (We assume you’re working on a test system.) The first dd commands blows away both the boot block and the disk’s partition information. The other commands mess up the first 50 megabytes of each partition. Although the root filesystem is still there, you couldn’t find it if you wanted to! Boot into Knoppix and run the following commands:

# dd if=/dev/zero of=/dev/hda bs=512 count=1
# dd if=/dev/zero of=/dev/hda1 bs=1024k count=50
# dd if=/dev/zero of=/dev/hda2 bs=1024k count=50
# dd if=/dev/zero of=/dev/hda3 bs=1024k count=50
# dd if=/dev/zero of=/dev/hda4 bs=1024k count=50
# reboot
Boot Failure
Insert Boot diskette in A:
Press any key when ready.
Boot the system from alternate media

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, then mount your NFS directory: knoppix@0[knoppix]$ su -

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

See Assumptions if either DHCP or NFS isn’t available.

Restore the boot block information

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

Prepare the new root drive

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

Restore the operating system

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 the restore or make it take longer.

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

All you have to do now is remove the Knoppix CD and reboot the system. Your system should be fully operational. Wasn’t that easy?

Alt-boot Partition Image Method

This example uses dd to back up and recover a complete system at the partition level. It requires the system to be offline (booted into Knoppix), and it works regardless of your operating system. It’s slightly more complex than the alt-boot full image method, and still requires the system to be down during a backup, but it can be faster if your disk is partitioned correctly. You can save a lot of space and time if you partition your hard disk so that one partition contains the operating system and applications, and then apply this procedure only to that partition. (You would back up the other partitions with regular filesystem backup tools.)

Create the Bare-Metal Backup

Use the following steps to create a bare-metal backup of your system.

Back up the important metadata

Back up the master boot record (MBR) by running the following command.

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

Boot the system from alternate media

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 mounte an NFS directory as /backups:

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

See Assumptions if either DHCP or NFS isn’t available.

Back up the operating system with a native utility

You then back up the operating system to the NFS directory using dd. You can find out 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

(In our example, we did not back up /dev/hda3 since it is the swap partition and has no data.) Alternatively, you could 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 could place an & 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.

Perform a Bare-Metal Recovery

Use the following steps to recover your system from bare-metal.

Boot the system from alternate media

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

See Assumptions if either DHCP or NFS isn’t available.

Restore the boot block and prepare the new root drive

For restoring by partition, you need to restore the MBR and partition table and then restore each partition. You can restore the master boot record (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 that 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.

Restore the operating system

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 could 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.

Live Method

This example uses tar to back up and recover the system at the partition level. This allows the system to be online. The procedure was tested on a Linux system. We did not test this on a Windows system because we could not identify a single utility available in Windows and Knoppix that preserves ACLs. Your experience may be different.

Create the Bare-Metal Backup

Use the following steps to create a bare-metal backup of your system.

Back up the important metadata

Back up the MBR by running the following command:

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

Back up the operating system with a native utility

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

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

See Assumptions if either DHCP or NFS isn’t available.

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 .

Perform a Bare-Metal Recovery

Use the following steps to recover your system from bare metal.

Boot the system from alternate media

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

See Assumptions if either DHCP or NFS isn’t available.

Restore the boot block information and prepare the new root drive

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 that 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 /

Restore the operating system

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

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

Knoppix, by default, creates mount points for each of the partitions it sees, so you should already have /mnt/hda1 and /mnt/hda2 available and the command mount /dev/hda1 mounts that partition to /mnt/hda1. If you don’t, you need to create them first.

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, you would 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.

Alt-boot Filesystem Method

This example uses tar to back up and recover Linux partitions and ntsfclone to back up and recover Windows partitions. This requires the system to be offline (booted into Knoppix). This process should work with Linux and any Windows version that uses NTFS.

Create the Bare-Metal Backup

Use the following steps to create a bare-metal backup of your system.

Back up the important metadata

Back up the master boot record (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.

Boot the system from alternate media

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 -

Back up the operating system with a native utility

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

See Assumptions if either DHCP or NFS isn’t available.

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 really a filesystem utility per se since it does not back up on the file level. It’s really an image backup utility that really understands NTFS filesystems.

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

Perform a Bare-Metal Recovery

Use the following steps to recover your system from bare metal.

Boot the system from alternate media

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

See Assumptions if either DHCP or NFS isn’t available.

Restore the boot block and prepare the new root drive

For restoring by partition, you need to restore the MBR and partition table and then restore each partition. You can restore the master boot record (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 that 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 will be restored with the ntfsclone command.

Restore the operating system

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, you would 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 

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