Moving Data between servers

[MTSU_SAN]

I'm replacing an existing production server with a new one. I need to quickly move the data from the existing server to the new one--the bright idea was to mirror the data from the existing server's fc60 disk array to a VA7410 which is attached to both servers.

This is great, but I am having trouble getting the LVM commands to separate out those new mirror disks, without losing the data on them, and then import them as a new VG on the new server.

Any suggestions?
c*

[Geoff Wild]

What kind of trouble?

You will need to lvreduce -m 0 /dev/vgXX/ /dev/dsk/

When done for all lvols, you need to vgreduce those devs from the vg...

Then vgimport on the new server...

Rgds...Geoff

[Rick Garland]

Doing a mirror from 1 type of array to another type of array does not always work.

Can copy the data from 1 system to other. Here are some examples using tar, cpio, and vxdump...

to WRITE a tar file TO a remote device
tar cvf - * | remsh (systemname) dd of=/dev/rmt/0m

to LIST (table of contents) tar file ON remote tape device
remsh (systemname) dd if=/dev/rmt/0m | tar tvf -

to READ (get) tar file(s) FROM remote tape device
remsh (systemname) dd if=/dev/rmt/0m | tar xvf -

Do not cross NFS mounts or it will fail.


Remote CPIO

find filesys -print | cpio -ocv | remsh remotehost "dd of=/dev/rmt/0m"

find filesys -print | cpio -ocv | remsh remotehost "dd of=/backup/system_a.cpio"

find . | cpio -oc | remsh remotehost "cd /newpath ; cpio -icdmuv"


/usr/sbin/vxdump 0f - /dev/vg00/osymmgr | remsh luna '(cd /apps/osymmgr; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vg00/openv | remsh luna '(cd /apps/openv; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vgfin107/orahome | remsh luna '(cd /apps/aporacle107; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vgfin107/appsmgr | remsh luna '(cd /apps/appsmgr107; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vgfin107/custom | remsh luna '(cd /apps/custom107; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vgfin107/orchid | remsh luna '(cd /apps/orchid107; /usr/sbin/vxrestore -rf -)'
/usr/sbin/vxdump 0f - /dev/vgcrcard/crcard | remsh luna '(cd /apps/crcard107; /usr/sbin/vxrestore -rf -)'

[James R. Ferguson]

Hi Connie:

If you are merely replacing the server, then 'vgexport' your non-vg00 volume groups and 'vgimport' them on the new server. This is one of the things that 'vgexport/vgimport' is designed to do.

# vchange -a n vgNN
# vgexport -m /tmp/vgNN.map -v -f /tmp/vgNN.dev vgNN

...move '/tmp/vgNN.map' and '/tmp/vgNN.dev' to new server; edit the device file paths in '/tmp/vgNN.dev' to match the new server's configuration; and 'vgimport':

...OR, use th e'-s' variation of 'vgexport':

# vgexport -m /tmp/vgNN.map -s -v vgNN

...and on the new server (either):

# vgimport -m /tmp/vgNN.map -v -f /tmp/vgNN.dev vgNN

(or):

# vgimport -m /tmp/vgNN.map -s -v vgNN

# vgchange -a y

Regards!

...JRF...

[Chan 007]

Hi,

I use the method of JRF..

lvreduce to remove mirror.

Ensure that your application and database is down while removing the mirror to have a complete sync.

Cheers ...007

[MTSU_SAN]

Appreciate all of the replies, but I need some time where both servers are up for testing before the change--the cpio is fine, but will take days (I've done this before when I installed Service Guard cluster), and the vgexport will give me no time to test.
c*

[MTSU_SAN]

Oh, and Geoff, I did that and the new server complained that the disks belonged to another CPU ID, and the data was not retrievable on those disks.
c*

[Robert-Jan Goossens]

Connie,

Title: Moving disks from Server1 to Server2
Document ID: KBRC00014628

US
http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000075725050

Europe
http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000075725050

With the vgchid you can change "cpu id"

Regards,
Robert-Jan

[MTSU_SAN]

Thanks for the document, and the vgchid idea. I'll try my old method and see if the data is on those disks after I move it. But, I'm moving a copy of the disks, not the disks themselves, so it is a little more involved than in this document.

[Howard Marshall]

Sense you have a disk array that is attached to both servers I recommend the following.

Using the shared disk array, create equivalent volume groups. For example if you have a vg01 then create a vg01a if you have oraclevg create oraclevga or something like that.

Then create equivalent logical volumes and file systems then mount them to relative mount points.

Then you can use cpio on a per file system basis to copy the data from one to the other

#>cd /opt/whateverdir
#>find . -xdev -print | cpio -pdxamv /opt2/whateverdir

you can have more than one instance of this running without overwriting anything sense the find -xdev won't cross mount point .

when the find and cpio commands have copied the files over unmount the relative file systems, export the vg and import it as the correct vg name on the other system.

Do all the testing you want or need, then when its time to convert for real you can just move the database data across.