How To Back Up Operating Systems

This is a step-by-step guide for backing up and restoring the operating system(s) installed on your PC (Linux, Windows, etc). Specifically, it describes how to back up and restore hard drive partitions and MBR boot code using free tools and discusses backup and restoration procedures and scenarios. Backup and restoration take about 10 minutes each.

Frequently Asked Questions

Why Is This Useful?

Uses and benefits include:

After a system upgrade or other 'surgery' gone wrong, you can roll the system back to its exact previous state.
If after a time your system performance degrades, you can roll the system back to its 'fresh install' state without having to reinstall.
If you are busy working on your computer and your system develops problems, instead of taking the time to research and fix them, you can restore your system in minutes and get back to work.
If you aren't sure if a new problem is hardware or software related, you can roll the system software back to when you know it worked. If the problem remains, it is a good indication of a hardware problem.
Your system is infected with a virus. Restoring from backup is a quick and thorough fix, equivalent to formatting your entire hard drive and tediously reinstalling everything from scratch (in 10 minutes).
You maintain a system in a public place. Instead of being worried that someone may 'mess up' the system, you know you can restore it in minutes.
Store your backup on a CD/DVD, external drive, or on a network share, and in the event of a hard drive failure, you can purchase a new hard drive and simply restore the partitions from backups.
During install of an OS, you can make backups at several stages. For example, you may make a backup before installing a video driver. If you have problems with the driver, instead of trying to cleanly remove it and try again, you can roll the system back, confident that it is 'clean' for the next driver test.
Having an MBR backup means that MBR damage or overwrite can be easily corrected.
You can test a new version of your OS. If it doesn't perform to your expectations, you can have your old system back in minutes.
Your backup tools do not rely on any commercial products or any operating system installed on your computer.

In short, this is a relatively easy procedure well worth taking the time to learn! Mastering this technique takes most of the fear out of system changes - you know how to press the 'rewind' button on everything you do, and the rewind button works reliably and quickly.

What Operating Systems Can Be Backed Up?

What OS(es) you're running doesn't matter. The only limitations are the filesystems being used and the amount of data involved. Most Linux and Windows systems are supported for backup. While some of the tools in this guide are available for use on Macs, this guide does not cover Mac backups specifically.

This guide supports the following filesystems (at least): ext2/3/4, reiserfs, reiser4, btrfs, xfs, jfs, vfat, fat16/32, ntfs, iso9660. Note that encrypted partitions cannot be backed up using the methods in this guide.

The second issue is the amount of data on the hard drive partition to be backed up. While there is no general limit on the size of the partition involved, it is most practical to back up a system which has separate partitions for the operating system(s) and the user data. This keeps the size of the backup practical. This means that if your hard drive has a single, huge partition containing the OS as well as the user data (movies, music files, documents, etc), then it will be difficult to back up this system due to the size of the backup, and in some cases the lack of a place to store the backup (which cannot be stored on the partition being backed up). In this case, consider repartitioning your hard drive so that your OS with installed software is stored on its own partition, separate from your user data files. (Repartitioning your hard drive is outside the scope of this guide and is not described here.)

Who Can Use This Guide?

This guide is primarily intended for Linux users who maintain multi-OS systems. Some basic knowledge of how Linux refers to and mounts partitions, and the ability to enter a few console commands carefully will be helpful, because this guide uses several Linux tools to accomplish the tasks. The ability to burn a CD from an ISO image will also be required. If you don't already have this knowledge, a little extra homework may be required to use this guide successfully.

The Tools For The Job

This guide will use the following tools:

SystemRescueCD - a free, slim, live Linux CD which includes the Partimage and FSArchiver programs, and other useful system tools. This is the system you will run to back up and maintain the other systems on your computer.

The Partimage program - free software that can easily copy a partition's contents into a single, compressed 'partition image file', and can also restore a partition's contents using such a file. http://www.partimage.org/

The FSArchiver program - a new program still in development which adds functionality not included in Partimage (such as ext4 support). http://www.fsarchiver.org

A printed copy of this guide is also helpful.

Getting SystemRescueCD

Step one is to make yourself a copy of the SystemRescueCD. This CD may be downloaded as an iso file from http://www.sysresccd.org/Download. After downloading the iso file, it is suggested that you check its integrity using md5sum. For example, on a Linux system you can generally do this by entering:

md5sum systemrescuecd-x86-1.3.5.iso

and compare the output with the md5sum published on the download page.

Finally, burn a copy of the CD using your CD burning software, and if possible have this software verify the integrity of the burn.

Note: If you plan to use FSArchiver, it is best to use the very latest beta version of SystemRescueCD. http://www.sysresccd.org/Beta-x86

Note: This guide is based on SystemRescueCD version 1.3.5. Later versions should be compatible with this guide, but when in doubt check the latest manual.

Creating Backups

Partition Backup Requirements

To back up a partition, you will need a "source partition" (a partition to be backed up), and a "target Partition" (a place to save the backup file). Both the source and target must already contain valid filesystems (ext2/3/4, reiserfs, reiser4, btrfs, xfs, jfs, vfat, fat16/32, ntfs, iso9660).

Note that the source partition may be a primary partition or a logical drive on an extended partition - this makes no difference.

The "target filesystem" (place to save the backup file) must NOT be located on the source partition. The backup file's size will be approximately half the size of the total data on the source partition (NOT half the total partition size). For example, if the 6 GB source partition contains 2 GB of files, the backup file will be approximately 1 GB. (The data on the partition is gzipped; free space is ignored.)

Examples of target filesystems which can be used to save your backup file:

Another formatted partition, on the same hard drive as the source partition, with ample space

A formatted partition on another internal hard drive

A USB stick or external hard drive with ample space

An NFS share on another computer

A shared folder on a networked Windows computer (samba share)

If you know the drive number and partition number of your source partition, and you know your target filesystem's location, then you are ready to proceed.

Prepare The Target

First, you may want to print out a copy of this guide.

Boot SystemRescueCD. You may generally press Enter at the "boot:" and keyboard prompts, and will eventually be presented with a root console prompt.

Enter the following command to prepare a mount point for the target filesystem:

mkdir /mnt/target

Next, mount your target filesystem (the place where you will save the backup file). Examples include:

# Note: If you'd like to see a list of partitions and sizes, you can enter:
fdisk -l
# OR
cat /proc/partitions

# To mount a local partition (hard drive, USB stick, etc.):
# In this example, sda5 (partition 5 of drive 1)
mount /dev/sda5 /mnt/target

# To mount a local NTFS partition with write permission:
ntfs-3g /dev/sda5 /mnt/target

# Note: Before mounting networked filesystems as shown below, you may need to enter:
net-setup

# OR  To mount a networked Windows shared folder (samba share):
mount -t smbfs -o lfs //192.168.10.3/my-share/ /mnt/target

# OR  To mount an NFS share:
mount -t nfs 192.168.10.1:/home/user/share /mnt/target

# Finally, make sure the target filesystem is successfully mounted:
ls /mnt/target

Once the target filesystem is mounted, you are ready to create the backup. This guide includes two methods for creating a partition backup: FSArchiver and Partimage. Each method has its strengths and weaknesses. Choose the method most appropriate for each partition you are backing up.

Create Partition Backup - FSArchiver Method

The FSArchiver method works best for linux filesystems (ext2/3/4, reiserfs, xfs, etc), and also has support for ntfs. FSArchiver has several advantages over Partimage: it supports ext4 and btrfs; it can restore data to a partition which is smaller than the original the backup was made from; it can change the filesystem type when restoring (eg ext3 to ext4); it can encrypt the backup; it checksums the data to detect corruption; and it can restore files from a partially corrupted backup. However, FSArchiver has no support for FAT filesystems, and the ntfs support is new and may not be stable. FSArchiver is also under heavy development and is thus not recommended for critical data (as of Jan 2010). Check the FSArchiver Homepage for the latest information on these issues. For more comparison information see FSArchiver vs Partimage. To make sure you have the most up-to-date version of FSArchiver, be sure to download the latest version of SystemRescueCD.

