Problem with drive mirroring

[Robert Young_10]

I'm working with a HP-UX ssytem at work: it has one drive, which is partitioned with LVM. We want to mirror this drive to second drive, so we can swap the drives when we lend the machine out (recently we lent the machine to a contractor who tried to upgrade it, and wiped out the drive in the process..)

I was hoping to use dd to achieve this, but it does not seem to want to take. Any suggestions on the easiest way to accomplish a drive mirror from one disk to another?

[Robert-Jan Goossens]

Hi,

Why not use a ignite tape, ignite is a free product mirror/ux will cost you extra.

http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=IGNITEUXB

Hope this helps,

Robert-Jan

[Jean-Luc Oudart]

Hi,

mirror-UX is the answer. But it's not free.
You have to purchase a license for it.

as far as I remember the license might be indexed on the number of cpu on the server.

Rgds,
Jean-Luc

[Helen French]

Well, you can use 'dd' to make a copy of your existing disk. If you want to go for Mirroring with LVM, then you need Mirror/UX software which is a priced product. Why did you think that dd won't work for you?

Also, if you have only one drive (which is vg00 and contains OS), install Ignite-UX on your system and create a recovery tape with make_tape_recovery command. In that case, you can restore your data to disk even if everything is lost.

[Jean-Luc Oudart]

Oops,

Robert-Jan is right,
If you don't need resilience. Ignite will do the trick.

Anyway you should have an ignite copy of your system (or more even). If you have to revert patches this may be very usefull ...

Rgds,
Jean-Luc

[Sean OB_1]

I agree that ignite is easy way to go.

What issues are you having when you try to use your dd'd disk?

I'm not sure if dd will take the boot information on a disk. Did you setup the disk as a boot disk and then dd the current disk to it?

[Robert Young_10]

Thanks everyone for the replies so far: I'm still working on a solution.

To Shiju Wilson: I ran dd as follows

dd if=/dev/dsk/c2t5d0 of=/dev/dsk/c2t6d0

where c2t5d0 is the input disk, and c2t6d0 is the destination disk. They are identical SCSI drives, but the dd process has been running for about an hour and a half now: it shouldn't take that long to copy a drive image should it? They are both 9 GB SCSI drives. (Mind you, I haven't unmounted the first drive, I can see that slowing down the process a good deal.)

I'll search my disks for Ignite: sounds like an easier solution. I reason I was hoping to find a way to do it from the console to be able to automate the process.

[Pete Randall]

Robert,

You need to add a block size to your dd command. The default is 512 bytes at a time and it will take days.

Try dd if=blah of=blahblah bs=1024k


Pete

[Pete Randall]

Hmmm, that almost looks like there's a space after the equal sign - there shouldn't be.


Pete

[A. Clay Stephenson]

The problem with your dd is that the blocksize is much too small and that you are going through the buffer cache. This should be raw/io with a larger dd buffer.

dd if=/dev/rdsk/c2t5d0 of=/dev/rdsk/c2t6d0 bs=256k

You might even try a larger bs and make sure than you only use bs= rather than ibs= obs= so that there is only 1 buffer and no buffer copy operation is done. You should do this when the system is as quiet as possible and the destination disk must be at least as large as the source - preferably identical disks.

NOTE: Because the filesystems are mounted, fsck's will be required on each filesystem when it boots but I have never had one of these to fail. Also because everything is riding on one disk, it would be a very good idea to use Ignite to do a make_tape_recovery --- so that you won't need it.

[Pete Randall]

Thanks, Clay - I hadn't even noticed the cooked disks. That will definitely help speed things up!


Pete

[Helen French]

Again, as pointed out, you need to use raw device files (rdsk instead of dsk) when specify with dd command. Also, use bs option like bs=512K or bs=1024K. That will defenitely speed the process up.

I would still consider make_tape_recovery as an option, since your disk is only 9GB and that it's easy and safe:

# make_tape_recovery -I -v -x inc_entire=vg00 -a /dev/rmt/0mn

[Todd McDaniel_1 · Accepted solution]

My company has a great way to do this... we have implemented a script that dd copies the root drive to another disk...

I will attach it here...

[kamal_9]

since you are using vg00 only its better to go for Ignite-UX and make an recovery tape

[Tim Sanko]

I could say that if you don't have Mirror Disk UX don't bother, but My production server is running on the alternate right now...

I would do an ignite tape through cron weekly, but I also have Mirror Disk/UX on every production server. I readily admit to paranoia with regards to production servers.

Tim

[Robert Young_10]

Thanks for the information, I wish I'd used the raw disk from the start.

I just installed ignite: doesn't make_recovery_tape require a tape device? Also, doesn't it only back up a part of a lvm group? It would be better if I could copy all of the information on the one drive exactly onto the other.

Running dd with the blocksize set and using raw disks gave MUCH better performance. The copy worked, however it complained about not being shutdown properly the first time I ran from the mirrored disk, as I wasn't able to umount all of the mounts on the primary disk.

[Pete Randall]

Robert,

Yes, make_tape_recovery requires a local tape drive. You can also do make_net_recovery to another system if one with sufficient space is available. The idea behind Ignite is to backup your root volume group in it's entirety so you can quickly recover the O/S. You *can* do other VG's as well, but the recommended method is to use conventional backup methods for your data volumes.

And yes, after the dd it will complain and you'll have to fsck the file systems.


Pete

[Pete Randall]

Robert,

I just wanted to add that I think that, lacking a tape drive, you're better off with your dd approach. I'd stick with that (though it would be nice to have a tape drive and run make_tape_recovery).


Pete