I have to admit, I've learned more about how Linux works by breaking it
and fixing it, than I have by any other method. There really is nothing quite
like the prospect of losing valuable data, or the idea that your only
computer won't boot, to motivate you to learn more about your system. In
this month's installment of “When Disaster Strikes”, I discuss a
surprisingly small part of your computer that plays a surprisingly large
role in booting and using it—the Master Boot Record, or MBR for short. I
cover some of my favorite ways to destroy an MBR and a few ways to
restore it once you have.

Before you can fully understand how to restore the MBR, you should have a
good idea of what it actually is. The MBR comprises the first 512 bytes of
a hard drive. Now that's bytes, not megabytes or even
kilobytes. In our terabyte age, it's hard to appreciate how very small
that is, but to give you an idea, at this point in the column, I've already
written about three MBRs worth of text.

This 512-byte space then is split up into two smaller sections. The first
446 bytes of the MBR contain the boot code—code like the first stage of
GRUB that allows you to load an operating system. The final 66 bytes
contain a 64-byte partition table and a 2-byte signature at the very end.
That partition table is full of information about the primary and extended
partitions on a disk, such as at which cylinder they start, at which
cylinder they end, what type of partition they are and other useful data
you typically don't think much about after a disk is set up—at least,
until it's gone.

A Routine Lecture on Backups

This is the part of the column where I repeat some of the best disaster
recovery advice I know—make backups. In this case, we are talking about MBR
disasters, so here are a few ways to back up your MBR. After all, it's only 512
bytes; there's no reason why you can't afford to back it up. Heck, it's
small enough to tattoo on your arm, except I guarantee once you do you'll
end up migrating to a new system or changing the partition layout.

The best tool to back up the MBR is coincidentally the best tool at
destroying it (more on that later), dd. In fact, dd is one of those
ancient, powerful and blunt UNIX tools that blindly does whatever you tell
it to, and it's adept at destroying all sorts of valuable data (more
precisely, it's adept at following your explicit orders to destroy your
valuable data). The following command backs up the MBR on the /dev/sda
disk to a file named mbr_backup:

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

Basically, this tells dd to read from /dev/sda 512 bytes at a time and
output the result into mbr_backup, but to do only one 512-byte read. Now
you can copy mbr_backup to another system or print it out and do the tattoo
thing I mentioned before. Later on, if you were to wipe out your MBR, you could restore it
(likely from some sort of rescue disk) with a slight twist on the above
command. Simply swap the input and output sources:

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

More than One Way to Skin an MBR

There are a number of elaborate ways you can destroy some or all of your
MBR. Please be careful with this first command. It actually deletes
your MBR at the very least, and with a typo, it potentially could delete the
entire disk, so step lightly. Let's start with the most blunt, dd:

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

This command basically blanks out your MBR by overwriting it with
zeros. Now, unless you are masochistic, or you are like me and used this
in a demonstration of MBR recovery tools, you probably wouldn't ever run
this command. Most people end up destroying part of their MBR in one of two
ways: mistakes with bootloaders and mistakes with fdisk or other
partitioning tools.

Mistakes with partitioning tools probably are the most common way people
break their MBRs, or more specifically, their partition tables. It could be
that you ran fdisk on sda when you meant to run it on sdb. It could be that
you just made a mistake when resizing a partition, and after a reboot, it
wouldn't mount. The important thing to keep in mind is that when you use
partitioning tools, they typically update only the partition table on the
drive. Even if you resize a drive, unless you tell a partitioning tool to
reformat the drive with a fresh filesystem, the actual data on the drive
doesn't change. All that has changed are those 64 bytes at the beginning of
the drive that say where the partitions begin and end. So, if you make a
partitioning mistake, your data is fine. You just have to reconstruct that
partition table.

It would figure that the first time I really destroyed my MBR, it was
through the second, less-common way—mistakes with bootloaders. In my
case,
it was a number of years ago, and I was struggling to get an early version
of GRUB installed on a disk. After the standard command-line commands
didn't work, I had the bright idea that maybe I could use the GRUB boot
floppy image. After all, it was 512 bytes and so was my MBR, right? Well,
it sort of worked. GRUB did appear; however, what I didn't realize was that
in addition to writing GRUB over the first 446 bytes of my MBR, I also
wrote over the last 66 bytes, my partition table. So although GRUB worked, it
didn't see any partitions on the drive.

Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.

Great article. I was trying to learn about grub and gparted and MBR recovery and multibooting. I printed out many articles, from the internet, said that grub could be reinstalled, but they did not say what to do if the MBR is actually corrupted. I then remembered Kyles column in my hardcopy mag. Kyles column clearly addresses this. Again, good reference article. Thanks.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.