This guide currently recommends the FSArchiver method if a partition contains an ext2/3/4 or other linux filesystem. Otherwise the Partimage method detailed in the next section is recommended.

Working by example, the following command will create a backup of the /dev/sda5 partition and save it to the backup file "/mnt/target/backup-sda5.fsa" on the target filesystem:

fsarchiver savefs /mnt/target/backup-sda5.fsa /dev/sda5

It will take a few minutes. When finished, you can view information on the created archive with:

fsarchiver archinfo /mnt/target/backup-sda5.fsa

FSArchiver has other options for archive creation. Examples include:

# To encrypt the backup using "yourpassword":
fsarchiver -c yourpassword savefs /mnt/target/backup-sda5.fsa /dev/sda5

# To split the backup into 4300MB files for DVD burning:
fsarchiver -s 4300 savefs /mnt/target/backup-sda5.fsa /dev/sda5

# To use a dual-core processor for greater compression speed (or use -j4 for quad):
fsarchiver -j2 savefs /mnt/target/backup-sda5.fsa /dev/sda5

# To see progress and more details as the backup is created::
fsarchiver -v savefs /mnt/target/backup-sda5.fsa /dev/sda5

For further options and information, please consult the FSArchiver Quick Start Guide.

If you have a multi-OS system, create a backup (using Partimage or FSArchiver) of each relevant partition, saving each to an appropriately-named backup file. (Linux swap partitions do not need to be backed up.)

Create Partition Backup - Partimage Method

The Partimage method works for most filesystems (ext2/3, reiserfs, reiser4, xfs, jfs, vfat, fat16/32, ntfs, iso9660), but does not support ext4 or btrfs. Partimage has some other limitations: it does not checksum data so corruptions may not be detected; a corrupt archive cannot be partially restored; you can only restore data to a partition which is the same size as or larger than the original partition the backup was created from; there is no encryption built-in; there is no support for multi-threaded compression. Advantages of Partimage include that it backs up all data on the partition including VBR boot code, and it restores files to their original disk sectors. Partimage is an older program which is quite stable, but is no longer being developed, so no ext4 support is expected.

This guide currently recommends the Partimage method if a partition contains a FAT (including vfat) or ntfs filesystem. Otherwise the FSArchiver method detailed in the previous section is recommended.

Once the target filesystem is mounted, run the Partimage program:

partimage

Partimage's GUI just requires you to fill in the boxes. You can see some screenshots of this here... http://www.partimage.org/Partimage-manual_Usage

First, use the up & down arrow keys to highlight the partition you want to back up. Once it's highlighted, press Tab to move the cursor to the "Image file to create/use" box. Enter the backup file here. For example:

/mnt/target/backup-sda5

(This will save the backup to a file named "backup-sda5.000" in /mnt/target/)

Now move down to the "Action to be done:" box by pressing the Tab key and make sure the 'Save partition into a new image file' option is checked (use space bar to select it if necessary). Press F5 to proceed.

Next you are given some options - set these as you wish, using the Tab key to move and the spacebar to check/uncheck options. Generally you can leave them as they are. If the image file is larger than the set size (default 2 GB), it will be broken into multiple files (.000, .001, etc) If you are saving the image file to a FAT32 filesystem, be sure to set the split size no higher than 4000 MB. If you plan to burn your backup to CDs or DVDs, set this to 690 MB for CD or 4300 MB for DVD.

Press F5 to proceed.

The partition's contents will be gzipped and saved to the backup 'image' file(s) - takes 5-10 minutes on most systems. When it's done, exit Partimage.

If you have a multi-OS system, create a backup (using Partimage or FSArchiver) of each relevant partition, saving each to an appropriately-named backup file. (Linux swap partitions do not need to be backed up.)

How To Back Up An MBR And Partition Table

MBR Backup

For a discussion of what the MBR is and why we're backing it up, read How The Computer Boots - The MBR Explained.

For an automated utility which creates and restores MBR backup files, mbrback is recommended.

The MBR backup is a VERY small file (512 bytes). In this example, we will assume that /dev/sda is the first hard drive (boot drive) of the system. Substitute your correct boot drive accordingly.

# Back up entire MBR:
dd if=/dev/sda of=/mnt/target/sda-MBR-backup bs=512 count=1

Note that you do NOT include a partition number after the device name, just "sda".

IMPORTANT: Anytime you change the partitioning of the drive, or change the boot code in the MBR, you should make a new backup of the MBR. Restoring the MBR using an outdated backup MBR file can be fatal to all of the data on your drive!

Note: Linux users do not need SystemRescueCD to make an MBR backup. The above dd command may be executed from a root console while the system is running.

Partition Table Backup

While the MBR contains the primary partition table, it does not contain the extended partition table, which is stored on the extended partition. The program sfdisk may be used to back up and restore the entire partition table, including extended partitions. For example, to create a partition table backup of the first hard drive:

sfdisk -d /dev/sda > /mnt/target/sda-part-table.sf

Note: The output of sfdisk is plain text and may be viewed by loading the file into a text editor or omitting the redirection. This output can be used by sfdisk to restore (recreate) the partition table, as detailed in Partition Table Restoration.

Rebooting And Finishing Up

Finally, umount the target filesystem and reboot:

umount /mnt/target
reboot

When the screen goes blank, remove the CD so the computer boots into your OS. You should now find the backup files where you saved them. If on a Linux filesystem, they will be owned by root - change this as you like. For example:

sudo chown 1000:1000 backup-sda5.*

I now suggest creating a text file which describes the contents of the backup file. In this example it could be named "backup-sda5.txt", and would describe what OS version was on the partition at the time of backup, date it was created, md5sum of the backup file, what software and drivers were installed, etc. You can also use this text file to record subsequent changes you make to the system. This makes remembering and repeating these changes after restoration very quick.

You can now copy and move the backup files as you like - to another drive, to a networked computer, burn them to CD or DVD. If multiple backup files were created, numbered .000, .001,... (Partimage), or .fsa,.f01,.f02,... (FSArchiver), just keep them together - they will all be required for restoration.

How To Back Up The /home Folder

On Linux systems, the /home folder contains user software/desktop settings and some user files. This data changes more frequently than system files - usually daily - so it is convenient to have a more up-to-date backup of this data. Also, unlike the system files, this data may be reliably backed up while the system is running and users are logged in.

Manual Backup Of The /home Folder

The following examples assume your backup partition is mounted to /user - change if necessary.

# To make a backup tar file of your /home folder, enter in a console:
sudo tar --preserve -czf /user/home-backup.tar.gz /home

