using veritas to migrate data

[Shawn Miller_2]

I am currently migrating data from one disk array to another. The disks are synced between the arrays so all the data is on the new set of disks. I have done this with LVM but I am not sure how with Veritas. Here is roughly what I do with LVM.


1. umount /a01
2. vgchange -a n vg_a01
3. vgexport -m vg_a01.mapfile vg_a01
3.5. have the sync between the disk arrays turned split - turned off - have a good clean copy now.
4. mkdir /dev/vg_a01
5. mknod /dev/vg_a01/group c 64 0x100000
6. vgimport -m vg_a01.mapfile vg_a01 /dev/dsk/c7t1d1 (the .../c7t1d1 being the disk device file for disk that is from the new arrary.)
7.vgcfgbackup vg_a01
8. After this is done for all the disks run mount -a to mount the new disk arrary disks onto the original file systems.

The users can not tell there is any difference but we would now be using disks from the new disk array.

[Steven E. Protter]

Veritas what?

Veritas netbackup?

vxfs filesystem is a veritas product that is used for filesystems.

OnlineJFS is also a Veritas product. The process would not be very different than your current process.

I'd recommend a good cold fbackup prior to the migration to avoid mistakes. A Veritas netbackup backup would also suffice.

SEP

[Shawn Miller_2]

These are import disks but not critical so the copy of the disks on the old array will suffice for backups. --

I am refering to veritas volume manager 3.5. I am looking at the commands but see nothing equivalent to a mapfile. Nor do I see on the import where I can specify the disks using something like the pv device name.

[Geoff Wild]

I havn't done this myself - as I don't use VERITAS Volume Manager...

But, look at this doc:

http://docs.hp.com/hpux/onlinedocs/5991-0613/5991-0613.html

You could mirror the vxfs volume - then remove the primary?

Rgds...Geoff

[Joseph A Benaiah_1]

Shawn,

There are a few other methods that you could consider. I depends on the fact that your UNIX host has visibilty of disks on both arrays.

1. Add the disks from the new array to the existing volume groups and use LVM mirroring. Once completed, reduce the mirrored copies leaving the PV's from the new in the existing volume groups. This method depends on the Max PV set appropiately and the max number of PE's set appropiately to accomodate bot the LUN sizes on both arrays.

2. Create a new volume group, for example vg_a01new, and the same logical volumes that exist in the original one. You will need to unmount all file systems in vg_a01 but this leave the volume group activated. You can then copy the data using dd as follows:

dd if=/dev/vg_a01/rlvol1 of=/dev/vg_a01new/rlvol1 bs=64k

Once you have done this for all lvols and vgs on your system, deactivate both volume groups, export them with a mapfile and import the new disks into /dev/vg_a01. You will need to reboot the server so that the applications start up.

I have migrated data from an EMC Symmtrix to a HP-XP1024 in a data centre with over 400 servers so I can confirm that this works.

Cheers,

Joseph

[Alzhy]

If your server has the full license of VxVM in place then migration from one array to another is easy with VxVM. You can do it in two ways - via mirroring or via evacuation - both of which will not impose any downtime. I am assuming the new array is SAN friendly and you already have an "established" SAN - meaning the old array is also on that SAN and the new array's LUNS can be non-disruptively presented to the servers.

VxVM MIRROR APPROACH:
For each Diskgroup, add a corresponding amount of LUNS from th enew array. Then Mirror until fully synch'd up. Then split the old array's LUNS off of the diskgroup and de-present those LUNS. I'll be happy to show you the commands but for now use VEA (the GUI) to do this as it will also show you ("Tasks" tab) the actual commands.

EVACUATION APPROACH:
Do as above by presenting the replacement LUNs from the new array (You need not have the same sized LUNs if you wish). Then for each LUN on the old array, simply do a "vxevac" - which will migrate all volumes (LVOL in LVM lingo) from a specified LUN to the target LUN or LUN(s).

/etc/vx/bin/vxevac [-g diskgroup] [-t tasktag] medianame [new_medianame...]

Again you can also use the VEA GUI for this.