How to deport & import Veritas disk group on to different disks ?

[Darshan Komurlekar]

Requirement : HP Server is connected to Disk array-1 and has all Veritas disk groups on it. It is decided to disconnect this server from Disk Array-1 and connect to new Disk Array-2; Create the same configuration of disk groups and restore the data ( backup tapes) on to Disk Array-2. Please note that disks from Disk Array 1 will not be moved to Disk Array-2.

Question: How can I minimize the time of recreating disk-groups and volumes (100s) again ? Is it possible to do it with DEPORT & IMPORT way ? If yes, please give the exact syntax. I have gone through the Veritas Users/Admin/Migration Guide on HP docs, but couldn't find the soln.

Here is how I would have done with HP's LVM :
1)vgexport -m vg01.map -pvs /dev/vg01
2)vgexport -f vg01.file -pvs /dev/vg01
3)vgexport /dev/vg01
4)Disconnect Disk Array1 and connect to Disk Array2.
5)Select new disks to be added to vg01.
6)Replace the old device file names with new ones from "vg01.file".
7) mkdir /dev/vg01
8) mknod /dev/vg01/group c 64 0x010000
9) vgimport -m vg01.map -f vg01.file /dev/vg01
10) Run newfs on all LVs in this vg01 & mount them.
11) Restore the Data.

How is it possible with Veritas Disk Groups ?

Thanks in advance for your feedback,

Darshan.

[Ralph Haefner]

I don't think you can do it with import and deport in Veritas. I've used Veritas to move disks from one server to another. You deport the diskgroups, hook up your array to the new server, then import your diskgroups. At my last job we did this all the time to move diskgroups from one server to another when we had to move into a new datacenter.

But I don't think it works the other way, you can't move the deported group onto another set of disks. If I'm wrong about that and somebody can tell how it is done I'd be interested in learning it too.

[jim rosser]

Have you looked at just adding the new disk to the server and then use Veritas to move the data to the new disk. You can actually do this while the server is up and running.

[Alzhy]

Darshan,

If you have the ability to have both Disk Array 1 and DIsk Array 2 attached to the server at the same time - then please do so as this will be the right way to do it without incurring much unwanted downtime.

You can bring in DiskArray 2's luns to the present config, mirror them and once done, mirror detach the luns that belong to array 1 and you're golden! If you're on a SAN, then you should never incur any downtime at all!

[Darshan Komurlekar]

Hi Sandy & Nelson,

Thanks for taking time to give your feedback. Here is reply to ur queries about this : Since this is a Disaster Recovery Test. Disk array-1 won't be connected when we would be connecting Disk array-2. So we can't choose the Option of mirroring (plex) or copying the data . Looks like Veritas VM doesn't have this fuctionality like HP's LVM. Good selling point for HP !!

[Alzhy]

Darshan,

Actually with VxVM -- you have fewer steps.

Backup Data/Mounts
Backup VolMgr COnfigs and DG's:
vxprint -mvpshr
On new Array/Envrironment:
vxmake
Restore Data.

Learn VxVM and you'll know what I mean.

Of course if you're talking DR needs, then Veritas has a solution as well for maintaining storage bits of your local prod and remote DR server in synch -- I forgot the VxVM option but it is a separately licensible product that works with any storage hardware..

[Darshan Komurlekar]

Nelson,
Per ur suggestion vxprint/vxmake seems to be the way to backup & restore the vxvm information using "descriptor file". Let me try this quickly and give the feedback. But the "vxprint -mvpshr" doesn't give the o/p that can be used/stored as Descriptor file for its further use in vxmake. Any specific options during vxprint for this purpose ?

Thanks,

Darshan.

[Alzhy · Accepted solution]

You do vxprint -mvpshr -g for each DG in your system.. capturing the output to a file. You now use that file as an argument to vxmake to rebuild your DG's..
..
VxVM is'nt really that difficult compared to LVM. Once you master it -- you can work in any VxVM environment -- the syntax and technologies are common accross Unices. There is a VxVM Mailing list (Auburn... somethingy.. search for it in Google) and of course there is vxideas.org and cuddletech.org.