creating business copy with eva3k

[Wayne Green]

Have 2 sites with 2 HPUX11.0 hosts running SP 3.0D. One eva3k at each site. Have recently loaded BC server and host agent software ver 2.3 on SMAs and HPUX servers.

Have setup BC snapclone job for backup at one site using the BC gui OK. snapclone presented to the same server. snapclone created for VG using one LUN.

Created BC snapclone job in gui for VG using 2 LUNs at second site. snapclone operation OK but mount operation failed. job log showed warning

"Cannot present a BCV that is already presented to the fabric "

Ran the undo job, both snapclones were deleted but then one of the source LUNs was unpresented to the HPUX server

The snapclone LUN created for the first LUN seems to have used the LUN number assigned to the second LUN and then the undo job has unpresented the second LUN.

Should this job work? Does it break any rules? I thought a VG could have upto 16 devices. I've seen posts where sssu scripts are used instead but I was hoping the gui and evmcl would save me a lot of work and headache. Has anyone else had similar problems.

[Alzhy]

What is it exactly that you are trying to achieve? Are you trying to present and mount a BCV LUN to the other site's HP-UX server?

I think if you really want failoverability between the 2 sites (I trust they're on dark fibre connection?) then Continous Access will be your best choice.

Or you can use a Veritas Cluster/VxVM solution with or without ServiceGuard.

[Wayne Green]

dark fibre connection is a great idea but DBAs are not convinced.

All I'm trying to do is take a snapclone of a filesystem (FS is on the only LV in the VG. VG has 2 LUNs presented from the EVA) and present the snapclones to the same system so we can take a backup of the snapclones.

FS is used for a database so idea is to drop the DB create the snap then restart the DB. Then we have a cold backup of the DB with just a few minutes downtime.

The only reason I mentioned the other site is because this has been setup and runnig OK for a while with exactly the same hardware and software but the VG only has one LUN.

[Uwe Zessin]

It is not that easy, because a snapped PV has the same ID as its parent. This will confuse the LVM. The supported way is to present the snapshot to another server.

[Alzhy · Accepted solution]

Wayne,

If you're using BC to do all of this (meaning all done from the SMA).. then you should'nt have any problems at all with either mounting the snap on the same server or on a different server - as long as you follow "rules". At BC prior to 2.2.3 it is very strict in that everytime there are changes in LVM config (new LUNS, new LVOLS, etc..), you must execute the two scripts :

/opt/CPQevm/bin/UpdateHost.sh and Generate_mapfiles.ksh.


Under 2.2.3.. Generate_mapfiles.ksh was droppped.

In our case however we do not totally rely on relying on the SMA/BC job for everything. Instead, we simply have the snapclone job ran on the SMA (executed via evmcl) and using SSSU - script the presentation of whatever SnapClone LUNS on wherever server they're supposed to be mounted (ie. on itself, the backup server or our test/staging server). Once presented to the proper server we've a script that does:

1. ioscan;insf -e
2. copies over the mapfile from the source server (if mounted ona diff server)
3. runs a script that gets the VGID and compares them with the VGID of the source VG so we get a list of cXtYdZ of the PV set tobe imported... creates a PV list file.
4. creates the proper vg device directory, group.. etc..
5. Change the VGID of the set (via the vgchgid command)
6. Finally the VG is imported and activated and mounted.

[Wayne Green]

Nelson, Thanks for the info. didn't know about the updateHost.sh file. I may have fallen foul of this "rule" if thats the case as I recently moved this logical volume to its own VG to test business copy jobs.

I didn't get the BC software when these were installed, an oversight by the supplier, but recently received the updates. As I scripted it all with sssu I thought this would be more reliable than my scripts which is an issue as we have a production server attached to this EVA which could also use this backup method.

Its not the creation of the snapclones I was concerned about but being able to fully test VGID changes, vgexports, LUN deletion and SP removal made me a bit nervous. The developers may call it a test machine but its only a test machine to us when they're not using it.