migrating from lvol1 to lvol2 onto a different drive?

[Manuel Contreras]

currently we have many 50GB volumes, made up of 10GB luns...all with single lvols.

the new environment/array will have 500GB volumes, made up of 100GB luns...which will be carved up with multiple lvols.

Since the new volumes are much larger, I won't be able to utilize lvm mirroring to reduce downtime (oracle users can be quite demanding).

I researched "pvmove", but it appears it will only move to the SAME lvol#:
pvmove -n /dev/vg00/lvol1 /dev/dsk/SOURCEDISK /dev/dsk/DESTDISK


seems like I'm stuck with intrusive options:

the "dd" option (not tested, but have read it was faster)
dd if=/dev/vgXX/rlvolYY of=/dev/vgVV/rlvolZZ bs=512k

recursive copies from source to target mount-points.

rsync from source to target mount-points...but since we have Databases = no online advantage.

good old backup and restore...



Is there another option I missed?

your input is appreciated,
manuel

[James R. Ferguson · Accepted solution]

Hi Manuel:

I'd use 'pax'.

It is a very effective way to copy the contents of one filesystem to another,
regardless of the file sizes involved, while preserving both file permissions and file ownerships is:

# cd srcdir && pax -r -w -pe . dstdir

This works on any 11.x release regardless of whether or not the pax version handles files larger than 4 or 8-GB.

Note that 'pax' preserves sparse files during copies.

Create new mountpoints on your target logical volume and while the source logical volume's filesystem isn't in-use, perform the copy. Unmount both the old (source) filesytem _and_ the new (destination) one. Change your 'etc/fstab' to mount the original mountpoint names on the new logical volume appopriately and issue:

# mount -a

Regards!

...JRF...

[James R. Ferguson]

HI (again) Manuel:

I neglated to add that for the faster performance during the copy, mount your target (destination) filesystem with these VxFS mount options:

-o largefiles,nolog,convosync=delay

Online JFS is required for this, but you should see at least a 2-fold increase in speed (your-mileage-may-vary).

Be sure to change the mount options to more standard, protective one afterwards to maintain normal integrity in an on-going, production environment.

Regards!

...JRF...

[Manuel Contreras]

I see some pax testing on the horizon :)
thanks James

[Manuel Contreras]

fyi,
tried pax, dd, rsync and recursive copies...and the winner is:

all tests were performed with a 35GB directory and it's contents (approx. a dozen database files)

1st. recursive copies - 8m11.4s
2nd. dd - 18m6s
3rd. pax - 21m35s
4th. rsync - over 50m

thinking recursive copies will prob. be faster then performing a backup and restore...

input is appreciated...thanks,
manuel

[Volker Borowski]

Hi,

recursive copy will garble your symbolic links, if any in place.
Check with "find" first, if there are any !

Volker

[Manuel Contreras]

really good point on links...but not an issue this time :P

[g3jza]

Hi,

what about using the regular 'cp -p' command?

I've been using the pax , but the performance on 'cp' is much better than pax, even if using

'-o largefiles,nolog,convosync=delay' mount option.

Are there any drawbacks when using 'cp' ? It should preserve symbolic links and is able to copy files > 2GB.

ACLs are not needed.

OS is HP-UX 11.11 .