MBR Backup

Introduction

Without getting into too many specifics, the MBR (Master Boot Record) is the most significant sector on all hard drives. It is the first 512byte sector also known as sector 0. It normally contains some assembly code, which are instructions for the processor to act upon; instructions known as bootstrap code in this location. There is also some text for displaying error messages, a disk signature (or soft hard drive ID), the four primary partition tables and, at the very end, there are two byes with the magic hexadecimal number AA55 (or 55 AA as successive 'little endian' bytes) and which identifies the particular sector as being a boot sector. All these structures can be looked at in much greater detail on the Starman's Website if desired.

Basically when a hard drive gets chosen as the boot device during start-up, the assembly code is passed to the start of its MBR. These instructions read and act upon pertinent information in the vicinity and attempt to continue the instructions on the appropriate system partition. If the process fails, one of a number of generic messages is usually issued for the user to read.

DOS and Windows use a standard MBR created (and often recreated) when the hard drive is partitioned for, or during, the insallation of the operating system. This arrangement passes-on the bootstrap code to the PBS (Partition Boot Sector) of the partition marked as active in the MBR's partition tables and from where the operating system begins to load.

The regular (as used by Windows, etc) bootstrap code can be replaced (or overlaid) by a number of software entities. These are mostly 3rd-party boot managers as well as the occasional boot sector virus or OEM utility or other "oddity". This is particularly common when booting non-Microsoft operating systems or when installing multiple operating systems on one PC.  These function a bit differently from normal by taking-over (or hijacking) the bootstrap code for their own purposes before returning it, either to the original location or to a brand new location when they have done their work. The 'soft' hard disk signature (which has significance for all the NT-based versions of Windows and has  very special relvance to Vista) and the partition tables are the other two areas that can be can be either intentionally or unintentionally modified by a number of utilities or system failures.

Why back-up the MBR?

If, for whatever reason, a normal and functional MBR gets modified then the whole system can fail to start-up or boot. Often such changes can be repaired, using a number of techniques, but the ability to restore the original code must have obvious advantages and indeed it may be the only way to get back an original factory installed MBR on certain OEM systems. In order to be able to restore the original, two things must be considered. One is to make the backup copy in a location where it will be accessible when needed. The second is to have a utility that you can access from something other than the hard drive in order to restore the original. This is a common feature - almost a paradox - when backing-up all sorts of stuff that often gets forgotten about. It is generally much easier to make a backup than it is to effectively and safely restore it. So this aspect should be given proper attention at the time of back-up creation - particularly considering that the need to be capable of restoring it is because one has, in the first case, usually got a non-functional hard drive that one wants to regain access to.

Know how the MBR will get restored when needed?

It might seem like 'putting the cart before the horse' but it is a very good principle of backup methodology to use, for initial backup, the same method you will use later-on to restore. We outlined one method of backing-up the MBR using a Windows utility in this page's QuickStart section and for most users this is a good quick way to at least create a backup file. Its downside is that in order to use the same Windows utility to restore the file one must have booted up to either a second hard drive in the same computer or to take the drive out and do the restoration of its MBR on a totally separate PC. The second dimension to restoration is, of course, that one must not only be able to run the utility but one must also be able to identify and access the backup file. If, for example the file was initially saved to a USB drive from the hard drive, and you later want to say run MBRwizard from a DOS boot floppy, you would probably need to copy the file directly to that floppy since most floppies cannot access USB drives without a lot of "geekiness" being involved. Bear in mind too that restoring the bad drive's MBR from a good hard drive on the same PC runs the risk of restoring the backup to the wrong hard drive and thus finishing up with two inaccessible drives. It is thus a good idea to always make new backups of all the MBRs in a multidrive system before restoring an older backup.

Floppy diskette backup and restoration

