break third vg00 mirror prior to OS patching?

[Adam Garsha]

Is there a whitepaper that outlines steps for booting from a "stale" OS mirror that you had grabbed by splitting a three-way LVM mirror of vg00 lv's prior to performing OS maintenance?

Is this even do-able? Common-place?

If possible, can you specify both PARISC and Integrity links?

[Adam Garsha]

maybe you need to shutdown and physically yank the mirror, replace, startup wait for sync of a new drive and go from there.

[Torsten.]

pull-out 1 disk always work, good practice is to have an ignite backup, but you can also use "lvsplit".

[A. Clay Stephenson · Accepted solution]

Let me suggest an alternative that's even better and I do it on all of my critical servers. Rather than using 3-way mirroring, use 2-way mirroring and use your remaining disk(2) as lifeboat(s). There have been rare cases where a failed mirror has gone undetected so that there are possible benefits from 3 way mirrors but well monitored systems should detect a disk failure so that it can be replaced long before the 3rd mirror ever is needed.

The idea behind a "lifeboat" is that periodically (I do it every weekend as a cron) when the systems are relatively quiescent, you do a dd copy of your boot disk(s) to the lifeboat disk(s). The filesystems are copied dirty but I've never had one fail to boot a machine. I also do a lifeboat copy before any patching.

Lifeboats save you from 2 things that mirrors do not: 1) Your own stupidity 2) Really bad patches. When a lifeboat is actually needed, you simply shutdown (if you haven't already crashed), move the lifeboats into the boot slot(s), and reboot. You are back up in a fraction of the time required by an Ignite (oh, and I do Ignite's too). I find that if you make lifeboats and Ignites then you never need them; if you don't make them ....

[Adam Garsha]

Awesome stuff. Do you do anything special to quiet things down before you take your lifeboat dd copy (shut anything down temporarily)? or just wait for quieter hours.

I wonder if I could just: 1. figure out about booting from EVA (see if doable)... use a SAN disk for lifeboat disk (keep local scsi for primary...). Grab whole vdisk clone for lifeboat rather then dd.

[Torsten.]

If some requirements are met, you can boot from your EVA.

[Brian A. Scurlock_1]

You should be able to use pvchange -a n if you have the correct patches installed to disable the mirrored PV you want to preserver than then if you wanted to boot off of that PV you could interupt the boot proccess (press any key within 10 secs) and do a bo alt or sea and bo (device number you want to boot from.
-Brian

[Adam Garsha]

cool one about the pvchange!

Also, for the lifeboat idea... since the device file for your lifeboat will be different (because it lives in a different path), can you still search for it at boot time and use it or do you need to pull out the original and put your lifeboat in its physical location to actually boot from it.

Does your answer change with Integrity?

[Torsten.]

You can swap the lifeboat disk to the other slot or just vgimport it to make it work with the different path.

[Adam Garsha]

I am trying the dd/lifeboat and it is taking "forever". Any tips on a tested/speediest dd example for use in this situation?

[Torsten.]

You didn't told us the size of your disk and the system and the scsi type you are using
:-(

less than 1 hour - maybe

[A. Clay Stephenson]

I suspect that you are using the standard block (512 bytes); you should also use the character (rdsk) device nodes.

dd if=/dev/rdsk/c1t5d0 of=/dev/rdsk/c2t5d0 bs=1000k

Do not specify an ibs= and an obs= simply use bs= to avoid an extra buffer-to-buffer copy with dd itself.

Typical copy times are a few tens of minutes per disk (depending uspon speed and size) and if vg00 is comprised of multiple disks then you can run them simultaneously.

[Adam Garsha]

36GB... you knew it was 10's of GB's :)

Looking for recs on bs, MB's, KB's, or default?

[A. Clay Stephenson]

Okay, here's a fully functional script; however, MAKE ABSOLUTELY CERTAIN that you assign the SRC and DEST device(s) to match your machine. I would also add the -v flag (verbose) and comment out the dd command itself until you have made certain that each source and destination device is correct.

copy_boot.sh

[Bill Hassell]

Thye critical parameter (for speed) in dd is bs= and the default is a very un-useful 512 bytes. That default translates to megabytes per hour so a 36Gb disk might take all day with no bs= value. Note also that bs= can take abbreviations such as 64k or 1024k. Anything above 256k doesn't seem to improve much but anything below 32k will definitely make the copy very slow. You can tell the difference while watching the disk lights. Large blocks take some time to read and then the disk goes quiet for a bit while the block is written to the destination. With the default 512 bytes, both lights will be on constantly and performance will be pitiful.

[Adam Garsha]

Thanks all!