Mirror disk and import on another server

[Geoff Wild]

I have 2 servers.

I want to "migrate" the data on one server to another.

So, I had the disk on the new server also mapped to the old server.

I vgextended, lv mirrored the disk to the existing vg.

No matter what steps I do (lvsplit, lvreduce, etc) I can not get the vg with the single disk on the new server.

I can vgimport it, but it thinks it has 2 disks - won't let me vgreduce -f

I can't run vgcfgbackup either...

As soon as I vgreduce that disk on the old server - the new server no longer thinks it is in a vg...

Anyway to mirror from one server to another or am I stuck with having to do a disk to disk copy?

Rgds...Geoff

[TwoProc]

Hey Geoff,

What I've done is to go ahead and lvreduce it right out of there like you did.

Then, go ahead and create a new vg for this one, using the disk as the primary (first ) disk for the new volume group.

Now, very carefully and deliberately, create all the lvols EXACTLY like you had them on the other machine.

Then, just mount the file systems (skip the newfs step), and you're done.

[TwoProc]

Oh, a little explanation as to what I meant by:

Now, very carefully and deliberately, create all the lvols EXACTLY like you had them on the other machine.


After re-reading it, I realized it's not that clear what I meant.

I mean use the same exact extents, start and stops as had them defined for this same disk, in the vg on the originating system that you brought the disk over from.

OK?

[Geoff Wild]

Yes - I looked at that - but a lot of work...I have 2.5 TB to copy....

What does work (just finished - but slower then lvm mirroring):

Don't vgextend the disk on the old server, just do a dd:

dd if=/dev/rdsk/c28t5d7 of=/dev/rdsk/c36t4d1 bs=1024

Then on new server - do a vgimport!

Question is - on 74GB LUNS, what block size should I use for best performance?

Rgds...Geoff

[Bill Hassell · Accepted solution]

> dd if=/dev/rdsk/c28t5d7 of=/dev/rdsk/c36t4d1 bs=1024
>
> Question is - on 74GB LUNS, what block size should I use for best performance?

Wow, bs=1024 is awful. Use bs=256k for all large disk copies (more than a few megs). The LUN size isn't important, only the amount of data read and then written. The default (no bs=) is 512 bytes which means that billions of separate I/Os will be required. bs=1024 still means billions. bs=128k or bs=256k means orders of magnitude faster with only thousands of I/Os. Note that values greater than 256k won't provide much improvement due to the driver's I/O handling.

[Geoff Wild]

Thanks Bill - 256K eh?

I did one at 1024K and it completed in 24 minutes...

How many do you think I could stream before the server fell to it's knees?

RP7410, HP-UX 11.23, 6 CPU's, 14GB ram...

[Bill Hassell]

> How many do you think I could stream before the server fell to it's knees?
> RP7410, HP-UX 11.23, 6 CPU's, 14GB ram...

dd is almost invisible as a process. It simply reads and writes blocks of data. There's no multi-record caching in dd so the program won't grow very large even with 1meg blocks. You will hit channel and disk limits before your server is even aware of multiple dd processes. Performance will be limited by the array layout and controller speed.

[Torsten.]

IMHO the vgreduce will remove the VG related information, so the import cannot find anything useful.

Think about this: DRD (dynamic root disk) will create a "cold" standby copy of your vg00 and creates a new VG (drd00) - how about this. I know, it is not intended for this purpose.

[Sandman!]

Can the new server see the disk which is part of the VG on the old server?

IMHO...it could be that since the new server cannot see the old server's disk it thinks that you are trying to remove the one and only PV out of that VG and so it disallows that operation. Try all steps after making the disk on the old server visible to the new server. Just a roundabout way of saying that each server should see the others disks (the ones that need to be migrated).

~hope it helps

[Geoff Wild]

The dd was the best solution to this.

It took 7 and a half hours to "copy" the 2.2 TB of data.

Rgds...Geoff