[GLLUG] boot strap
Keyes, Randall
randall.keyes at jnli.com
Tue May 10 08:50:20 EDT 2005
While it won't help with this particular situation, and I realize it's
probably an unrealistic option for smaller shops, IBM's Tivoli Storage
Manager is an awesome tool for backup/restore and archive/retrieve. I've
used it to bring back entire NT4/W2K boxes to new hardware and also on
another occasion to bring back an entire Linux partition. If you're a
medium to large shop, you might want to at least consider it as a future
option.
Randy Keyes
randall.keyes at jnli.com
517-367-3976
-----Original Message-----
From: tk3000 [mailto:tk3000 at comcast.net]
Sent: Monday, May 09, 2005 6:38 PM
To: STeve Andre'
Cc: linux-user at egr.msu.edu
Subject: Re: [GLLUG] boot strap
On Tuesday 10 May 2005 01:53 am, STeve Andre' wrote:
> On Monday 09 May 2005 17:34, tk3000 wrote:
> > Hello,
> >
> > I was in the process of doing backups of my hds in the form of images.
> > But I am in doubt with respect to the area of the hd corresponding to
> > the boot code/strap; I am extracting the boot code and partition table
> > separately, which, for the boot strap, would be something like:
> >
> > A) dd if=/dev/hda of=/mnt/backup.MBRBOOTSTRAPONLY bs=446 count=1
> > or
> > B) dd if=/dev/hda of=/mnt/backup.MBRBOOTSTRAPONLY bs=448 count=1
> >
> > So, my question is: which is the correct, or more correct; or if the 2
> > bytes are irrelevant (being one of those reserved areas defined at the
> > time the xt was launched, and never being used...). I have some sources
> > that indicate 446 and others that indicate 448; so, I am not quite sure.
> >
> > Thanks in advance,
> > Pedro Wald
>
> I can't speak to the byte specifics of your machine and OS, but the
classic
> bootstrap loader is 446 bytes. However, it isn't at the beginning of the
> disk, is it? Regardless of that, there is the partition table in general
> to think of. I'd make sure I have the software to create a new set of
> partitions, and know the sizes of everything on the disk, rather than make
> an image backup of it. Know how to create it and you can always do that.
> Make an image and you may (will?) have problems using it anywhere else.
> For backups, I prefer good old plain stupid tar. You can then move things
> to a new disk and extract what you want, etc.
>
> --STeve Andre'
I understand that it can be problematic to restore. tar is great tool, but
star has more features (maybe modern distribuitions have tar as an
alias to star; but I am just guessing). For me image is a good approach for
fast and complete recovery but I am not relying only on images, I thinking
that having a multitude of backup strategies can be handy. I believe that
the main issue of recovery is the size of the partition, I understand (but
I am not quite sure...) that the key is to define partition sizes using
cylinders rather than bytes (fdisk, by default, shows the partition and
allows you to define the partition in terms of bytes). My system is a x86,
so
the MBR is located at the very beginning of the disk. For most part the
bootstrap is pretty generic, but in some circumstances it can be helpfull
to have a separate backup. Maybe/sometimes the most problematic part is
having
to backup and restore logical partitions on extended partitions. tar has
more
options and is more flexible when dealing with file objects than dd; but in
my case I have different boot managers even in different boot sectors all
over my partition arrangement, so having images can be helpfull too.
Well, I will take the 446 as the right one. Thks!
Pedro Wald
--
Knowledge is the power and currency of the virtual world we inhabit. -Bil
Idol
On reiserfs we trust.
K7VTA Pro, Athlon XP 1.7MGhz+, Via Chipset, 256 ram,80 gigs.
Slackware 10 + kernel 2.6.11.8
_______________________________________________
linux-user mailing list
linux-user at egr.msu.edu
http://www.egr.msu.edu/mailman/listinfo/linux-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.egr.msu.edu/mailman-archives/linux-user/attachments/20050510/2bd6242e/attachment.htm
More information about the linux-user
mailing list