[sf-lug] MBR/partition table/sfdisk/use dd to copy the mbr

[Michael Paoli]

> Date: Mon, 19 Nov 2007 21:35:32 -0800
> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [sf-lug] use dd to copy the mbr
> To: sf-lug at linuxmafia.com
>
> Quoting jim stockford (jim at well.com):
>
> > # dd if=/boot/mbr_backup of=/dev/sda bs=446 count=1
> > # # or, copy from the primary master to primary slave:
> > # dd if=/dev/hda of=/dev/hdb bs=446 count=1
> >
> > note the bs=446 rather than bs=512 lets you copy the
> > bootstrap loader code without copying the partition table
> > (if you use bs=512 you copy the partition table from the
> > source and overwrite that of the target).
>
> I frankly cannot fathom why people think the inital 446 bytes' contents
> are so valuable.  It's dead-easy to rebuild from a Linux maintenance CD
> whatever you had there.  I'd have though possessing a reference copy of
> the partition table would be more valuable.

Well, ... at least *sometimes*, backing up the MBR and/or partition
table can be highly useful or convenient ... if not downright important.

E.g. if one might not easily be able to otherwise restore the MBR as it
was, then backing it up may be highly useful.  For example, x86
hardware, at least per legacy design, can quite easily support 4
distinct and separate operating systems - with a multi-boot
configuration.  If one wants/needs to keep a particular type of MBR in
place, ... there are no guarantees that that particular MBR is easily
restored from whatever foo operating system or boot loader may be
responsible for having initially set it up.

And on backing up partition tables - I *really* like sfdisk; *however*
sfdisk can be exceedingly dangerous if one doesn't know what one is
doing (or even worse, if one doesn't, but thinks one does).  I would
*not* recommend sfdisk for systems administrators that aren't rather to
quite experienced and careful (e.g. it's real easy to type sfdisk, not
know what one's doing or feed it not precisely the correct data, and
trash one's partition table).  Nevertheless sfdisk can do some highly
cool and useful stuff.  E.g.:
* the -l and -d options can be used to output a very handy listing of
  how the partition table is configured.  If one includes the -x option
  with -l and -uS, one can really see at quite low level how all the
  partitioning details are configured.
* the -d option can be highly useful for partition table backup/restore,
  particularly when combined with -uS, as the output format with -d can
  be used as input to (re)create/restore a partition table.  (This type
  of data is also some of the metadata that my backup scripts create
  and backup early on the backup media - so it can be easily extracted
  from backup media and consulted or used quite directly in creating
  partition table prior to moving on to higher level data restore
  tasks).
* the -O and -I options are highly useful for backing up, and if need be
  restoring, partition table changes.  Note that this is highly
  superior to merely backing up the partition table - as some partition
  table changes cannot be undone and things restored on the hard drive
  as they were before the change by merely restoring the earlier
  partition table (most notably with extended partitions, one also
  alters other sectors on the hard drive; with -O and -I one can save
  and undo those changes, whereas a mere backup and restore of the
  partition table will not undo changes to data in sectors beyond that
  containing the partition table).
* if it would be a legitimate partition table, sfdisk will let you
  create it.  One can do very low level fine grain control of how the
  partition table is set up - many other partitioning utilities won't
  allow one that level of control.  It will still (at least generally?)
  prevent you from creating a partition table that wouldn't be
  legitimate at all, and by default it will also prevent one from doing
  at least some things that in general may not be a good idea.

And some random examples of where I've found backing up the partition
table, partition table and related data changes, and/or MBR to be
rather to quite useful:
* Once upon a time, initial setup of a laptop.  It included a
  proprietary OS (had to purchase it with the laptop) with a sucky
  filesystem - but one with which various open source tools well
  understood and could deal with, ... and which would get instantly
  converted into an even much suckier filesystem type - which would be
  more problematic for dealing with via open source tools - if the
  installed OS was booted (it would convert filesystem type upon
  initial boot).  I didn't want to completely get rid of that sucky OS
  (maybe I wanted the occasional reminder of how sucky it was ... and
  besides, it was already bought and paid for) ... but I sure did want
  to both shrink and relocate its filesystem/partition.  I didn't want
  to change the MBR (though I did want to configure it so that by
  default, that bootloader would chainload GRUB).  I didn't yet have
  CD/DVD burn capabilities, and other than the hard drive (which I
  didn't yet want to boot from due to aforementioned reasons), the only
  things I had available to boot from were floppy, or one single
  relatively old LinuxCare rescue CD (which while useful, was rather
  limiting - e.g. the laptop's Ethernet was far too new of hardware for
  that CD to know how to deal with).  Anyway, with careful backups
  along the way (typically to floppy, or some other "safe" area removed
  or away from stuff being changed or dependent upon stuff being
  changed), I was able to make all the manipulations and file shuffling
  and repartitioning I wanted to do, without ever booting off of the
  hard drive.  If I recall correctly, one goof somewhere along all that
  hairy manipulation process, would have been a major pain had I not
  also done that tiny little backup of critical data - so I was able to
  undo the goof, and pick up again from where I was right before I'd
  made that goof.
* hairy disk partitioning / MBR / boot loader configuration changes.
  Sometimes I do a major repartitioning of a hard drive - with the data
  mostly all in place - and with no data losses.  Careful well planned
  changes, along with use of sfdisk including -O option often make this
  a significantly more goof resistant operation (and on at least some
  rare occasions, I've had need or desire to go back a step in the
  change process - and sfdisk with -I option made that quite easy, and
  guaranteed to get me back where I was before (at least as long as I
  didn't manage to do something incredibly stupid)).  Likewise, when
  doing some major bootloader reconfigurations - involving all of some
  proprietary hardware manufacturer (pre)bootloader, the NT bootloader,
  GRUB *and* LILO ... all on the same system :-) careful backups of the
  relevant pieces being altered can be rather to quite important (and I
  may have saved myself from major issue to fix by doing such careful
  backup bits ... it was either that occasion, or some of the initial
  laptop partitioning reconfiguration where I did save myself from
  quite a mess by having a careful backup of just the right critical
  bits of data).

So, yeah, ... "nowadays" with lots of (e.g. CD/DVD) bootable operating
systems and recovery utilities, generally much more capable hardware,
and when dealing with systems that have only (or mostly) open source
operating system (e.g. Linux), MBR and bootloader installed, backing up
those critical little bits often isn't as important, as fixing such is
typically much easier now.  Nevertheless, still, having just the right
critical little bits backed up - and in a manner that they can be
usefully and properly restored, can still - at least occasionally -
save one's tail.  While merely "fixing" things, such as via some
bootable CD/DVD and reloading MBR and reconfiguring the partition table
as it was, ... may not quite fix things adequately (e.g. that may not
undo other changes on disk due to extended partition changes).

Also, for what it's worth, there's *excellent* documentation on the
details of partitioning, structure, various partition "gottchas"
(particularly with multiboot configurations, and where some other
operating systems might not fully and properly "play by the rules" as
they should), which can be found in - oddly enough - the LILO
documentation.  Anyway, best partitioning documentation I ever stumbled
across (though since I found that some years ago, there might be better
information out there somewhere else).