How To Backup Operating Systems
From Wikibooks, the open-content textbooks collection
This is a step-by-step guide for creating backups of the operating system(s) installed on your PC (Linux, Windows, etc). Specifically, it describes how to backup and restore hard drive partitions and MBR boot code using free tools. Backup and restoration take about 10 minutes each.
[edit] Frequently Asked Questions
[edit] 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, USB stick, or on another system's hard drive, 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.
[edit] What Operating Systems Can Be Backed Up?
An OS is just a collection of files on a portion of your hard drive. This method simply makes a backup copy of all of that data, so it doesn't matter what OS you're running. The only limitations are the filesystem being used and the amount of data involved.
This method supports the following filesystems (at least): ext2/ext3, reiserfs, reiser4, xfs, jfs, Fat16/Fat32, ntfs, iso9660. This means that most Linux and Windows systems are supported for backup. Note that encrypted partitions cannot be backed up using this method.
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 backup 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 backup 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 (movies, music, etc). (Repartitioning your hard drive is outside the scope of this guide and is not described here.)
[edit] 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.
[edit] The Tools For The Job
This guide will use the following tools:
- 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/
- SystemRescueCD - a free, slim, live Linux CD which includes the partimage program and other useful system tools. This is the system you will run to backup the other systems on your computer.
[edit] 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. On a Linux system you can generally do this by typing:
md5sum systemrescuecd-x86-1.0.2.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: This guide is based on SystemRescueCD version 1.0.2. Later versions should be compatible with this guide as well, but when in doubt check the latest manual.
Related topics:
[edit] Creating Backups
[edit] Partition Backup Requirements
To backup a partition, you will need a "source partition" (a partition to be backed up), and a "target filesystem" (a place to save the backup file). Both the source and target must already contain valid filesystems (ext2/ext3, reiserfs, reiser4, xfs, jfs, Fat16/Fat32, ntfs, or 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 source partition contains 2GB of files, the backup file will be approximately 1GB. (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 partition, on the same hard drive as the source partition, with ample space
- A 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
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.
[edit] How To Backup A Partition
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:
# To mount a local partition (hard drive, USB stick, etc.): # In this example, sda5 (partition 5 of drive 1) mount /dev/sda5 /mnt/target # Note: If you'd like to see a list of partitions and sizes, you can enter: cat /proc/partitions # 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, run the partimage program. Enter: 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 backup. Once it is 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 2GB), 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 700 MB for CDs or 4400 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, run partimage again and create a backup of each relevant partition, saving each to an appropriately-named backup file. (Swap partitions do not need to be backed up.)
[edit] How To Backup An MBR
For a discussion of what the MBR is and why we're backing it up, read #How The Computer Boots - The MBR Explained.
This 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.
# Backup 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".
Linux users do not need SystemRescueCD to make an MBR backup. The above dd commands may be executed from a root console while the system is running.
[edit] Rebooting And Finishing Up
Finally, umount the target filesystem and reboot:
umount /mnt/target sync 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:
sudo chown user1:user1 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 this backup file as you like - to another drive, to a networked computer, burn it to CD or DVD. (If multiple backup files were created, numbered .000, .001, etc., just keep them together - they will all be required for restoration.)
[edit] How To Backup The /home Folder
On Linux systems, the /home folder contains user software/desktop settings and some 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.
[edit] 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 backup the partition.
[edit] 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.
[edit] Restoring From Backups
[edit] Restoration Requirements
Restoring the contents of a partition using a backup file means that the partition will reflect the exact state the partition was in 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 'partition image file' created by partimage, and you need a destination partition. The destination does not need to be same partition the backup was created from. You may restore the backup file to any suitable partition on any drive, providing:
- 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 10GB with 2GB of files on it, the new destination partition must be at least 10GB in size (or larger - the filesystem will grow). Partimage will refuse to restore to a smaller partition than the original. (This limitation existed the last time I tested partimage in this manner. Current or later versions may not have this limitation.) (To copy a partition to a smaller partition, see the method described in #Scenario #8: Moving A System To Another Partition.)
- 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 unformated, 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 or similar).
If you know the location 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.
[edit] How To Restore A Partition
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, enter:
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.
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).
WARNING: All the data currently stored on this partition will be overwritten!
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)
IMPORTANT: Press Tab twice to move down to "Restore partition from an image file" and press spacebar to select it.
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
Remove the SystemRescueCD at the blank screen and your computer will travel back in time!
[edit] How To Restore An MBR
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). 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 equivalent to reinstalling grub to the MBR.
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 ENTIRE MBR (including partition table): dd if=/mnt/back/sda-MBR-backup of=/dev/sda bs=512 count=1 # OR, restore the boot code ONLY, leaving the partition table unchanged: dd if=/mnt/back/sda-MBR-backup of=/dev/sda bs=448 count=1
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.
[edit] 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 or as a user.
If using SystemRescueCD, you must mount the location of the backup files before proceeding.
# 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: 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 or press Ctrl-Alt-F7 to login to a desktop.
[edit] 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 backup and what to restore when maintaining your system.
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 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 some cases, the BIOS can be told which hard drive on your system should be considered drive 1. This gives you control over what device boots your system.
When booting a hard drive, the BIOS runs the program code contained in the Master Boot Record (MBR) of the hard drive (this program is called the 'boot code' of the MBR). The MBR is NOT located on any partition of the hard drive. It is the first 512 bytes of the drive, located in front of the first partition. Thus, 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 Windows install CD)
- the repair facility of an OS (eg fixmbr)
- installing a boot manager (eg grub)
- by direct disk writing as used in this guide
- or by a virus which infects the MBR
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'. (The extended partition table, which defines the logical drives of the system, is located on the extended partition, not in MBR.) The primary partition table is modified by:
- the installation program of an OS (eg Windows install CD)
- partitioning software (eg cfdisk or Gparted)
- or by direct disk writing as used in this guide
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.
Finally, it should be noted that the MBR contains a 32-bit number intended to uniquely identify the drive. Restoring the MBR to a new drive from an old MBR backup file will duplicate this number.
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 scenarios:
- On a simple, single OS system (such as DOS or Windows), the MBR boot code will examine the partition table portion of the MBR to see which partition is marked 'bootable' (aka 'active'). It will then pass control to the Volume Boot Record (VBR), or "boot loader", of this partition. The VBR boot loader is simply a program which the installed OS uses to get itself up and running (the VBR is stored ON the partition, and is thus backed up/restored when the partition is backed up/restored). 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'.
- On a dual-boot or multi-OS system, the MBR boot code may contain a multi-OS boot loader such as grub. If grub is installed to the MBR of the drive, it will run first. grub will then 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, the menu.lst file tells grub what partitions on the system may be booted and how to boot them. Note that this scenario has 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 will affect the boot process. Note that this method ignores which partition is marked 'bootable' in the partition table.
- 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 it's menu, again based on menu.lst, located on its root partition.
- There are many other variations of bootloading, including chainloading, which means having one system's bootloader load another system's bootloader. (Technically, grub boots Windows via chainloading.) However, these aspects are beyond the scope of this discussion.
- There are also other boot loaders besides grub, such as LILO. This guide does not currently describe the use of other boot loaders, but generally they are stored in the MBR in a similar manner to grub.
For the purposes of backing up your system, you want to determine what needs to be backed up, and what each backup contains. 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 backup 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 slightly more complicated. You must backup the MBR, which contains the grub boot code. You also must backup the grub 'root' partition, which contains /boot/grub/menu.lst (along with your OS). In addition, you must backup other partitions containing other OSes. Note that if the MBR is damaged, or the grub 'root' partition is damaged or moved, the system will not boot properly. To control the boot process on this kind of system, you edit menu.lst. 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 - which modifies the MBR contents.
For a thorough discussion of the MBR: http://en.wikipedia.org/wiki/Master_boot_record
[edit] 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.
[edit] How To Set Grub's Root Partition
If you have grub installed in the MBR, then it will use the menu.lst and other files on its 'root partition' to determine what partitions are bootable and how. If you relocate grub's root partition, you need to tell grub where to find these files (called stage 1 files). This describes how to set grub's root partition and install it 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) # OR, if grub is installed in the VBR rather than the MBR (this is rare) # put grub into the partition's VBR instead of putting it in the MBR # Note - you will also need to make the partition 'bootable' grub> setup (hd0,1)
Note that grub 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 1 files (usually in /boot/grub). If it does not, you need to install grub (which is beyond the scope of this document). Most Linux distributions install grub during installation.
[edit] Using UUIDs
Some Linux systems, such as Ubuntu, use UUIDs to identify partitions in grub's menu.lst 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 re-formating a partition will change the partition's UUID. It also means that restoring a partition from backup will restore the UUID of the backup's filesystem.
If the UUIDs of partitions change and menu.lst 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 menu.lst and 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 menu.lst and fstab to device designations.
For example, this line in grub'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 lookup a UUID and how to change a UUID. The following examples work on Ubuntu - your distribution may be slightly different.
# To lookup the current UUID of /dev/sda2: 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
[edit] System Partitioning Recommendations
By partitioning your system well and setting it up carefully, you'll make maintenance much easier. 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 the 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 installed sda1 2G swap Linux swap sda2 7G / Linux system [grub root partition] sda3 7G /mnt/win Windows OS (fat32 or ntfs) sda4 xxG Extended Partition (contains logical drives) sda5 7G /mnt/sda5 test system sda6 7G /mnt/sda6 backup partition [bootable SystemRescueCD] sda7 xxG /user user data (reiser, ext3, or fat32)
If you are installing Windows, it is best to partition your drive (using cfdisk on SystemRescueCD or another method), and then install Windows first 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, and you will not be able to boot Linux.
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.
sda5 is an extra system partition where you can test new versions of an OS, or new OSes, without affected 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 backup 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 (although there are other options requiring drivers).
Note that the /home folder has been left on the / partition. This allows you to maintain a different /home folder 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'. The /boot/grub/menu.lst file on sda2 will determine the default boot OS and options.
[edit] 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).
[edit] Scenario #1: System Modification Gone Bad
This 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.
[edit] 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. (Or, if you are confident that your MBR backup file contains the current version of your partition table, you can just restore the entire MBR.) Alternatively, you can reinstall grub to the MBR.
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.
[edit] 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. At worst you will 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. (Or, if you are confident that your MBR backup file contains the current version of your partition table, you can just restore the entire MBR.) Alternatively, you can reinstall grub to the MBR.
The system will now boot as before, but it may not be aware of the new Windows system. Now 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 numbers hard drives and partitions starting from 0, not 1. So (hd0,4) is equivalent to /dev/sda5.
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.
[edit] 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 /boot/grub/menu.lst 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 menu.lst, 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.
Finally, 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
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.
[edit] 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 menu.lst (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 menu.lst (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 menu.lst (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.
[edit] 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 system partition to another, but not impossible. When in doubt, restore them all.
You should also scan your user data area (/user) for viruses.
[edit] 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). Be sure to make your system partitions at least as large as the old partitions, or you will not be able to restore them. Also, it is most convenient to use the same partition numbers for the installed systems so that grub can find them. Otherwise, you will need to reorganize grub's menu.lst and change the fstab file(s) 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.
If your new partitions have different UUIDs or device designations, you will need to change /etc/fstab entries to reflect the new locations in order for your Linux OSes to boot. You can use the nano editor on SystemRescueCD to edit these files (once you have mounted them). Most importantly, fstab tells Linux where its root filesystem (/) is located. See #Using UUIDs for instructions.
[edit] 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.
The first step is to create your new partition, and ensure that it is at least as large as the old partition. (If it is smaller, you may not be able to restore.) Then, restore the new partition using the backup file.
Next, you will need to address the boot procedure if the partition you moved was the bootable partition, or was grub's root partition.
If the new partition is on 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 the old partition was grub's root partition, then you will need to change grub's root partition.
If the new partition is on a different drive, you will need to make the new drive bootable by restoring the boot code of the MBR from the old drive, or by installing grub to the MBR. 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. If you have a generic MBR which boots the bootable partition, then change which partition is marked 'bootable'. If you have grub in the MBR, then you will need to change grub's root partition.
If using grub, you will also need to edit the entry in the root partition's /boot/grub/menu.lst file to reflect the new location of the system. You can use the nano editor on SystemRescueCD to edit these files (once you have mounted them).
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.
Note: If you do want to copy the contents of a partition to a smaller partition, 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/.
[edit] 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.0.2.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.
[edit] 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 menu.lst entry selected.)
The procedure is as follows:
# Mount the iso file sudo mkdir /mnt/iso sudo mount -o loop /user/systemrescuecd-x86-1.0.2.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 /boot/grub/menu.lst so it appears as a boot option...
title SystemRescueCD-1.0.2 (sda6) root (hd0,5) kernel /sysrcd/rescuecd subdir=sysrcd setkmap=us initrd /sysrcd/initram.igz savedefault boot
For up-to-date instructions on the above procedure, as well as instructions for installing SystemRescueCD to a bootable USB stick, please consult:
- http://www.sysresccd.org/Sysresccd-manual-en_Easy_install_SystemRescueCd_on_harddisk
- http://www.sysresccd.org/Howto_install-usb-stick
- http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick
- http://www.sysresccd.org/forums/viewtopic.php?t=1828
[edit] 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 program and use it from your installed systems to backup other, unmounted partitions. This way you will not have to reboot to make some backups. One limitation is that you cannot use partimage to backup a mounted partition, so you cannot backup 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 and it has run successfully on every system I have ever used it on - new and old. 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 clone maxx: A no-frills simple method described in How to Back up Any Hard Drive.
