Re: [CentOS] backup server..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, 2006-09-14 at 05:48 -0700, TimJowers@xxxxxxxxx wrote:
>    Maybe someone can clear up the grub conf for me. Has anyone gotten this to
> work: two IDE/ATA drivers. Slave is a spare duplicate of the master. Goal is to
> be able to boot to Spare at any time and run it instead. What step am I
> missing?

Sweat, hard work, in-depth reading and testing? I had this implemented
95% (was adding routines to automatically skip compression of
ISOs, .gz, ...) when the MOBO did a "belly up" on me. The stuff is
laying around on different disks in different machines ATM.

When I get it reconstructed and finalized, I'll be glad to share with
the list. For now, here's what I remember (I'm not looking at code, so
you'll need to consider my memory was the second thing to go as I got
older).

Here is a synopsis of my recollections.
 - Can't have two volume groups named the same. This has implications.
 - Set up fstab to mount /dev/root instead of VolGroup00/... or -L ...
 - Initrd has two "ignorelockingfailure" directives in the init script.
   Adjust one to include the new volgroup(s) you may define.
 - For carrying to new systems and installing (if not the boot disk?),
   use "export" and "import" commands. Life will be easier.
 - If you must carry data from a crashed system to an active one (you
   were not able to "export") you may need to do some "renames" and
   such on the receiving system. Can't have duplicate names (maj/minor
   node carried on pv?) in a system.
 - VG and LV names can be whatever you want. They don't have to be Vol*.
   This can make it easier to setup fall-back positions. My 2nd HD has
   VolGroupAA, ...AB, etc. LV names can be lvol0, lvol1, UsersHome or
   whatever.
 - The physical volume relates to a major/minor node number on the
   originating system. Apparently (not confirmed) the pv metadata has
   some record or relationship of this (so that the same vg/lv normally
   gets the same node. Conflicts are possible as HDs are moved into
   other systems, hence the need for "export" and "import" in normal
   conditions.
 - Using snapshot volumes, you can safely and effectively backup
   live data. "Nice" can control the impact on any active users ATM.
 - I did a "grub-install" on both disks and also set the grub config
   file on each disk to allow access and "rooting" on both hd0 and hd1.
 - If backup is current, this even allows for successful boot and
   operations even when HD has not failed, but file system corruption
   has made "production" version unusable. Just use the edit ability in
   the grub boot menu to respecify the root or go to run level {1,2,3}
   to adjust an fstab if the spoiled FS is, e.g. /home and then telinit
   to run level X.
 - I could test basic operations by changing boot sequence in BIOS. I do
   not know if this holds when a HD fails (haven't tested to see if BIOS
   still reassigns 0x81->0x80, 0x82->0x81, ... as it used to. This would
   affect what you put in grub's conf file.). IIRC, it *seems* that
   reassignment does *not* happen when the boot sequence is changed, but
   it used to occur, using LILO. Haven't investigated fully.

> <snip>

HTH
--
Bill

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux