vgimport using EMC BCV's on separate backup server with different physical paths

[Kevin Speirs_1]

I am currently succesfully syncing, splitting and mounting BCV's to a backup server using vgimport -p -v -m command, copying the *.map and *.dsk files across to the backup server, running vgimport using the *.map and a 'converted' dsk file and then mounting the VG.

When I mean 'converted', what I have is a flat file called STD_TO_BCV which converts the controller path of the disk on the master system to whatever the path is on the backup system.

For example disk c1t0d0 (EMC dev 1A1) on the master system, is device c9t0d0 on the backup system due to it seeing the disk via a different path (as seen via ioscan/syminq etc).

This works OK... except for the fact that I have to ensure that my STD_TO_BCV table is always maintained correctly. i.e. If I add a disk to the master system and I fail to add a line to my table to physically state 'if you see c1t0d0 make it c9t0d0 in the new *.dsk file', the BCV's will not contain the data on the new disk in the back systems' VG.

My question is: Is there a way of running a sync/split/vgexport... followed by a vgimport on the backup server (with different hardware paths to the EMC disk) without the need to 'customise' any *.DSK files?

I've experimented with vgexport/vgimport using a "-s" to get a VGID entry in the map file, but don't seem to be getting anywhere - I tend to get "could not access physical volumes.. ".

Any advice will be much appreciated.

Kind regards,
Kevin

[monasingh_1 · Accepted solution]

We have been doing syncing BCVs, spliting and vgimport with -s option on a different server for a long time without any problem.

One thing I can think of is that perhaps you are running the vgimport right after split returns the prompt. This could not be the actual problem but this may be a possible cause. BCV split runs in background and completes little later even if it returns the prompt to you, and the devices may not be available to host adapter for vgimport.

you may try following:

01. Yoy may want to check the symmir -g DG_NAME -bg. and When split is completely done (no bg shown in output of symmir -g DG_NAME -bg output), then you run vgimport -s.

02. Try the -instant option for doing split which will do a quick and forground split and will only give you prompt after full split is taken place. I also give -force option but that is optional. I also give few minutes gap between the split and vgimport.

Hope this helps. let us know how it goes...

[Geoff Wild]

Why do the vgexport/vgimport at all?

We backup some of our large systems with bcv's all the time...without vgexport/vgimport.

Only need to do that whenever you change the standards...IE, add another disk.

All you need to do is:

sync
put db in hot backup mode
split
take db out of hot backup mode
vgchange -a y on backup server
mount on backup server

No need to copy the dsk's...

Rgds...Geoff

[Sundar_7]

Hi Kevin,

You get "could not access physical volumes" for couple of reasons

1) You need to execute vgimport after the split is done. As Mona has mentioned, bcv split runs in the background and till the time the split is not complete, system cannot access the physical volumes

2) If the script in the backup server is executing vgchgid on the BCV volumes, it effectively changes the volume group ID. So the VGID from the production server's map file (produced by the vgexport -s) will not match with the VGIDs in the BCV physical volumes. So vgimport -s cannot succeed.

So here is what I would do

1) Remove vgchgid from the script
2) execute vgimport once the split is complete (add -instant) option to the BCV split

Geoff - vgexport/vgimport from the production box to the backup server is necessary to make sure any changes to the production volume group is propogated to the backup server (like removing/adding physical/logical volume in the production VG )

-- Sundar.

[Kevin Speirs_1]

Dear all,

Thanks for the advice, I seem to have got it working by adding a few 'sleeps' into my scripts.

I haven't found out the exact cause, but it works at the moment so I'll have a closer look when I've got time.

Thanks everyone.

Kevin