[GLLUG] boot strap

[Keyes, Randall]

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