Poor Man's Mirroring?

[Jason Martens]

Hey all,
We have a server that does not have any software raid (for various reasons). I do however have two internal disks, and I would like to impliment a "poor man's" mirroring solution. Basically, I want to copy my production boot disk to the spare internal disk once a week or so, so I can use it to boot should (when) the primary fails.

Suggestions for doing this? dd? cp? I vaguely remember something about make_lif or something like that.

Thanks,
Jason

[Jason Martens]

This is an L2000 BTW.

[IT_2007]

You can simply make it as alternate boot disk.

Here is the procedure.

1. pvcreate /dev/rdsk/alternatedisk
2. mkboot /dev/dsk/alternatedisk
3. mkboot -a "hpux -lq" /dev/dsk/alternatedisk
4. vgextend /dev/vg00 /dev/dsk/alternatedisk
5. lvextend -m 1 /dev/vg00/lvol1
6. lvextend -m 1 /dev/vg00/lvol2
7. lvextend -m 1 /dev/vg00/lvol3
complete for the rest of lvol's in vg00.

Once it is finished, you can check lvlnboot -v vg00

[Pete Randall · Accepted solution]

When you say "Poor Man's Mirroring", I assume you mean that you do not have MirrorDisk/UX. Given that, you need to look into a life boat image created with dd. You copy the entire root disk onto a spare and, should your root disk fail, you simply swap the spare into the slot where your failed root disk resides.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=51838


Pete

[DCE]

I assume you do not having mirroring installed.

The following link tells how to use dd

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1058578

If you have mirroring installed, then follow the instructions in the previous answer

[Jaime Bolanos Rojas.]

Jason, just to expand IT_2007 answer, to do the lvextend -m you will need a copy of Mirror Disk/UX, for which you will need a licensed if not installed, if you are really a poor man ( just like me ) you might not want to pay for it :-)

To check if you have it:

swlist -l product | grep -i mirror

If not, then check with fbackup, I do not really know if the solution is feasable.

Other option is to backup your data, use ignite ux which is a free software that you can download.

Regards,

Jaime.

[A. Clay Stephenson]

Werll, if you don't have MirrorDisk/UX then the suggested lvextend -m 1 commands are rather useless. What you can do is something like this (if I can assume the disks are identical -- or at the very least that the capacity of the destination disk is at least that of the source disk):

src=/dev/rdsk/c0t6d0 # source raw device; change to your actual boot disk
DEST=/dev/rdsk/c1t6d0 # destination raw device; change to fit your box

dd if=${SRC} of=${DEST} bs=1024k

This will make an exact copy and should be done when the system is relatively quiet. Shoulkd you need to actually use this "lifeboat" disk, you remove it from it's current slot and put it in the boot disk's slot. Because the filesystems are copied dirty, an fsck (automatic) will be done when the box is booted but I've never had a lifeboat fail to boot. I actually do this every weekend as a cronjob on all of my boxes (in addition to normal mirroring) because lifeboats will fix 2 things that mirrors do not: 1) really bad patches 2) your own stupidity.

However, you should get still another disk and purchase Mirror/UX.

[Jason Martens]

WOW! And yet again the forums are the most helpful support place in the world. :)

I do not have MirrorDisk, so I can't use mirroring (unfortunately, as it works really nicely).

One question, I've read all the various threads, and there seems to be some discrepancy with the blocksize to use with the dd command. Does it matter? Or do I need to use one particular blocksize. So far, I've seen 8000, 2000 and 1024 suggested.

Thanks,
Jason

[IT_2007]

You can use different block size to use in dd command. If you use big blocks in chunks of 1024k or 2048k or 3072k, it copies faster.

[Pete Randall]

The important thing about the block size is to make sure you specify one. If you don't, it defaults to 512 bytes and the copy will take *FOREVER*. I always use 1024k with good results.


Pete

[James R. Ferguson]

Hi Jason:

A large blocksize like 1024k (note the "k") results in faster transfers for the whole concept associated with why block data in the first place.

The other important thing to note is the use of the *raw* disk devices. Using the raw device file ('dev/rdsk/cXtYdZ') means that LVM does *not* get involved in passing the data.

Regards!

...JRF...

[A. Clay Stephenson]

In practical terms the blocksize is not all that critical as long as it is 64KiB or greater. Above that the performance differences will be quite small. There are two "gotcha's" to avoid: 1) Specifying no blocksize - the default 512 byte block will be very slow 2) Specifying separate input block size and output block size. e.g ibs=1024k obs=1024k rather than simply (and seemingly equivalent) bs=1024k. In the former case there are actually two buffers and dd has to do an in-memory buffer copy from the input to output buffer. In the latter case there is but one buffer so that the extra copy operation is avoided.

[Bill Hassell]

And just to clarify the lifeboat disk: It is an exact copy of the boot disk and that includes information about the slot for that disk. You won't be able to boot from the lifeboat disk if it is in another slot. That is why setting up disk mirroring so the other disk can automatically boot is a more complicated process.

And as Clay mentions, lifeboat disks are the last resort to handle the big "oops" that root sometimes makes. (to be accurate, Ignite/UX is the very last resort) Disk mirroring will faithfully copy all your mistakes to the mirror whereas the lifeboat disk is a very nice rollback mechanism.

dd without the bs= value is extremely slow, just a few megs per minute. Change it from the default 512 bytes to a large block size to dramatically improve performance. The largest difference in speed occurs when the block size is 128k or more, but perforamnce will asymptotically trail off after 1024k or so. Note that dd understands the k as Kbytes.