VG migration and file system copy 2

[rondebbs]

Hello, we are using extendvg/mirrorvg to migrate VGs from one symmetrix array to another. One of the Big VGs is already at the 128 PV max so we can not extendvg.

We will take an outage and manually copy all file systems in this VG to new file system names. Rather than just using the cp -R command would we be better off using something like tar or cpio. All the filesystems in the VG total over 2TB so we are looking at the most efficient method. I'm not that familiar with tar or cpio.

Thanks

 

[rondebbs]

Also, the mirrorvgs are moving 1 - 1.5 GBs per minute. Do you think I'll get faster times with a file system copy, or tar etc?

 

[khalidaaa]

Are you moving those files within the machine or across two machines?

If within then you can do this:

cd /destination_fs   #first you have to cd to destination fs
(cd /source_fs;find . -print | backup -iqf -) | restore -iqvpf -

if on different machines, then you first have to configure rsh.

A good hint for rsh can be found here:

http://www.linuxquestions.org/questions/aix-43/how-to-configure-rsh-on-aix-397786/

and then use this command:

cd /destination_fs   #first you have to cd to destination fs on the destination host
rsh source_host_name 'cd /source_fs;find . -print | backup -iqf -' | restore -iqvpf -

Regards,
Khalid

 

[p5wizard]

Watch out with backup/restore, you may end up with sparse files (unallocated null blocks) which is not really desirable for DB files...


HTH,

p5wizard

 

[rondebbs]

I will be copying these file systems and their sub directories and files to the same 5.2 server but from one dmx array to a new dmx array. For the /ora_prd file system, I guess I'll have to use a slighlty different file system name like /ora_prd2 on the new array. When the file system copy is finally done I'll likely delete the /ora_prd on the old array and then use chfs to change the /ora_prd2 mount point back to the real /ora_prd.

In this instance is there any benifit(performance or otherwise) in using cpio, tar etc or should I just stay with "cp -R /ora_prd /ora_prd2".

 

[khalidaaa]

I think cp command will do!

Just remember to use the -p option to preserve permission

cp -pR /ora_prod/* /ora_prod2

http://publib.boulder.ibm.com/infoc...om.ibm.aix.howtos/doc/howto/cmd_copyfiles.htm

Good luck rondebbs.

Regards,
Khalid

 

[p5wizard]

A thought: If you can isolate some of the filesystems of that VG (on a couple of PVs) and migrate these FSs during downtime) to a new VG on the new SAN server, you can reducevg the big VG and make room for extendvg operation on the new storage, hence make migratepv operations possible on a disk per disk basis.

It'll take you longer, but you'll reduce the downtime considerably.

[tt]reducevg bigvg old1 old2
extendvg bigvg new1 new2
migratepv old1 new1
migratepv old2 new2
reducevg bigvg old3 old4
extendvg bigvg new3 new4
migratepv old3 new3
migratepv old4 new4
...[/tt]

And if the new LUNs can be made larger (double the old size), you can migrate 2 old LUNs to 1 new LUN and at each iteration double the number of old LUNs to be migrated. You'll reach 128 sooner ;-).

Also, it is best to plan the migratepv operation for non-business-hours.



HTH,

p5wizard

 

[ogniemi]

I don't know if it was already mentioned, but you can easily copy LV from VG1 to VG2 using cplv command (of course it is better on unmounted filesystem).

To Copy to a New Logical Volume
cplv [ -v VolumeGroup ] [ -y NewLogicalVolume | -Y Prefix ] SourceLogicalVolume

when you copy the LV to new VG is will be exactly the same data and using chfs command you can switch you original fs to new LV (and of course to new jfslog on new VG)

it will probably not work if you have some raw devices where LVCB is owerwritten....I didn't try it...

Moving a JFS/JFS2 File System to a New Volume Group:

http://www-1.ibm.com/support/docview.wss?uid=isg3T1000167