# Or, you can save space by omitting unnecessary files:
sudo tar --preserve --exclude=/home/*/.mozilla/firefox/*/Cache/* \
--exclude=/home/*/.mozilla/firefox/*/bookmarkbackups/* \
--exclude=/home/*/.googleearth/Cache/* \
--exclude=/home/*/.local/share/Trash/* --exclude=/home/*/.thumbnails/* \
-czf /user/home-backup.tar.gz /home

The /home folder has been compressed and saved to /user/home-backup.tar.gz.

Alternatively, you can simply copy your /home folder to a backup location without compression:

sudo cp -a /home /user/home-backup

The -a option ensures that file permissions and ownership information is retained.

Or, if your /home folder is on a separate partition of its own, you can use Partimage to back up the partition.

Automatic Backup Of The /home Folder

It is also possible to automate backup of the /home folder so that a daily backup is created. To do so, enter (or copy/paste) the following commands in a console: (substitute your desired backup location for "/user", preferably a different partition from your system partition)

# Create folders for backups and scripts to be used
mkdir -p /user/scripts
mkdir -p /user/backups
# Create a script to perform daily backups
echo '#!/bin/bash' > /user/scripts/daily-home-backup.sh
echo 'tar --preserve --exclude=/home/*/.mozilla/firefox/*/Cache/* \
--exclude=/home/*/.mozilla/firefox/*/bookmarkbackups/* \
--exclude=/home/*/.googleearth/Cache/* --exclude=/home/*/.local/share/Trash/* \
--exclude=/home/*/.thumbnails/* -czf /user/backups/home-backup-$(date +%Y-%m-%d-%H%M).tar.gz \
/home' >> /user/scripts/daily-home-backup.sh
# Make the script automatically remove backups older than 20 days
echo 'find -L /user/backups -type f -mtime +20 -name "home-backup-*.tar.gz" \
-execdir rm {} \;' >> /user/scripts/daily-home-backup.sh
# Make the script owned by root (security precaution since it will be run by root)
sudo chown root:root /user/scripts/daily-home-backup.sh
# Make the script executable
sudo chmod ugo+x /user/scripts/daily-home-backup.sh
# Create a crontab file to run the backup script daily at 3:00AM
echo '00 3 * * * /user/scripts/daily-home-backup.sh' > /user/scripts/root-crontab
# Install the crontab file
sudo crontab -u root /user/scripts/root-crontab

The above commands produce the following executable script (/user/scripts/daily-home-backup.sh) and schedule it to be run daily at 3:00AM:

#!/bin/bash
tar --preserve --exclude=/home/*/.mozilla/firefox/*/Cache/* \
--exclude=/home/*/.mozilla/firefox/*/bookmarkbackups/* --exclude=/home/*/.googleearth/Cache/* \
--exclude=/home/*/.local/share/Trash/* --exclude=/home/*/.thumbnails/* \
-czf /user/backups/home-backup-$(date +%Y-%m-%d-%H%M).tar.gz /home
find -L /user/backups -type f -mtime +20 -name "home-backup-*.tar.gz" -execdir rm {} \;

Anytime you want to manually create a backup of home, just enter:

sudo bash /user/scripts/daily-home-backup.sh

If you decide you don't want the daily-home-backup.sh script to run daily, just remove the crontab job:

sudo crontab -u root -r

The above script is just a simple example which may be customized by editing /user/scripts/daily-home-backup.sh There are also GUI backup programs on most systems which can automate backup of your /home folder.

Restoring From Backups

Restoration Requirements

Restoring the contents of a partition should restore all files and boot information present when the backup was made. Assuming the partition contained your OS, all the settings and installed software which were located on that partition will be restored to their previous state.

To restore, you need a backup file created by Partimage or FSArchiver, and you need a destination partition. The destination partition may be on any drive, and does not need to be the same partition the backup was created from. You may restore the backup file to any partition on any drive, providing:

If the backup file contains an OS, be sure the backup file was created on this same computer. Generally it is a poor idea to attempt to use backup files created on one computer with another computer, unless the hardware is virtually identical. (Each computer usually has a different mainboard, video card, memory, and other specifics. Running an OS which was installed on a different machine's hardware generally doesn't go well!) Make separate backup files for each computer's OS(es) and don't mix them.

The destination partition does NOT need to have a valid filesystem on it. It may be unformatted, or may contain any filesystem or data. Whatever is there will be overwritten. If you are restoring to a brand new drive, you merely need to create the partitions (using cfdisk, sfdisk, or similar).

(Partimage only) The size of the destination partition must be at least as large as the original partition the backup was created from, not merely big enough to hold the data. For example, if the original source partition was 10 GB with 2 GB of files on it, the new destination partition must be at least 10 GB in size (or larger - depending on the filesystem, it may automatically grow to use the available space). Partimage will refuse to restore to a smaller partition than the original. (Partimage uses a low level block/cluster copy to copy and restore the partition's contents, so file data is placed in its original location on the partition. more info) To copy and restore a partition to a smaller partition, use the FSArchiver method, or the method described in How To Copy Data To A Smaller Partition.)

If you know the location and type (Partimage or FSArchiver) of your backup image file, and it is accessible from the computer, and you know the drive and number of your destination partition, you are ready to restore. Note that Partimage backups have the extensions .000, .001, etc., while FSArchiver backups have the extensions .fsa, .f01, etc.

Prepare The Source

First, boot SystemRescueCD and mount the partition or network share where the backup file is stored. Using the backup location in our previous example:

# Our backup file is on /dev/sda5
mkdir /mnt/back
mount /dev/sda5 /mnt/back

OR, if you burned the backup file onto a bootable SystemRescueCD DVD (see how to do this), you will find it in /mnt/cdrom. You do not need to mount anything.

OR, if your backup file is located on a single CD or DVD, you can either copy the backup file to another location before booting SystemRescueCD, or you can boot SystemRescueCD in such a way that you can remove it from the drive. To do so, enter this at the "boot:" prompt:

boot: fb1024 docache doeject

or:

boot: fb800 docache doeject

The CD will eject after SystemRescueCD has booted, and you can insert another CD or DVD in the drive and mount it.

OR, if your backup file was split into multiple files (.000, .001, etc), you must copy them to a single location before proceeding, such as another partition or network share, and mount this location.

Restore Partition - FSArchiver Method

If you created your backup file using FSArchiver, you must use this method to restore it.

Working by example, to restore /dev/sda5 from the backup file /mnt/back/backup-sda5.fsa (substitute the device name you wish to restore to!):

fsarchiver restfs /mnt/back/backup-sda5.fsa id=0,dest=/dev/sda5

Note: "id=0" in the above command specifies that filesystem #0 in the archive is to be restored. Unless you saved multiple filesystems to the archive file, which is not covered in this guide, always use "id=0".

If you encrypted your archive using the -c option, use the same -c option when restoring.

If your backup was split into multiple files (.fsa, .f01, .f02...), just specify the first file (with .fsa extension) and FSArchiver will find the rest.

Note: Unlike Partimage, which restores an exact duplicate of a partition using a low level block copy, FSArchiver recreates the filesystem. This means that files will be in different locations on the disk. If the partition you restored contains GRUB's stage files (/boot/grub/), you will need to reinstall GRUB to the MBR so it can mark the new disk location of its files. If using LILO, it must also be reinstalled.

Note: If you restored to a different partition than the original, you may need to change Linux (GRUB, fstab) or Windows (boot.ini) boot information. Consult the Restoration Scenarios section for more information.

Finally, umount what you mounted, and reboot:

umount /mnt/back
reboot

Remove the SystemRescueCD at the blank screen and your computer will travel back in time!

Restore Partition - Partimage Method

If you created your backup file using Partimage, you must use this method to restore it. Once you have the location of your backup file(s) mounted, run Partimage:

partimage

First, using the up & down arrow keys, highlight the destination partition (the partition which will be restored using your backup file).

Press Tab to move the cursor to the "Image file to create/use" field. Enter your backup file location and name. In this example:

/mnt/back/backup-sda5.000

(If you have multiple backup files, just enter the name of the first file, including the extension .000)

Then press F5 to proceed. Follow on-screen instructions and the partition will generally be restored within 5-10 minutes.

Exit Partimage, umount what you mounted, and reboot:

umount /mnt/back
reboot

Note: If you restored to a different partition than the original, you may need to change Linux (GRUB, fstab) or Windows (boot.ini) boot information. Consult the Restoration Scenarios section for more information.

Remove the SystemRescueCD at the blank screen and your computer will travel back in time!

How To Copy Data To A Smaller Partition

If you want to copy the contents of a partition to a smaller partition and are unable to use FSArchiver, you can avoid Partimage's limitation using the cp command. Boot SystemRescueCD, and execute some variation of the following example commands:

# format destination partition (in this example /dev/sda3 using ext3)
# WARNING: this destroys all data on the partition!
mkfs.ext3 /dev/sda3
# mount source partition (/dev/sda2) and target
cd /mnt
mkdir source
mkdir target
mount /dev/sda2 source
mount /dev/sda3 target
# copy the filesystem
# Note: be sure to include the dots
cp -ax /mnt/source/. /mnt/target/.

Note: Unlike Partimage, the above method only copies the files on the partition. It does not copy the VBR boot sector of the partition (critical to Windows booting), and it changes the location of the linux kernel files (which may require reinstallation of your bootloader to the MBR).

How To Restore An MBR And Partition Table

MBR Restoration

You should only restore the MBR if it is necessary to do so, and you should be sure you have an up-to-date backup file to work with. Because the primary partition table is stored in the MBR, an out-of-date backup file containing a different version of the partition table can cause loss of data.

If you are merely rolling back the state of a partition in order to roll back your OS, you do not need to restore the MBR. The MBR only needs to be restored if the system is not booting the way you want (perhaps the MBR was damaged, you purchased a new hard drive and have no bootable MBR, or you installed Windows which overwrites the MBR without installing a multi-OS boot manager), or if the primary partition table has been damaged. Consult the Restoration Scenarios section to determine when it is appropriate to restore the MBR.

You can choose to restore the entire MBR, which restores the boot code as well as the primary partition table. Or you can restore just the boot code within the MBR. If the partition table is okay, just restore the boot code.

If you previously had GRUB installed in the MBR of your hard drive, restoring the boot code from backup is usually equivalent to reinstalling GRUB to the MBR.

For an automated utility which backs up and restores the MBR, mbrback is recommended.

In this example, we will assume that /dev/sda is the first hard drive (boot drive) of the system. Substitute your correct boot drive accordingly.

Boot SystemRescueCD and mount the location where your backup files are stored. Using the backup location in our previous example:

# Our backup file is on /dev/sda5
mkdir /mnt/back
mount /dev/sda5 /mnt/back

# Our boot drive is /dev/sda
# To restore the boot code ONLY, leaving the partition table unchanged:
dd if=/mnt/back/sda-MBR-backup of=/dev/sda bs=448 count=1

# OR, to restore the ENTIRE MBR (including partition table):
dd if=/mnt/back/sda-MBR-backup of=/dev/sda bs=512 count=1

IMPORTANT: Note that you do NOT include a partition number after the device name in the dd command, just "sda".

Note: Linux users may not need SystemRescueCD to restore the MBR. If you have a working Linux system, the above dd commands may be executed from a root console while the system is running.

Partition Table Restoration

While the MBR contains the primary partition table, it does not contain the extended partition table. If the full partition table needs to be restored (perhaps it was damaged or was modified incorrectly), the backup file created by sfdisk may be used. (This method also works to create a partition table on a new drive identical to another drive.) For example, to recreate the partition table from the backup made of the first hard drive:

sfdisk /dev/sda < /mnt/back/sda-part-table.sf

How To Restore The /home Folder

If /home is on a separate partition, it is restored using the same method as other partitions.

If the /home folder was copied or tarred, boot into your OS or SystemRescueCD. If using your OS, it is important not to log into the system as a graphical user. At the graphical desktop manager greeting, press Ctrl-Alt-F1 to access a console. Login as root (preferred) or as a user.

If using SystemRescueCD, you must mount the location of the backup files and the location of the /home folder before proceeding, and use the correct location of the home folder in lieu of "/home" in the example below (e.g. /mnt/mysystem/home instead of /home).

# First, remove the /home folder:
sudo rm -r /home

# If your backup of the /home folder was a copy made with "cp -a", just copy it back:
sudo cp -a /user/home-backup /home

# OR, if your backup is a tar file:
sudo cd /
sudo tar xzfp /user/home-backup.tar.gz

You may then reboot (enter "reboot") or press Ctrl-Alt-F7 to login to a desktop.

How The Computer Boots - The MBR Explained

It is valuable to have a basic understanding of how a computer boots so you know what to back up and what to restore when maintaining your system.

BIOS Device Priority

When you turn on your computer, the BIOS programming (which is stored in memory chips on the mainboard) starts running. Among other things, this BIOS program determines which drive or device will be booted first. The 'boot device priority' may be changed by entering the BIOS (aka Setup) at boot. A typical boot device priority is floppy, CDROM, hard drive 1. In most cases, the BIOS can be told which device on your system should be considered drive 1. This gives you control over what device boots your system.

Master Boot Record

The BIOS then consults the Master Boot Record (MBR) of the boot device. The MBR is NOT located on any partition of the device. Rather, it is the first 512 byte sector of the device, located in front of the first partition.

The MBR contains:

a 'boot code' area
the primary partition table
a 32 bit 'disk signature'

MBR Boot Code

When booting a boot device, such as a hard drive, the BIOS runs the program code contained in the MBR of the device (this program is called the 'boot code' of the MBR). Repartitioning your hard drive, formatting partitions, or restoring partitions from backup will NOT alter or restore the MBR boot code.

The MBR boot code is generally only modified by:

the installation program of an OS (eg a Linux or Windows install CD)
the repair facility of an OS (eg Windows fixmbr)
installing a boot manager (eg GRUB)
direct disk writing as used in this guide (dd)
a virus which infects the MBR
disk-wiping utilities (eg DBAN)

MBR Primary Partition Table

In addition to the boot code, the MBR contains the drive's primary partition table. This information includes the size, number, and OS-type of the partitions, and which one partition is marked 'bootable' (referred to as the 'boot' or 'active' partition of the drive). (The extended partition table, which defines any logical partitions of the drive, is located on the extended partition, not in the MBR.) The primary partition table of the MBR is modified by:

the installation program of an OS (eg a Linux or Windows install CD)
partitioning software (eg cfdisk, sfdisk, Gparted)
direct disk writing as used in this guide (dd)

Formatting or changing the data on the partitions does not change the partition table. You must resize, delete, or create partitions, change their type, or change the bootable partition in order to affect the MBR's partition table.

MBR Disk Signature

Finally, it should be noted that the MBR contains a 32-bit number (a "Windows NT disk signature" - now also used by Linux) intended to uniquely identify the disk medium (Note: this is NOT the same as UUIDs, which are stored in the filesystems on the partitions). Restoring the entire MBR to a new drive from an MBR backup file will duplicate this number.

For a thorough discussion of the MBR: http://en.wikipedia.org/wiki/Master_boot_record

Boot Management

Once the BIOS passes control to the MBR boot code, that program determines what happens next. The boot code area of the MBR is not very big, so it can't do much. Mostly what it does is pass control to another program. Here are several possible boot configurations:

Generic Boot Code

On a simple, single-OS system (such as DOS or older Windows), the MBR boot code will examine the partition table portion of the MBR to see which partition is marked 'bootable' (aka 'active'). It then passes control to the Volume Boot Record (VBR) of this boot partition. (A VBR is stored in the first few sectors of a partition, whereas the MBR is stored in the first sector of the drive). In this case, the VBR contains a boot loader - a program which the installed OS uses to get itself up and running. With this kind of generic MBR boot code, the only way to boot a different partition is to modify the partition table. Specifically, using a program like cfdisk, you must change which partition is marked 'bootable'.

Linux Boot Managers

On most Linux systems, the MBR boot code contains a boot manager such as GRUB or LILO. For example, if GRUB is installed to the MBR of the drive, it will run first. GRUB will consult its 'root partition' for further information. (When GRUB is installed, one partition is defined as the GRUB 'root' and contains data used by GRUB, generally in /boot/grub/. Specifically, GRUB's "menu.lst" or "grub.cfg" file tells GRUB what partitions on the system may be booted and how to boot them.) GRUB may present the user with a menu at boot time asking what partition to boot. Control is then passed to the Linux kernel and boot programs. Note that this scenario has at least two places where vital boot information is stored: in the MBR boot code, and on the partition designated as GRUB's 'root'. If either area is damaged or changed, it may affect the boot process. Note that this method ignores which partition is marked 'bootable' in the partition table. Also note that GRUB stores within the MBR boot code the physical disk sector where its stage file is located. If the physical location of this file changes (due to restoration with FSArchiver, for example), GRUB will need to be reinstalled to the MBR.

Windows Boot Managers

On newer Windows systems such as NT, XP, and Vista, a boot manager is used: NT Loader aka "NTLDR" (Windows NT and XP), or Windows Boot Manager (Windows Vista). When Windows is installed, the MBR's boot code will be overwritten. At boot, this code will transfer control to the VBR of the boot partition, which in turn transfers control to the NT Loader or Windows Boot Manager, which will control the rest of the boot process. Sometimes the boot manager will present a menu asking the user what installed version of Windows to boot. Note that this scenario has at least four places where vital boot information is stored: in the MBR boot code, in the boot flag of the MBR partition table, in the VBR of the boot partition, and in the filesystem of the partition containing the NT Loader or Windows Boot Manager. If any of these areas is damaged or changed, it may affect the boot process.

Linux & Windows

If a multi-OS system includes Linux and Windows, a Linux boot manager must be used to control the boot process because the Windows boot managers do not accommodate Linux partitions. This setup is very similar to a Linux-only system, except that in order to boot a Windows partition, the boot manager (such as GRUB) will transfer control to the VBR of the Windows partition, allowing the Windows boot loader or manager to take control (called chainloading). Note that this scenario has several places where vital boot information is stored: in the MBR boot code, on the partition designated as GRUB's 'root', in the VBR(s) of Windows partition(s), and in the filesystem(s) of the partition(s) containing NT Loader or Windows Boot Manager. If any of these areas is damaged or changed, it may affect the boot process. Note that this method ignores which partition is marked 'bootable' in the partition table.

Grub In A VBR And More

Another more rare variation of GRUB installation is for GRUB's boot code to be installed only in the VBR area of a partition, not in the drive's MBR. In this case the MBR contains generic boot code which simply boots the 'bootable' partition. If the partition where GRUB is installed to the VBR is marked 'bootable', GRUB will boot, and will present its menu, again based on its configuration files located on its root partition.

There are also many other possible variations of boot management, but the above examples describe most common configurations.

Backing Up And Restoring The Boot Process

For the purpose of backing up your complete system, you want to determine what needs to be backed up in order to restore not only the filesystems, but if possible the entire boot process. For example, if you have a simple, single-OS system, then the MBR boot code will simply boot the partition marked 'bootable'. In that case, if you back up the MBR and the partition containing the OS, you have a full backup. You can fully restore the system by restoring the MBR and the OS partition. (If you move the OS to a different partition, you simply need to change which partition is marked 'bootable'.)

If you have a multi-OS system which has GRUB installed in the MBR, then backing up and controlling the boot process is more complicated. You must back up the MBR, which contains the GRUB boot code. You also must back up the GRUB 'root' partition, which contains /boot/grub/ (along with your Linux OS). In addition, you must back up other partitions containing other OSes. To control the boot process on this kind of system, you edit GRUB's configuration files. Changing the 'bootable' flag in cfdisk will have no effect. To change which partition is GRUB's 'root', you must run GRUB and install it to the MBR.

In most cases, restoring the MBR boot code and the OS partitions will restore the boot process of the system. However, there are exceptions. The Windows installer will sometimes borrow the VBR of another compatible partition in order to boot the partition containing Windows, which can create very confusing boot behavior, and lead to breakages in the boot process. For example, Windows insists that it boot from hard drive 1, and not from extended partitions (logical drives). If you attempt to install it to a partition on another drive, or to an extended partition, it may write a boot loader into the VBR of one of the primary partitions on drive 1 in order to boot. In terms of backing up and restoring Windows, this means that sometimes restoring the partition containing Windows will not be enough to restore the boot process to working order. In this case, it may be necessary to reinstall or repair Windows using the Windows installation disc. In other cases, reconfiguring the Windows boot manager may be required (edit boot.ini, etc.) For a more detailed discussion of the Windows boot process, please consult Windows NT/XP Startup Process and Windows Vista Startup Process.

Also note that the Partimage program, one method used by this guide for backing up and restoring partitions, copies not only the filesystem on the partition but also the 'boot sector' contents of the partition's VBR, and it maintains the locations of the kernel and other files. (Partimage uses a low level block/cluster copy, not the linux kernel's filesystem support.) For more information please consult Partimage: How are the partitions read/written.

On the other hand, the FSArchiver method merely recreates the filesystem, so files may be moved, and the contents of the VBR may not be restored. However, when restoring ntfs partitions, FSArchiver does perform an ntfs-clone which is designed to maintain the boot functionality of a Windows partition. If a partition you restore with FSArchiver contains GRUB's root (/boot/grub/), you will need to reinstall GRUB to the MBR so that it can mark the new location of its files.

How To Set The Boot Partition

This section only applies if you have a single-OS system with generic MBR boot code that boots the 'bootable' (aka 'active') partition, OR if you have GRUB installed into the VBR of a partition rather than into the MBR (which is not usually done). If you have GRUB installed in the MBR, changing the 'bootable' partition will make no difference as GRUB ignores this.

To change the 'bootable' partition, boot SystemRescueCD or any Linux console and enter:

cfdisk

Highlight the desired boot partition using the up/down arrow keys. Next, make sure "[Bootable]" is highlighted at the bottom of the screen. If it is not, press Tab repeatedly until "[Bootable]" is highlighted. Press Enter. "Boot" should appear next to the partition name in the list above. Now press Tab repeatedly until "[Write]" is highlighted, and press Enter.

The partition table has been modified, so be sure to make a new backup of the MBR.

How To Set Grub's Root Partition

If you have GRUB installed in the MBR, then it will use files on its 'root' to determine what partitions are bootable and how (the GRUB menu). If you relocate GRUB's root to a different partition, or move the disk location of its files (as FSArchiver will when restoring), you need to tell GRUB where to find these files (called stage files).

If GRUB is not already installed to the MBR, this method will also install GRUB's boot code.

Because there are now two versions of GRUB in common use (v1 and v2) which work quite differently, you must first determine which version you are using. From your linux OS with GRUB installed, run:

grub-install -v

If the version is reported as something similar to "(GNU GRUB 1.97~beta4)", this means you are running GRUB v2. If the report is "(GNU GRUB 0.97)", you are using GRUB v1.

Use the method below appropriate for your version of GRUB.

GRUB v1

This describes how to set GRUB v1's root partition and install its boot code to the MBR.

From a Linux console (SystemRescueCd or an installed system), enter:

# To set GRUB's root partition and reinstall GRUB in the MBR:
# start GRUB
sudo grub
# Show partitions containing GRUB's stage 1
grub> find /boot/grub/stage1
# Select a partition from the list and set it as root  (sda2 in this example)
grub> root (hd0,1)
# Install GRUB into the MBR
grub> setup (hd0)
# exit GRUB
grub> quit

Note that GRUB v1 numbers hard drives and partitions starting from 0, not 1. So (hd0,4) is equivalent to /dev/sda5.

Note that the root partition must contain GRUB's stage files (usually in /boot/grub/). If it does not, you need to install the GRUB program (which is beyond the scope of this guide). Most Linux distributions install GRUB during installation.

The MBR has been modified, so be sure to make a new backup of the MBR.

GRUB v2

This section briefly describes how to set GRUB v2's root partition, install its boot code to the MBR, and reinstall the GRUB2 stage files (/boot/grub/).

First, from SystemRescueCD or your installed linux system, determine and mount the partition which contains GRUB's files (/boot/grub/). From your installed system, this should already be mounted on "/" or on your boot partition. If using SystemRescueCD, mount the partition manually. For example, if your GRUB root is on sda1, then from SystemRescueCD:

mkdir /mnt/grubroot
mount /dev/sda1 /mnt/grubroot

Once you have GRUB's root mounted, reinstall GRUB. With SystemRescueCD:

grub2-install --root-directory=/mnt/grubroot /dev/sda

Or if using your installed linux system:

sudo grub-install --root-directory=/ /dev/sda

If using your installed linux system, you may also want to update the GRUB menu:

sudo update-grub

Note: GRUB will install its files to the boot folder beneath the root you specify (eg /mnt/grubroot/boot/grub/ or /boot/grub/) Be sure NOT to include a partition number in the grub-install command, just "/dev/sda".

Note: SystemRescueCD contains both GRUB v1 and v2. "grub-install" runs GRUB v1, while "grub2-install" runs v2. On a linux system with just one version of GRUB installed, "grub-install" is the command to use. Use "grub-install -v" to see the version (0.9x is v1, 1.9x and later is v2).

For more thorough information on using GRUB v2, please consult GNU GRUB, the Ubuntu GRUB2 Guide, or the many other guides available for GRUB2.

The MBR has been modified, so be sure to make a new backup of the MBR.

Using UUIDs

Some Linux systems, such as Ubuntu, use UUIDs to identify partitions in GRUB's configuration files and in /etc/fstab. A UUID is a randomly generated identification number (for example ddec031f-558c-378f-b26f-158f5742c397) which is stored in the filesystem of the partition when it is formated. This means that reformatting a partition will change the partition's UUID. It also means that restoring a partition from backup will restore the UUID of the backed up filesystem.

If the UUIDs of partitions change, and GRUB and fstab are not updated, either the system will not boot, it will boot the wrong partition, or it may complain about missing filesystems.

One particularly troublesome condition you want to avoid is two partitions with the same UUID. This generally results from restoring a partition from a backup made on another partition. If two partitions have the same UUID, and GRUB or fstab use UUIDs to boot, it can create very confusing boot behavior. Be sure to generate a new UUID when you restore a partition using a backup containing a duplicate UUID.

In some cases it may be easier to change the UUID references in GRUB and fstab to device designations.

For example, this line in GRUB v1's /boot/grub/menu.lst:

kernel  /boot/vmlinuz-2.6.20-16-generic  root=UUID=ff0531cb-a7c6-4973-a106-02f62f432fff ro splash

might become

kernel  /boot/vmlinuz-2.6.20-16-generic root=/dev/sda2 ro splash

And this line in /etc/fstab:

UUID=d08bed28-71d2-45e8-9a20-07e593a7c828  / reiserfs  defaults  0 1

might become

/dev/sda2  /  reiserfs  defaults  0 1

If you do wish to continue using UUIDs, you may need to know how to look up a UUID and how to change a UUID. The following examples work on Ubuntu - your distribution may be slightly different.

# To look up the current UUID of /dev/sda2:
sudo blkid
# OR
sudo vol_id -u /dev/sda2

# To install a new random UUID in an ext2/ext3 filesystem:
# Note: device sda2 should not be mounted
sudo tune2fs -U random /dev/sda2

# To install a new random UUID in a reiser filesystem:
# Note: device sda2 should not be mounted
sudo reiserfstune --uuid random /dev/sda2

# Note: On some systems the reiserfstune command is tunefs.reiserfs

# To generate a random UUID for general purposes:
uuidgen -r

System Partitioning Recommendations

By partitioning your system well and setting it up carefully, you'll make maintenance much easier. This is not a guide on how to setup a multi-boot system, but some discussion of partition usage applies, and will be referenced in the following section on Restoration Scenarios. If you are not starting with a clean hard drive, you may be able to change the size of existing partitions and create new partitions without losing the data on your drive. One such method is the Gparted program distributed on many live CDs, including SystemRescueCD (you must startx to see the Gparted icon). For the purposes of this discussion, I will assume you are setting up a fresh, multi-OS system from scratch. If this is the case, you can run the cfdisk program on SystemRescueCD to destructively (re)partition your drive. All data on the drive will be lost.

A suggested partition table:

device  size    mount       use
------  ----    -----       ---
MBR     512b                GRUB boot code installed
sda1    2G      swap        Linux swap
sda2    7G      /           Linux system  [GRUB root partition]
sda3    20G     /mnt/win    Windows OS (ntfs or fat32) [VBR contains Windows boot code]
sda4    -                   Extended Partition (contains extended partition table)
sda5    20G     /mnt/sda5   test system
sda6    20G     /mnt/sda6   backup partition  [bootable SystemRescueCD]
sda7    xxG     /user       user data (reiser, ext3/4, ntfs, or vfat)

If you are installing Windows, it is best to partition your drive (using cfdisk on SystemRescueCD or another method), and then install Windows to its correct partition. Once Windows installation is complete, then install the Linux OS. Most Linux OSes will install GRUB to the MBR, so your system will become multi-boot.

Note: The reason Windows is installed first is that it overwrites the MBR, making itself the only bootable OS on the system. If you install it after Linux, this will remove GRUB from the MBR's boot code, and you will not be able to boot Linux without restoring the MBR boot code or reinstalling GRUB to the MBR.

If you have multiple Linux systems on your computer, they can share a single swap partition. The data in the swap is only valid while the OS is running (or hibernating). Generally, you need only one swap partition.

The size of the partitions above are approximate and will vary depending on what OS you're installing to them and how much software you're installing. Typically, Windows XP uses approximately 5 GB without software, and Vista takes 12 GB. A typical linux install with software may use 2-5 GB.

sda5 in the above example is an extra system partition where you can test new versions of an OS, or new OSes, without affecting your primary OSes. If you like the new system, you can then make that your primary OS (see Restoration Scenario #4).

sda6 is a storage area for backup partition images created by Partimage. It is safer to keep these on their own unmounted partition. You can also easily make this partition a bootable SystemRescueCD, so that you don't need to insert the SystemRescueCD to perform maintenance. Review How To Install SystemRescueCD On A Hard Drive.

sda7 uses the remaining space on the drive, and contains the majority of user data, such as documents, movies, music, and other large data. This amount of data is difficult to back up due to its size, which is why it is convenient to have it on a separate partition. This partition may also be used to store Partimage backup files. If you want this partition to be accessible from both Windows and Linux, it is easiest to format it as FAT32 or NTFS (although there are also drivers available which allow Windows to access Linux filesystems).

Note that the /home folder has been left on the / (Linux root) partition. This allows you to maintain different /home folders for different OS installations. Generally, having two OSes share a single /home folder can create problems. It is also acceptable to create a separate partition for /home. In this case, the /home partition or files are backed up and restored separately from the system partition.

Because we have GRUB installed to the MBR, it doesn't matter which of the partitions is marked 'bootable'. GRUB's /boot/grub/ files on sda2 will determine the default boot OS and options.

Restoration Scenarios

Working by example, this section will explore various restoration scenarios. It is assumed that you have an up-to-date backup of your boot drive's MBR, and a reasonably up-to-date backup image file of each partition containing an OS on your system. You may also have a separate, more recent backup of your /home folder available (for Linux systems), and a backup of your entire partition table made with sfdisk.

Instructions for all of the activities described in this section, such as restoring MBR boot code, are detailed in the prior sections of this guide.

Scenario #1: System Modification Gone Bad

This is a common use for restoration. Perhaps you tried an OS upgrade which did not turn out well. Perhaps you installed a driver which has created problems, and you don't know how to cleanly remove it. Perhaps you simply want to roll the system back to its 'fresh install' state when it was running better. Or perhaps you want to thoroughly clean and reconfigure your system for security purposes.

In this case, all that is required is restoring the partition containing the OS using the backup file. It is NOT necessary to restore the MBR.

The only other detail to consider is whether to restore your /home folder from a more recent backup, if available. If you believe your system problems may be related to user settings in the /home folder, you may wish to use the older version of the /home folder. If you want to restore your user's settings, then follow the system partition restoration with additional restoration of your /home folder.

Scenario #2: Repair Or Reinstall Of Windows On A Multi-Boot System

The Windows install and repair programs may overwrite the MBR, which means the system will no longer boot with GRUB - it will only boot into Windows. This is a quick fix. Restore the boot code portion of the MBR. Alternatively, you can reinstall GRUB to the MBR.

Scenario #3: A New Version Of Windows On Your Test Partition

In the example partitioning recommendations, sda5 is a partition reserved for testing new versions of an OS. You may want to install a new version of Windows to this partition, while leaving your old version intact on another partition.

The Windows install program will overwrite the MBR. At best, it will see several versions of Windows and will allow you to boot into them, but not into Linux. Or, you may only be able to boot into your new install of Windows.

The first step in correcting this is to restore the MBR boot code, which will put GRUB back in the MBR. Alternatively, you can reinstall GRUB to the MBR.

The system will now boot into the GRUB boot manager, but it will not be aware of the new Windows system. If using GRUB v1, you need to edit /boot/grub/menu.lst on the GRUB root partition (generally your Linux system partition), and add an entry for the Windows partition in the appropriate place. This will generally look something like this:

# /dev/sda5
title		Microsoft Windows
root		(hd0,4)
savedefault
makeactive
chainloader	+1

Note that GRUB v1 numbers hard drives and partitions starting from 0, not 1. So (hd0,4) is equivalent to /dev/sda5.

If you are using GRUB v2, simply update the menu with this command issued on your installed linux system, which should automatically find and add your Windows OS:

sudo update-grub

You can examine /boot/grub/grub.cfg to see if the OS was added. Note that GRUB v2 numbers hard drives starting from 0, and partitions starting from 1. So (hd0,5) is equivalent to /dev/sda5.

Depending on what version of Windows you installed, the behavior may vary. In some cases, each Windows partition can be booted independently by separate GRUB menu entries. In other cases, one Windows partition will boot to a Windows boot manager, which will present another boot menu, this time only for the different versions of Windows you have installed. Note that the partition you installed the new version of Windows to may not even be bootable - it may use another partition as its boot partition. For additional information, consult Backing Up And Restoring The Boot Process above.

Note that when a partition is formated during reinstallation, its UUID may change. This may cause your Linux system to complain during boot when it looks for the old UUID of the Windows partition. If so, you need to edit your /etc/fstab file to either reflect the new UUID, or change to a /dev/xxx reference. See Using UUIDs for instructions.

Scenario #4: A New Version Of Linux On Your Test Partition

If you want to test a new version of Linux without affecting your current working system, you can install it to the test partition (sda5 in the example partitioning). It can use the same swap partition as your original Linux system.

The good news is that most Linux installations will reinstall GRUB, and will recognize other OSes on the system. When you reboot, you should have the option to boot into all your OSes.

However, there is one thing to be aware of - the reinstallation of GRUB probably changed GRUB's root partition to the new system (sda5). This means that GRUB's configuration files (in /boot/grub/) on the new system partition is now controlling the boot options. This may be fine to use. However, you should know that if you erase the test partition, GRUB will not be able to find its /boot/grub/ files, and you will not be able to boot.

If you prefer to have your original Linux partition remain in control of GRUB, you can restore the MBR boot code from backup, or you can change GRUB's root partition. If using GRUB v1, then add an entry to your menu.lst file (on the original Linux system - sda2 in this example) to boot the new Linux system. Something like:

# Linux installation on /dev/sda5
title		Ubuntu (sda5)
root		(hd0,4)
kernel		/vmlinuz root=/dev/sda5 ro
initrd		/initrd.img
savedefault
boot

Note that GRUB v1 numbers hard drives and partitions starting from 0, not 1. So (hd0,4) is equivalent to /dev/sda5.

If you are using GRUB v2, simply update the menu with this command issued on your installed linux system, which should automatically find and add your installed OSes:

sudo update-grub

Also note that when a partition is formated during installation, its UUID may change. This may cause your old Linux system to complain during boot when it looks for the old UUID of the test partition. If so, you need to edit your /etc/fstab file (on the old system) to either reflect the new UUID, or change to a /dev/xxx reference. See Using UUIDs for instructions.

Scenario #5: Alternating Versions Of Linux

Major upgrades of Linux come out every few months. One method for using these upgrades is to install them to alternating partitions. For example, you might install Linux version 6 to sda2. Then install version 7 to sda5, leaving version 6 on sda2 intact. Then, you can install version 8 on sda2, leaving version 7 on sda5 intact, etc. This allows you to try out the new system install or upgrade while still having access to 'old reliable'. As noted earlier, both installations can share a common swap partition.

If you prefer to avoid upgrades and simply do a fresh install when a new version comes out, this is extremely easy. You simply install the new version to the free partition. This will also install GRUB, and will make the new Linux partition the GRUB root partition. Your computer will boot into the new installation by default, but this can easily be modified by editing GRUB's configuration (on the new partition). You can work on setting up the new installation at your leisure while still having access to your old system. (If you have servers running, you may want to assign the new installation a different IP address while you are working on it to distinguish it from the old system.)

If you prefer to work with upgrades, there are a few extra steps. First, make a copy of your old system partition onto the new partition. This is as simple as making a backup file of the partition and restoring it to the new partition. (Be sure to generate a new UUID for the copy partition, if applicable.) Next, make the new partition bootable by adding an entry to GRUB's menu (on the old partition). Finally, update /etc/fstab on the new partition so that the system knows where to find its root filesystem and other mountable partitions. You can now boot into two mirror copies of your Linux system.

Next, boot into the copy system and perform the upgrade, testing it as you like. If it is functional, you can make it your primary system simply by editing GRUB's configuration (on the old partition) to make it the default boot partition. The old partition may be left as a backup.

What you do with the /home folder during these alternating installs is a matter of preference. My suggestion is to copy the /home folder to the new partition, thereby creating two parallel /home folders. Or, you can have both installations share a common /home folder, but this may cause problems.

Once you have the two parallel systems installed, you can mount their filesystems from within each system to copy relevant files from one system to the other. You can also compare two versions of system files, etc. To offer maximum protection to your old installation, only mount its filesystems as readonly in the new system.

The bonus of alternating Linux installs is that you also always have a reliable backup system installed on your computer.

Scenario #6: Virus Infection

A virus may infect the system files, the /home folder (Linux), and the MBR. Unless you know where the virus is located, it is wise to restore the system partition(s), the MBR boot code, and optionally restore the /home folder using a backup which you know was made prior to infection. It is unusual for a virus to hop from one OS partition to another, but not impossible. When in doubt, restore them all.

You should also scan your user data partition for viruses.

Scenario #7: New Hard Drive

The first thing to address is partitioning. You should create the partition table from scratch using a tool like cfdisk (available on SystemRescueCD). Or, if the new drive is the identical size of the old drive, you can recreate the partition table from backup using sfdisk. If using the Partimage method for your backups, be sure to make your system partitions at least as large as the old partitions, or you will not be able to restore them (FSArchiver does not have this limitation, but the partition still needs to be large enough to hold all the data in the backup). Also, it is most convenient to use the same partition numbers for the installed systems so that GRUB can find them. Otherwise, you may need to update GRUB's configuration, change the fstab file(s), and edit Windows boot manager files to reflect the new partition numbers.

Now restore the system partitions, and if desired, /home folder. If /home is located on a separate partition, you must restore this as well. If your old hard drive failed, then you will need your backups which you saved to DVD or another drive (you did archive your backups to another drive, right??)

Once your partitions are restored, restore the MBR boot code (boot code only! NOT the full MBR which contains the old partition table). Alternatively, you can install GRUB to the MBR. (Note: If you used FSArchiver to restore the partition containing GRUB's root (/boot/grub/), you must install GRUB to the MBR due to the movement of the files on the disk.)

If you have changed the partition numbers of the installed systems, you may need to update GRUB's configuration, change the fstab file(s), and edit Windows boot manager files to reflect the new partition numbers. If you have changed the partition numbers of Windows, be sure to consult Backing Up And Restoring The Boot Process which details other Windows boot issues.

Scenario #8: Moving A System To Another Partition

You may want to move an installed OS to another partition, a larger partition, or onto a partition on a different drive. (Note: Moving Windows to a second drive or to an extended partition can be problematic for booting - keep Windows on a primary partition of the first hard drive.)

The first step is to prepare your new partition, and ensure that it is at least as large as the old partition. (If it is smaller, you will not be able to restore using Partimage.) Then, restore to the new partition using the backup file.

Next, you will need to address the boot process.

If the new partition is on a primary partition of the same drive, and you have a generic MBR which boots the bootable partition, then change which partition is marked 'bootable'.

If you have GRUB in the MBR, and you moved GRUB's root (/boot/grub/), you will need to change GRUB's root partition.

If the new partition is on a different drive and contains GRUB's root, you may need to make the new drive bootable by restoring the boot code of the MBR from the old drive, or by changing GRUB's root partition. You may also need to change the BIOS boot device priority or drive numbering, or the BIOS will continue to boot the old drive's MBR. In short, when you're done, the MBR of the boot drive must contain boot code (GRUB, etc), and GRUB must be set to the correct root partition to find its /boot/grub/ files.

If using GRUB, you will also need to update GRUB's configuration to reflect the new location of the moved OS (with GRUB v1, edit the entry in the /boot/grub/menu.lst file; with GRUB v2, run update-grub). To edit files, you can use the nano editor on SystemRescueCD (once you have mounted the file's location).

As your new partitions may have different UUIDs or device designations, or two partitions may now have identical UUIDs, you may need to change /etc/fstab entries to reflect the new locations in order for your Linux OS to boot. You can change outdated UUIDs to /dev/xxx if necessary. Most importantly, fstab tells Linux where its root filesystem (/) is located. See Using UUIDs for instructions.

If you have changed the partition numbers of Windows, you may need to edit Windows boot manager files to reflect the new partition numbers. Also, be sure to consult Backing Up And Restoring The Boot Process which details other Windows boot issues.

How To Burn A Bootable DVD Containing Backup Files And Tools

It is possible and very simple to burn a DVD which includes the bootable SystemRescueCD system on it, as well as one or more backup files for your partitions. You can do this from any Linux installation which includes the growisofs program (which is common), including SystemRescueCD.

Assuming the SystemRescueCD iso file is located in /user/, and your backup files are located in the folder /user/backups/

# Where /dev/hdc is your DVD-burner - change if necessary
growisofs -Z /dev/hdc=/user/systemrescuecd-x86-1.3.5.iso
growisofs -M /dev/hdc -J -R /user/backups/

Obviously there must be ample space on the DVD for the iso contents as well as the backup files in /user/backups/ for this to be successful.

How To Install SystemRescueCD On A Hard Drive

It is also very simple to make a hard drive partition a bootable SystemRescueCD system. This alleviates the need to put the CD in the drive in order to perform system maintenance. In the example partitioning, the backup partition would be an ideal candidate.

The only requirements are that the partition has 200MB free, and that it use one of the standard filesystems supported by SystemRescueCD. You can even use a partition which has another bootable system on it. (The partition can be booted two different ways depending on the GRUB menu entry selected.)

The procedure is as follows:

# Mount the iso file
sudo mkdir /mnt/iso
sudo mount -o loop /user/systemrescuecd-x86-1.3.5.iso /mnt/iso

(Alternatively, you can simply insert the SystemRescueCD in the CDROM drive so that the files can be read directly from it.)

Next, create a folder on the destination partition, in this example /dev/sda6, and copy the relevant files to this folder (/sysrcd). Note that some of the files are located in the isolinux sub-folder, but they should all be copied without directory structure to /sysrcd.

sudo mkdir /mnt/sda6
sudo mount /dev/sda6 /mnt/sda6
sudo mkdir /mnt/sda6/sysrcd
sudo cp /mnt/iso/sysrcd.dat /mnt/iso/sysrcd.md5 /mnt/iso/isolinux/initram.igz \
/mnt/iso/isolinux/rescuecd /mnt/iso/isolinux/rescue64 \
/mnt/iso/isolinux/altker32 /mnt/iso/isolinux/altker64 \
/mnt/sda6/sysrcd
umount /mnt/iso

The hard drive partition /dev/sda6 is now bootable. We just need to add an entry to GRUB's menu.

If using GRUB v1, edit /boot/grub/menu.lst so it appears as a boot option...

title       SystemRescueCD-1.3.5 (sda6)
root        (hd0,5)
kernel      /sysrcd/rescuecd subdir=sysrcd setkmap=us
initrd      /sysrcd/initram.igz
savedefault
boot

If using GRUB v2, create a file named "/etc/grub.d/51_my-sysrcd" (or wherever your grub.d folder is located), and paste the following text into the file, modifying the "set root" line as needed:

#!/bin/sh

echo "Adding SystemRescueCD" >&2
cat << EOF
menuentry "SystemRescueCD-1.3.5 (sda6)" {
set root=(hd0,6)
linux /sysrcd/rescuecd subdir=sysrcd setkmap=us
initrd /sysrcd/initram.igz
}
EOF

Save that file, then run:

sudo chmod +x /etc/grub.d/51_my-sysrcd
sudo update-grub

For up-to-date instructions on the above procedure, as well as instructions for installing SystemRescueCD to a bootable USB stick, please consult:

Alternatives To Using SystemRescueCD

In some situations, it may be more convenient not to use SystemRescueCD, although I do recommend keeping a CD copy on hand.

For example, if you have two Linux systems installed on your computer, you can install the Partimage or FSArchiver programs and use them from your installed systems to back up other, unmounted partitions. This way you will not have to reboot to make some backups. One limitation is that you cannot use Partimage to back up a mounted partition, so you cannot back up the booted system using the booted system.

Also, other live Linux CDs often include the Partimage program. If they run successfully on your hardware, you can use these as a substitute for SystemRescueCD. The advantage to SystemRescueCD is that it boots very quickly. Some other live CDs are not so reliable or quick to use.

Other free tools include:

Clonezilla: based on DRBL, Partition Image, ntfsclone, and udpcast, it allows you to create backups and recover

PC Inspector Clonemaxx: A no-frills simple method described in How to Back Up Any Hard Drive

How To Back Up Operating Systems

Frequently Asked Questions

Why Is This Useful?

What Operating Systems Can Be Backed Up?

Who Can Use This Guide?

The Tools For The Job

Getting SystemRescueCD

Creating Backups

Partition Backup Requirements

Prepare The Target

Create Partition Backup - FSArchiver Method

Create Partition Backup - Partimage Method

How To Back Up An MBR And Partition Table

MBR Backup

Partition Table Backup

Rebooting And Finishing Up

How To Back Up The /home Folder

Manual Backup Of The /home Folder

Automatic Backup Of The /home Folder

Restoring From Backups

Restoration Requirements

Prepare The Source

Restore Partition - FSArchiver Method

Restore Partition - Partimage Method

How To Copy Data To A Smaller Partition

How To Restore An MBR And Partition Table

MBR Restoration

Partition Table Restoration

How To Restore The /home Folder

How The Computer Boots - The MBR Explained

BIOS Device Priority

Master Boot Record

MBR Boot Code

MBR Primary Partition Table

MBR Disk Signature

Boot Management

Generic Boot Code

Linux Boot Managers

Windows Boot Managers

Linux & Windows

Grub In A VBR And More

Backing Up And Restoring The Boot Process

How To Set The Boot Partition

How To Set Grub's Root Partition

GRUB v1

GRUB v2

Using UUIDs

System Partitioning Recommendations

Restoration Scenarios

Scenario #1: System Modification Gone Bad

Scenario #2: Repair Or Reinstall Of Windows On A Multi-Boot System

Scenario #3: A New Version Of Windows On Your Test Partition

Scenario #4: A New Version Of Linux On Your Test Partition

Scenario #5: Alternating Versions Of Linux

Scenario #6: Virus Infection

Scenario #7: New Hard Drive

Scenario #8: Moving A System To Another Partition

How To Burn A Bootable DVD Containing Backup Files And Tools

How To Install SystemRescueCD On A Hard Drive

Alternatives To Using SystemRescueCD

Further Reading