If you have an internal floppy drive (or a USB floppy drive that your system supports booting-to) then this is an appropriate and effective way of both creating and restoring the MBR and of storing the backup file onto. Unfortunately more and more systems no longer ship with floppy drives and by no means do all PCs support booting to USB drives. MBRWizard provides a DOS based version which can be added to a DOS boot floppy diskette. You could do worse than grab the Driver Free Disk For BIOS Flashing and then add whatever backup utility/utilities you want to run from it. It is just a very clean boot diskette with the maximum available space for the user to avail of. It is thus very suitable for BIOS Flashing (hence its name) but it can always be used as a minimalist boot floppy for other functions. You can, of course, use any other DOS/Win9X boot diskette (often called a startup disk) of your choice. Apart from MBRWizard there are other DOS-based MBR utilities that you can use in a similar manner from a boot floppy. These include TerabyteUnlimited's MBRWork 1.07b and DIY DataRecovery's MBRTool 2.2/2.3. Make sure you read the documentation from all these utilities - particularly before doing any restorations.

MBRTool now comes with a Windows installer that can help you create a bootable floppy or CD. MBRTool is probably the easier to use of these two DOS programs. When giving the backup file a name (using MBRTool) don't attempt to give it any file extension. This will be done automatically by the program and helps to identify the HDD in question. Thus it uses .128 for the first HDD and .129 for the second and so on. This also helps to avoid overwriting the wrong drive when restoring the MBR from the file. One caution about saving data to floppy diskettes is that they are not safe places for important data. Diskettes easily become corrupt/inaccessible and so the back-up files should be copied somewhere else to be properly secure.

It is also possible to run Linux from a floppy and TomsRtBt Tiny Linux is one such example. We have found one important llimitation with its hardware support since we have only been able to identify the floppy drive and internal IDE drives with it. USB and SATA drives have not, in our hands, been identifiable on it. Once the kernel has loaded the Linux boot floppy can be removed and a FAT formatted floppy inserted in its place. This can be mounted and the MBR backup of any IDE drive then made into that mounted folder - or in other words onto the FAT floppy diskette. The next sections deal with how to use fdisk, cd, ls, mkdir and mount along with the dd command to create and restore MBR backup files.

The Linux dd utility

The dd program is found on just about every Linux distro and there is information on its use at the bottom of this page. It enables the copying of blocks of data to and from block devices such as floppy and hard drives. All done from a command prompt. In plain English the command is  "dd  <input path> <output path> <block size> <count of blocks>". The last two parameters for an MBR are always bs=512 and count=1 respectively. When making the MBR backup, the input path will be the hard drive device in question and the output path will be the path to the backup file stored in a newly created and mounted folder. When restoring the MBR the input path and output path are simply reversed. We reititerate, for those new to Linux, that case always matters. Here - just about all the commands are lower case. The Linux version of fdisk as well as dd and other commands that we will use do need root or super user access. Most Live CDs and Live Floppies will set one up as root by default so this is unlikely to be a problem in the way we are doing things in these examples. If a command doesn't work as expected the same command can always be prefixed with sudo to give one-off root privilege. If a password is needed it will be requested after the command has been entered. For example if fdisk -l provides no output try sudo fdisk -l in its place.

Identifying Hard Drives from Linux

