MBR Backup
Quick Start:- Directly download and unzip MBRwiz.zip (for the
NT-based Windows 2000/XP/PE/2003/Vista) or MBRwizD.zip (for DOS
or the DOS-based Windows 9x/ME). Copy the unzipped exe to the C: drive
(we only suggest this position for ease of access later but if you are happy
with command prompts then use any place you like). MBRWizard's Homepage
has more information on its use. Ensure you know
how to choose the correct drive if you have multiple hard drives.
To do the backup from Windows, open a Command Prompt (MS-DOS or NT)
from the Accessories Folder reached from the Start Button; (NB if
using Vista you must Right Click on the Command Prompt Icon and then choose "Run
as Administrator"). Assuming you copied the file to the root of the C:
drive, as suggested, at the Command Prompt enter
C:\mbrwiz /Save=C:\mbr.bin
(or
C:\mbrwizD /Save=C:\mbr.bin for the DOS/Win9x version). Next ensure that you
copy the mbr.bin file to some external medium such as a USB Flash
Memory or Thumb drive or
a floppy diskette for safe-keeping along with a copy of the mbrwizD.exe file so that you can run the program even when you cannot get into windows.
To use the program from a Startup Diskette you will need to have added the
unzipped mbrwizD.exe file to the floppy and at
the floppy's A:>\ prompt enter
mbrwizD /Save=mbr.bin
and that should be
that. Use mbrwizD /? to see all the switches; switches which include choosing one out of multiple hard drives and the equivalent restore option.
To use the program from a Windows interface running on a BartPE Live
CD see our TinyHexer and BartPE page.
Note: we have suggested calling
this 512byte binary file mbr.bin but it can be called just about
anything different if one so chooses.
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 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).
- Download One Bone and burn the iso image to a CD and boot to it.
- Hit q (or Esc and exit the menu at the top of the screen) to exit to a command prompt.
- Identify the relevant hard drive with fdisk -l
- Insert a floppy diskette or pen drive and, if the latter, re-run
fdisk -l to identify a USB drive partition
- Create a mountable directory with mkdir /mnt/aaa
- Mount the floppy or pen drive with mount /dev/fd0 /mnt/aaa or mount /dev/sda1 /mnt/aaa or whatever is appropriate
- 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.
- Now you should be able to backup (editing the line appropriately) with:
- dd if=/dev/hda of=/mnt/aaa/mbr.bin bs=512 count=1
- Or restore with:
- 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.