[GLLUG] boot strap

Tue May 10 21:13:13 EDT 2005

On Tuesday 10 May 2005 06:10 pm, STeve Andre' wrote:
> On Monday 09 May 2005 18:37, tk3000 wrote:
> > 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
>
> Never confuse more features with a program being better; I think I could
> make the case that most programs that have successive versions with "more
> features" are train wrecks in terms of how to use them, and what they do. 
> This is not to say that software should not evolve, but one should always
> critical eye towards "improvements".
>
I agree. I mentioned the star because on occation I had a situation when the 
star did the job that tar was unable to perfor by itself; but it certainly, 
does not mean that one is better than another on each possible 
appicability; but based on what I have read star is a superset of tar, which 
does not mean that a more feature featured tool is necessary better, better 
performer, more stable, etc. Plus, you are in a so far better position to 
comment about them, since I have no development experience whatsoever with 
such tools and type of tools.

I understand that bit-by-bit copy of a volume has more issues than a 
conventional backup, such as being much more susceptible to massive 
failure in case of the corruption of the image, and the test also requires 
another partition in order to reproduce to copy, partition size (I am assuming 
equal or bigger partitions). In case of partial and identifiable recovery of 
files the imaging of volumes is totally counterproductive and inadequate.

Ok, let me see... I have a bunch of partitions including primary, extended and 
logical part.; some of my logical part. are bootable (via grub+lilo; 
chainloading). Plus, I have w2k installed; and as far as I know wk2 has many 
issues with respect to the physical position and disposition of system and 
other sensitive files on disk; and I also happened to use Junctions 
(juinctions are homologous to sym link) within my ntfs partitions, I haven't 
investigate but I don't know how tar would deal with junctions and 
permissions/owership of file on ntfs... I haven't tried to backup and/or 
recover a ntfs part. with tar, but it looks like a receipt for disaster 
(there may be a way, but maybe too much work and prone to error). I have a 
couple of bootable dvds (with tomsrtbt image, el torito) with all my backup; 
in a case of a disaster, I just insert them to recover everything to a former 
estate with dd.

Well, I did not mention the ntfs before... But with such simple unified 
approach I know that I can restitute my system to a previous state with 
minimum loss and effort in case of a massive failure of my hd for instance.

But, that is not and can not be the only approach by any means in a recovery 
and disaster situation. Conventional backup (such as  full and increm.), or 
even simple copies of files and directorey trees are the best solution for 
most situations. And most likely, in most disaster scenarios, it will be much 
more helpfull to have a conventional backup rather than images for a series 
of reasons (such as files recovery, partial recovery and the recoverability 
process itself). So, bottom line, I am intending to use both of them; and I 
am already using both in some degree.

Pedro Wald

> What I am trying to figure out is why you want to do the image save.  I'm
> thinking back to a time when I helped write such software and those
> experiences taught me that it isn't worth it.  What happens is part of the
> image save is damaged?  What happens if you the partition you are restoring
> onto is accidently too small?  These are real world things that I have seen
> rise up and nip people in their rear ends...
>
> In terms of experimentation its a good thing to do.  I just hope you don't
> rely on any form of backup where atomic elements (ie, files) can't be
> individually restored.
>
> --STeve Andre'
> _______________________________________________
> linux-user mailing list
> linux-user at egr.msu.edu
> http://www.egr.msu.edu/mailman/listinfo/linux-user

-- 
Knowledge is the power and currency of the virtual world 
inhabit. -Bil Idol