At a command prompt (indicated here by #) enter the following fdisk command, noting that -l is lower case -L. Using fdisk -l -u is very similar:

# fdisk -l 

Identified devices will all start with the word Disk followed by its Linux Device ID followed by details about the device and the way it has been partitioned. The Linux Device ID is written with the format /dev/hda for the master device on the first IDE channel (/dev/hdb for the next device and so on). Any partitions have a suffixed number at the end of the Device ID. So one might see hda1, hda2, etc for the partitions inside /dev/hda. SATA, SCSI and USB devices normlly start with the letter S and not the letter H. Thus these might appear as /dev/sda, /dev/sdb, etc. and sda1, sda2, etc for the partitions inside /dev/sda.

Fig 1.

Fig 1 shows some output from fdisk and dd_rescue in Knoppix. In the example shown two hard drives are identified. /dev/hdb (the slave IDE drive on channel #1) and /dev/sda (the first and only SATA hard drive in the system). It can additionally be seen that /dev/hdb has five partitions and /dev/sda has only one.

The first thing to memorise or write down is the Device ID of the hard drive, whose MBR one is interested-in, having identified it in the list of devices shown by fdisk -l. If using an external USB hard drive or pen drive you should insert it at this point. Some distros will auto-mount them but we will address mounting in the next section. Then re-run fdisk -l and the newly inserted USB drive should now be identifiable.

Mounting the relevant partition in Linux

In Linux, a partition's file system must first be "mounted" in an empty folder before the files in it can be accessed in any way whatsoever. To keep things simple we are going to suggest that any backup partitions are FAT partitions, which should make all the partitions normally writable once mounted. There is a bit of a quirk when using Knoppix but most of the distros mentioned here will not need any special access permissions to be applied on mounting FAT partitions.

Looking at a command prompt is a bit daunting to the Linux newbie so the first thing is to be able to view and move around the file system. Just enter ls to list the contents of any current dirctory. One uses cd (change directory) to move around. Thus cd / moves to top of the directory tree and cd /mnt moves to the mnt folder.

Since a new empty directory is going to be needed in which to mount the backup location this could be done now. Enter mkdir /mnt/aaa to make directory (mkdir) aaa inside the mnt directory. Now cd /mnt to change the current location to the mnt directory and then ls to see its contents. The newly created aaa folder should now show-up in the list. This folder is a sort of virtual folder/placeholder in a RAMdisk created by a Live CD and doesn't persist after the distro is shut down.

If using a flash memory or thumb drive then the backup partition ID is probably /dev/sda1 or /dev/sdb1 and if it is a floppy it will be /dev/fd0. Next make this accessible by mounting it in your newly created aaa folder. Enter the following command to mount the partition:

mount /dev/sda1 /mnt/aaa

You should obviously have edited /dev/sda1 and /mnt/aaa as necessary in the above line. If all went according to plan you should now be able to move to the aaa folder by cd /mnt/aaa and ls should now show not an empty folder but the contents of /dev/sda1 (in the above example). Just to make the point clearer; one cannot access a partition's files as a block device but one can access them when the same partiton has been mounted in folder somewhere in the file system's hierachy. The path to a device and the path to a mounted partition are two very separate things.

Using a Linux Distro to make and restore a backup of the MBR using dd

The previous three paragraphs may have looked a bit complicated but in essence there is not very much to using dd in most Linux Distros. We will now give examples by using the command line version of Puppy Linux because it is a small download (<30MB) and loads very quickly from the boot CD. We have used the One Bone 2.01 distro for our example but you shouldn't need to modify very much with other distros, once you get the hang of identifying devices and mounting them as required:

(A similar method is shown on another of our pages using a Knoppix Live CD).

1. Download One Bone and burn the iso image to a CD and boot to it.
2. Hit q (or Esc and exit the menu at the top of the screen) to exit to a command prompt.
3. Identify the relevant hard drive with fdisk -l
4. Insert a floppy diskette or pen drive and, if the latter, re-run fdisk -l to identify a USB drive partition
   
5. Create a mountable directory with mkdir /mnt/aaa
6. Mount the floppy or pen drive with mount /dev/fd0 /mnt/aaa or mount /dev/sda1 /mnt/aaa or whatever is appropriate
7. You may get some confusing lines of text but next move to the mounted folder with cd /mnt/aaa and then ls to see if the contents of the medium are visible.
8. Now you should be able to backup (editing the line appropriately) with:
9. dd if=/dev/hda of=/mnt/aaa/mbr.bin bs=512 count=1
   
10. Or restore with:
11. dd if=/mnt/aaa/mbr.bin of=/dev/hda bs=512 count=1
    

NB It is hardly going to be dangerous to copy a 512 byte file to the wrong directory but do be absolutely sure that you restore to the correct hard drive's MBR. If in doubt about restoration then desist and ask for help. Please read our site disclaimer regardless of what you do. Practicing on an old hard drive prevents a lot of head-scratching and heart-ache later on. We have called this binary file mbr.bin but its name is actually not at all important as long as it allows you to correctly identify it. You might like to identify the hard drive by calling it say mbrhda.bin or by when it was created by calling it say mbr080525.bin.