How to back up your Master Boot Record (MBR): fail to prepare or prepare to fail

Short URL:


Backup, like security, is a well-worn mantra in the world of GNU/Linux—and even the most battle-hardened, street-wise user has, for whatever reason, thought about regular backups after disaster has already struck. It is an all too familiar story. System Administrators, by the very nature of their work, will have that imperative carved on their headstones. For them it will be a way of life. Desktop users, being responsible only for themselves, can afford to be a little more louche about such things. If it all goes a bit “arms in the air" there is no one to reproach them but themselves.

You should backup many things: the files in your home directory, configurations files in /etc, (and there are many excellent graphical tools to do the job) but one of the simplest and best things you can do is to backup your boot master boot record (MBR). It’s one thing to experience lost or corrupted files, it’s quite another not to be able to bootup your computer at all. What follows may just get you out of a fix.

Windows manners

It is highly unlikely that you came to GNU/Linux as a computing virgin. You almost certainly, like me, came via Windows and therefore either installed over it or decided to attempt to dual boot. Like Bill and Steve, Windows is a bit short on computing etiquette and if you installed GNU/Linux first on a blank hard drive and then followed up with an installation of some version of Windows you will have made a painful discovery. Windows will, without so much as a by-your-leave, stamp all over your GNU/Linux boot sector with great big hobnail boots. The first lesson is to install Windows first.

However, you don’t need to be dual booting with Windows to court disaster. Dual booting with several versions of GNU/Linux can lead to boot problems too. At best, only one version will boot—or worse, none and you may find yourself googling furiously to understand terse and cryptic GRUB error messages. Sometimes, boot sectors (including partition tables) can just get corrupted for no discernable reason at all. Whatever the reason, you need to prepare for all eventualities as GRUB (GRand Universal Bootloader) does not make a copy of the MBR during installation.

Backing up

The MBR, as I will refer to it hereafter, is a 512 byte segment on the very first sector of your hard drive composed of three parts: 1) the boot code which is 446 bytes long, 2) the partiton table which is 64 btyes long, and 3) the boot code signature which is 2 bytes long. These numbers are VERY important. Any careless or impulsive fingering at the keyboard of these numbers could well render your machine unbootable or the partition table unreadable. The sight of a grown man crying is not pretty. You have been warned!

The core of the backup command is dd—which will be familiar to every system administrator, especially to those who intend to clone an entire hard disk. To see all the options type man dd. As we want to back up only the first 512 bytes we need to append some agruments to it. Here is the full command you need (and remember to run it as the root user, su (and sudo for Ubuntu users):

dd if=/dev/hda of=/home/richmondg/mbr_backup bs=512 count=1

Obviously, you will need to substitute the partition where your boot sector resides and also use your own username. Now let’s see just what we did there. dd just stands for disk dump, if means input file, of means output file, bs simply means bytes and count=1 tells the command to do this just once. It makes sense to save this out to some removable device, usually a USB stick, in which case amend the file path to suit so that /home/richmondg/mbr_backup reads, say, /dev/sda/mbr_backup or just copy the original backup to the external device.

Or, only copy the first 446 bytes. Why?

This could be a useful tip. If you change 512 to 446 in the above command you will only save the boot sector, but not the partition table. Why would you want to do that? The reason is that if you use 512 bytes and subsequently amend your partitons for any reason and then restore the MBR it will be out of sync. So, ensure that if you have made any partiton changes since your original MBR backup that you update that backup.

Restoring the MBR

Not surprisingly, in order to restore the MBR it is only necessary to reverse that original command which saved it. If you managed to hose the MBR you will not be able to boot up, so you can use a live CD to access your hard drive and read the backup off any removable media such as a USB stick. Here is the command:

dd if=/dev/sda/mbr_backup of=/dev/hda bs=512 count=1

Again, amend sda to read where you saved the MBR and run the command as root. If you wish to kill the MBR altogether, including the partition table, then you can overwrite it with a series of zeros:

dd if=/dev/zero of=/dev/hda bs=512 count=1

If you want to kill the MBR but leave the partition table intact then simply change 512 to 446.

There are, of course, alternatives which involve using your install CD in rescue mode to reinstall GRUB which will have the same effect (with the added advantage of not overwriting the partition table) but that is another topic in its own right. In the meantime, using the dd command with arguments will help familiarise you with other linux commands and the file structure. Mastery of the command line is a learning curve but one that can repay huge dividends when things go wrong.



Lawrence D'Oliveiro's picture
Submitted by Lawrence D'Oliveiro (not verified) on

The trouble with backing up the entire boot sector is that, if you need to restore it, it will wipe out the bootloader in the process. Not good. Instead, do something like this:

sfdisk -d /dev/sda >sda-partitions.txt

This dumps the partition table only, not the boot code. Then you can restore it with

sfdisk /dev/sda

Of course, make sure sda-partitions.txt is saved somewhere other than on the disk whose boot sector it is. :)

clievers's picture
Submitted by clievers on

This is a great idea. I'm going to do this tonight on my two Ubuntu boxes. Actually, I guess I could do this on my Windows box too? The MBR is the MBR. Backing up is gooooooodddddd.
Thank you.
let's all play nice!

skypjack's picture
Submitted by skypjack on

This is a good idea and a good article!
Until now, I've used a grub disk (floppy disk) to recover from MBR disaster. Logging into my unreachable Linux system from grub shell, then I can restore the MBR without problems.
However, this is a good tip to save my time.

ErnieDV's picture
Submitted by ErnieDV on

This is a very timely tip. I'm about to try Linux on my Dell E310 system. Given that this is one of those systems where the only way you can restore Windows is by restoring the entire system from the special partition, I've been very nervous about making a lot of work for myself in case it all goes horribly wrong. Using a live CD to do this before hand and saving to a USB stick is a great safety net.

FXEF's picture
Submitted by FXEF (not verified) on

This is question, not a suggestion. I have read that when using dd that all drives or partitions should be unmounted. Is this the case with your use of dd?

Sukarn Maini's picture
Submitted by Sukarn Maini (not verified) on

No, you do not need to unmount your partitions to backup your mbr using this command.

However, I don't know about the need to unmount for restoring the mbr.

tk3000's picture
Submitted by tk3000 on

Only a small correction (the original poster probably forgot to complete the line). In order to recover the partition table one would have to redirect the file containing the partition table backup, as follows:

sfdisk /dev/sda < sda-partitions.txt

which will then recover the last partition table backed up with:

sfdisk -d /dev/sda > sda-partitions.txt

Author information

Gary Richmond's picture


A retired but passionate user of free and open source for nearly ten years, novice Python programmer, Ubuntu user, musical wanabee when "playing" piano and guitar. When not torturing musical instruments, rumoured to be translating Vogon poetry into Swahili.