Operating System - HP-UX
1833756 Members
2684 Online
110063 Solutions
New Discussion

Re: Patching and mirrored root

 
SOLVED
Go to solution
Michelle Barton
Frequent Advisor

Patching and mirrored root

What is up with the search feature on itrc? Anyways, vg00 is mirrored and I want to split the mirror, apply a patch bundle and then test it while keeping the split disk in tact just in case I need to roll back. I know there are procedures, but, I can't find them.

Thanks,
Michelle
7 REPLIES 7
RAC_1
Honored Contributor

Re: Patching and mirrored root

Why break mirror?? Backup /stand/vmunix /stand/system and /stand/dlkm. Apply patches and if anything goes wrong you can boot into old kernel.

From ISL prompt,

hpux /stand/vmunix.good

Anil
There is no substitute to HARDWORK
Pete Randall
Outstanding Contributor

Re: Patching and mirrored root

Michelle,

I would tend to lean more towards an Ignite make_tape_recovery backup for fallback, but I suppose there are advantages to your proposal. Firstly you would need to lvsplit all the logical volumes in the root vg, apply the patch, then lvmerge the lvols back together. The trick will be in keeping track of which mirror is which but it shouldn't be too difficult.


Pete

Pete
A. Clay Stephenson
Acclaimed Contributor

Re: Patching and mirrored root

Backing up /stand and related files is a necessary but often not sufficient step because the patches could be far more widespread. Rather than spliting the mirrors, it makes more sense to pull the mirror gently from its hot-plug slot and let it spin down. You should have already done an lvdisplay to make sure that all extents are current on all PV's. I assume that you have also already done a mboot -a "hpux -lq ..." to enable booting without quorum on either disk.

Doing a make_tape_recovery first is also a good idea. My preferred method is to leave the drives mirrored and create a "lifeboat" by copying via dd the entire boot disk to another disk. That way, if anything goes wrong, you simply shutdown and move the lifeboat into the boot disk slot and you are back up faster than any other method. Lifeboats save you from two things that mirrors do not: 1) Really, really bad patches 2) Your old stupidity. I run lifeboats on all my boxes.
If it ain't broke, I can fix that.
Michelle Barton
Frequent Advisor

Re: Patching and mirrored root

Clay,
So, if you create a lifeboat using a dd, how do you get the data back if needed? I know this should be obvious, but I'm not getting it.

Thanks,
Michelle
Pete Randall
Outstanding Contributor

Re: Patching and mirrored root

I expect you would boot off the lifeboat and dd it back to your original (mirrored) boot disk(s).


Pete

Pete
A. Clay Stephenson
Acclaimed Contributor
Solution

Re: Patching and mirrored root

Let's take the simplest case, vg00 consists of 1 boot disk and 1 boot mirror. The lifeboat is a 3rd separate disk not in any VG. Each weekend (or before a patch installation), a script is run which does a dd from the boot disk to the lifeboat disk. I also make sure that -lq has been inserted in the boot string so that the machine can boot from only one disk. You should always do this with mirrored boot disks because unless you mkboot -a "hpux -lq ..." on both the primary and alternate disks, you actually make the machine less likely to boot because both disks have to be available otherwise. When I need to use the life, I pull the primary and alternate boot disks out of their slots and move the lifeboat to the primary slot. Power back up and the system is as it was before.
If it ain't broke, I can fix that.
Robert Bennett_3
Respected Contributor

Re: Patching and mirrored root

We do what Clay is suggesting on all our servers. We have vg00 mirrored (1 boot and one mirrored disk) and have a vg01 that is a copy of vg00 that we call our alt_root disk. vg01 is updated once a week via a script in cron.

We will routinely comment out the cron job before we update vg00 (patching and the like) so as not to introduce changes in the "lifeboat". But if we need to use the lifeboat we simply boot off vg01 instead of vg00. If everything works well, we will uncomment the cron job after a couple of weeks.

It's a practice that has come in handy more than once.

Hope this helps

B
"All there is to thinking is seeing something noticeable which makes you see something you weren't noticing which makes you see something that isn't even visible." - Norman Maclean