How to backup MBR/ GRUB ? (Dual-boot Linux & Win XP)
JayLinux53
HD's - one for each OS, as below.
HD 1 - Windows XP (IDE HD)
HD 2 - openSUSE 11.1 (SATA HD)
GRUB is used as the bootloader and is located on MBR (HD 1). I can
properly boot into oS 11.1 and Windows XP.
Now, I would like to make a backup of the MBR (& GRUB, if necessary),
so that I can restore it if there is a problem.
How do I make an MBR Backup and also, how does one restore it, if
there is a problem later ?
Thanks,
Jay
==
J.O. Aho
As you don't seem to like google, I guess someone else has to make the search
for you and post the link here:
http://ubuntu.wordpress.com/2005/10/20/backing-up-the-mbr/
IMHO it's as simple to just boot a rescue CD and reinstall grub.
--
//Aho
Bit Twister
> so that I can restore grub MBR if there is a problem.
I just boot a rescue cd,
mkdir /junk
mount -t -auto /dev/sdXy /junk (you solve for Xy)
chroot /junk grub-install /dev/sda
grub-install /dev/sda
Bit Twister
>
> so that I can restore grub MBR if there is a problem.
Opps, much better here.
habibielwa7id
Very easy man using Linux dd from rescue mode or within Linux,
Check what is mbr you installed your boot loader in, hda, sda or sdb.
suppose it's sda,
dd if=/dev/sda of=/root/mbr.img bs=512 count=1
Then you may check the new mbr file
file /root/mbr.img
From a modern Linux distro that uses new version of "file" command
like Fedora 10 the "file" command will also tell you info about the
partitions inside that mbr.
to restore it just reverse like,
dd of=/dev/sda if=/root/mbr.img bs=512 count=1
Be careful doing things like that, You may cause problems if you miss
something when typing.
Regards,
Bit Twister
> Very easy man using Linux dd from rescue mode or within Linux,
> Check what is mbr you installed your boot loader in, hda, sda or sdb.
> suppose it's sda,
> dd if=/dev/sda of=/root/mbr.img bs=512 count=1
I thought the boot loader was bs=1 count=446 if using
bs=512 count=1 you also picked up the partition table.
Bryce
You're right ... but the partition table is the jelly in the
doughnut: the best part!
David W. Hodgins
> From a modern Linux distro that uses new version of "file" command
> like Fedora 10 the "file" command will also tell you info about the
> partitions inside that mbr.
For others reading this, that were not aware of this, Running "file -s /dev/sda"
will show you the partition table. "file -ks /dev/sda" will also show you if lilo
is installed. Doesn't recognize the GAG boot manager. Haven't tried it with
grub.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Mark Madsen
> On Thu, 19 Feb 2009 07:36:53 -0500, habibielwa7id <foua...@gmail.com>
> wrote:
>
>> From a modern Linux distro that uses new version of "file" command like
>> Fedora 10 the "file" command will also tell you info about the
>> partitions inside that mbr.
>
> For others reading this, that were not aware of this, Running "file -s
> /dev/sda" will show you the partition table. "file -ks /dev/sda" will
> also show you if lilo is installed. Doesn't recognize the GAG boot
> manager. Haven't tried it with grub.
With GRUB in /dev/sda2 I get
blackbox:/home/msm# file -ks /dev/sda2
/dev/sda2: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3,
1st sector stage2 0x21d626e\012- Linux\012- rev 1\012- .0\012- ext3
filesystem data\012- , UUID=814447d3\012- -98d9\012- -470d\012- -ac32
\012- -d9af1cb0\012- c888\012- \012- (large files)
...so I guess it can recognise GRUB too.
jaylinux53
> > I thought the boot loader was bs=1 count=446 if using
> > bs=512 count=1 you also picked up the partition table.
>
> You're right ... but the partition table is the jelly in the
> doughnut: the best part!
What is the significance of backing up the Partition Table also
(bs=512)?
Should I backup & restore bs=512 (MBR + Partition Table) OR bs=446
(MBR only). Most Google-search posts mention bs=512 for backing up the
MBR.
Any practical experience with either of the above options, in
restoring an MBR backup ?
Jay
==
ray
Factors: if the partition table becomes corrupt with the MBR, then 512
would obviously restore both. If you change the partitioning after
backing up 512 then a restore would put your system in a corrupted state.
i.e. there are occasions when each one would be beneficial. I would
suggest if you go this route to do both. I generally don't bother - it's
really quite easy to rewrite the MBR with a Live CD.
David W. Hodgins
> Should I backup & restore bs=512 (MBR + Partition Table) OR bs=446
> (MBR only). Most Google-search posts mention bs=512 for backing up the
> MBR.
If you make changes to the partition table in between the backup and restore,
you'll have problems using all 512 bytes.
Either backup/restore only the first 446 bytes, or ensure you update your backup
anytime you change the master partition table.
Bryce
Ray is right: it's easy to re-create the bootrecord (first 446 bytes)
using a rescue CD. Tools like cfdisk or gparted make it easy enough
to create or modify a partition table as well.
I back up the whole 512 bytes, mostly to have a snapshot the partition
table. If the PT on your drive gets damaged, the data on that drive
becomes unavailable. Fixing the PT without a copy is tricky.
habibielwa7id
-Yes, I think so. "Fixing the PT without a copy is tricky"
Although I read about many tools that can scan the hard disk and make
new MBR with valid data, But I have not tried it yet, May because I
always do many backups for my systems.
habibielwa7id
-If you want to backup and restore only the partition, table you may
use sfdisk , It has 2 options to backup and restore only the
partition table,
-As aside note:
I advice you to learn how to use dd with it's amazing capabilities,
I remember 1 of my friends had an image for Vmware host, And wanted
it to be larger, May be because he wanted more free space inside it,
He was able to stretch it using dd,
- You may take images as backups for your servers hard disks across
the network using dd in integration with ssh and gzip like this,
dd if=/dev/sda conv=sync,noerror | gzip -c | ssh ro...@192.168.1.2 "dd
of=/root/backup/mail_backup/sda_gz.img"
and restore it like this, Plug a hard disk to your workstation and
copy the compressed image to it not compressed like this,
dd if=/root/backup/mail_backup/sda_gz.img | gunzip -c | dd of=/dev/sdb
I almost don't install Linux from the beginning from some time, when
the company I work for ask me to setup a new server, I copy from the
servers that are running the boatloader, The partition table, And the
partistions I need for the new server and make the new server's hard
disk in just 2 hours may be, If I will install every thing from the
beginning, it will take may be many days to reach agood point.
Regards,
Van Chocstraw
Get the GAG utility and burn it to CD. it's a graphical boot manager.
You can boot your system and use the boot loader program on your system
to fix the mbr.
An ever better utility is Super Grub, a bootable CD to boot into your
system when boot sector is trashed. I keep a copy handy just in case. I
have used it in the past and it saved me.
--
<<//--------------------\\>>
Van Chocstraw
>>\\--------------------//<<
bb
>....
> dd if=/dev/sda conv=sync,noerror | gzip -c | ssh ro...@192.168.1.2 "dd
> of=/root/backup/mail_backup/sda_gz.img"
As I often write when someone come up with this dd imaging ,
it's bad, since you have a long time from where you copy the superblock
to when you copy the last data, much can happen on the disk, a file can
have data in a block that was used for something else when you started.
In short, you don't know if your files is ok.
What do work is:
cd somewhere_under_the_mountpoint
dd if=/dev/zero of=bigfile || rm bigfile # zero free blocks
cd -
sync
mount -o remount,ro <partition>
do your dd
mount -o remount,rw <partition>
The bad thing is that a system may hang after remount,ro depending on which
filesystem and what's going on.
Better to use partimage or any ghost clone for linux,
using a rescue disk, and you are safe.
I sometimes do dd if=/dev/sda bs=1 count=446 > MBR
and dd if=/dev/sda bs=1 skip=446 count=16 > PARTS
But the time to restore them
(concat one MBR with one PART and dd back to the first block)
take even more time then grub-install, so it's just to
have plan B in case of disasters.
/bb
habibielwa7id
> On 2009-02-22 10:13, habibielwa7id wrote:
>
> >....
> > of=/root/backup/mail_backup/sda_gz.img"
> > ....
>
> As I often write when someone come up with this dd imaging ,
> it's bad, since you have a long time from where you copy the superblock
> to when you copy the last data, much can happen on the disk, a file can
> have data in a block that was used for something else when you started.
> In short, you don't know if your files is ok.
have to be changed but rarely, And most of the data on the servers I
have, doesn't changed but rarely, So I have another copy from all the
files on all my hard disks I take regularly with some thing like,
tar --ignore-failed-read --exclude=/home --exclude=/proc --exclude=/
tmp --exclude=/sys --exclude=/dev -pzcvf root_ftp.tar.gz / 2>>
error.log
For example what may be changed on the mail server?, Only the mailbox,
Which I have a separate backup taking regularly with another methods
like rsync, So if I want to make another copy from the mail server,
after I make the new hard disk with dd I boot it then I restore my
last copy of the mail box, And may the new server will be used by
another company, So there is no need for the mailbox, I just change
the ips and some config files so it suites the new environment, This
really better that installing every thing from the beginning,
I remember last month a customer ordered a new server to use it as a
gateway, with Squid, Load balancing with two wan lines, Delay pools,
QOS, Vnc ,Ntop And many other tools, I copied the image from a
another server which I took along time to configure all of these tools
in it, and gave the customer the server he needs while he was setting
beside me in just 2 or 3 hours, "Oh my god" if I will have to
configure all of these tools from the begging, It will take may be
more than a week of a continues work. So I just advised them to do
like this when they may be in the same situation.
> What do work is:
>
> cd somewhere_under_the_mountpoint
> dd if=/dev/zero of=bigfile || rm bigfile # zero free blocks
> cd -
>
> sync
> mount -o remount,ro <partition>
>
> do your dd
> mount -o remount,rw <partition>
-I will try to learn something from this,
> I sometimes do dd if=/dev/sda bs=1 count=446 > MBR
> and dd if=/dev/sda bs=1 skip=446 count=16 > PARTS
-Are you sure that using dd without the "of=" option is save?
count=16 ? I think you meant 64 which is the partition table. Or 66
which is the partition table besides the magic number.
> But the time to restore them
> (concat one MBR with one PART and dd back to the first block)
> take even more time then grub-install, so it's just to
> have plan B in case of disasters.
>
> /bb
Yes of course, But this if he wants to restore the boat loader only,
May he wants to restore the whole MBR as some times some stupid tools
especially on Windows destroy it, And as I know some viruses on
Windows may destroy the whole MBR.
Regards,
Jasen Betts
> Ray is right: it's easy to re-create the bootrecord (first 446 bytes)
> using a rescue CD. Tools like cfdisk or gparted make it easy enough
> to create or modify a partition table as well.
>
> I back up the whole 512 bytes, mostly to have a snapshot the partition
> table. If the PT on your drive gets damaged, the data on that drive
> becomes unavailable. Fixing the PT without a copy is tricky.
have you ever tried "gpart"
Bryce
No, I haven't ... but only because I have always had an MBR copy around.
gpart would be Plan B, and it is among the tools in the SystemRescueCD
that have saved me many times.
gpart's man page includes this under PRECAUTIONS:
gpart may be of some help when the primary partition table was lost or
destroyed but it can under NO circumstances replace proper disk/parti-
tion table backups. To save the master boot record (MBR) including the
primary partition table to a file type
dd if=/dev/hda of=mbr bs=512 count=1
...
Jasen Betts
> Jasen Betts wrote:
>
>>
>>> Ray is right: it's easy to re-create the bootrecord (first 446 bytes)
>>> using a rescue CD. Tools like cfdisk or gparted make it easy enough
>>> to create or modify a partition table as well.
>>>
>>> I back up the whole 512 bytes, mostly to have a snapshot the partition
>>> table. If the PT on your drive gets damaged, the data on that drive
>>> becomes unavailable. Fixing the PT without a copy is tricky.
>>
>> have you ever tried "gpart"
>
> No, I haven't ... but only because I have always had an MBR copy around.
> gpart would be Plan B, and it is among the tools in the SystemRescueCD
> that have saved me many times.
>
> gpart's man page includes this under PRECAUTIONS:
> gpart may be of some help when the primary partition table was lost or
> destroyed but it can under NO circumstances replace proper disk/parti-
> tion table backups.
yeah, they say that because it guesses what the partition table should
be. and sure knowledge (like from a backup) is better than a guess.
that said there is enough redundant information is the superblocks etc
that it can guess the partition table. if the partitions are of types
that it recognises, the partitions are formatted and the superblocks
are intact.
My comment was mainly that fixing the PT without a copy needn't be
'tricky'.
rsink
Very true, and I use this method also. BUT there is risk in everything
and here it'd be that if you repartition in-between then the said
recovery will be a hosedown. I'd suggest to all to still use all 512
bytes as you do (the entire root sector) but with caution concerning
possible oops-i-forgot's :-)
Just my 2 cents.