Peforming backup using EMC BCV

[raver_1]

Hi all,

To be frank, I'm rather new to HP-UX. Therefore, need your expertise on the following.

I'm trying to backup the production data (on the Application host) using the BCV copy on my Backup host.

These are basically the steps I can think of:

1)Establish the BCV with the Standard;
2)Freeze database;
3)Split the BCV once fully synchronised;
4)Un-freeze database;
5)Import vg;
6)fsck;
7)Mount BCV on Backup host for backup.

My question is, what are the exact commands required for step (5).

Pls note that my Backup host will be backing-up more than one Application host's data at any one time.

Pls kindly advice. Thank you.


Regards,
Jayce

[Steven Sim Kok Leong]

Hi,

I wish I still had my accesses to the HP servers I administered previously. I realised that a lot of information had been stored in my scripts, more than I can remember in my mind. Had missed out copying them out from some of the servers.

For the XP256 business copy integration with omniback backup as far as I recall, the pre-backup script and the post-backup script were using horcm commands to perform pair-splitting of the BCV, fsck, vgchange and pair-resyncing. However, I don't recall any vgimport or vgexport necessary.

Are you implementing via horcm?

# ps -fae|grep -i horcm

Hope this helps. Regards.

Steven Sim Kok Leong

[Luc Bussieres]

Jayce,

To import the VG that was split you have to:

1) run vgchgid with all the BCV split devices on the same line (just the split ones not all of them)
2) "mkdir /dev/vg???" for the backup
3) "mknod /dev/vg???/group c 64 0x##0000" replace the ## with a unique number that is not use by any other volume group.
4) vgimport -m /path_to_mapfile_of_primary
/dev/vg??? disk1 disk2 ...

If you do not have the mapfile for the primary you could execute
vgexport -p -m /path_to_mapfile /dev/vgprimary

Luc

[Jordan Bean]

man lvm
man vgexport
man vgimport

Since you will be making the BCVs available to another host, you won't need the vgchgid (?) command.

I would first create vg map files from the database host and copy them to the backup host:

vgexport -p -f vg.pv -m vg.map vgXX

The channel number may likely be different on the backup host, so modify vg.pv appropriately. For continuity, the targets are usually left unchanged, but check that also.

On the backup host, after the BCV split, this is how to import:

insf -e
mkdir -m 2755 /dev/vgXX
mknod /dev/vgXX/group c 64 0xXX0000
vgimport -f vg.pv -m vg.map /dev/vgXX
vgcfgbackup vgXX

Now you can fsck, modify /etc/fstab, and mount the new logicals.

You only have to do all this ONCE. Before the BCVs are re-established, you only need to unmount the logicals and deactivate the volume group. You don't need to export it.

grep vgXX /etc/fstab | while read lv d junk;do umount $d; done
vgchange -a n vgXX

Re-establish... Wait... Split...

vgchange -a y vgXX
grep vgXX /etc/fstab | while read lv d junk; do mount $d; done


Oh, on minor caveat about vgXX... XX must be unique and, if this kernel paramater hasn't been changed since install, between 00 and 09. Do this to find out which numbers are already in use:

ls -l /dev/vg*/group

Of course, this assumes all the volume groups begin with vg and reside just under /dev.

[Animesh Chakraborty]

Hi,
No need to do vgimport everyday.
Only first time do a vgimport then from next time just do vgdeactivate before sync and vgactivate after split.
Rest of the steps are fine.

[raver_1]

Thank you all who responded. You guys have been very helpful.

Anyway, here're my responds and more queries.

Kok Leong, sorry I don't really know what "horcm" is. I'm implementing Veritas NetBackup using EMC Symmetrix storage.

As for the rest, allow me to elaborate on my concern.

I have six application hosts in which I need to backup using their BCVs on the Backup host.
All the application hosts have their own vg00, vg01, etc. So if I use the vgexport commands to generate the mapfile for each server and vimport them on my Backup host, won't it hit problem?
Eg. if I start two application hosts backup together, backup host will import two different vg00. What will happen???
How can I overcome this? Am I right to say I need to change the channel and target number, and also the vg number of the mapfiles collected for individual application host in order for me to successfully import them on the my backup host.

Animesh, you mentioned there's no need to vgimport every time. Am I right to say you are assuming that the BCV are dedicated. FYI, two of my application hosts are actually sharing their BCV devices.

Awaiting all your valuable advices.
Thank you.

[Steven Sim Kok Leong]

Hi,

XP256 is based on OEM'ed Hitachi Data System (HDS) 7700E SAN disk array.

The HORC (Hitachi Open Remote Copy) is a storage system based remote mirroring product that runs on Hitachi Data Systems 7700E. It mirrors a disk image across a distance.

HORCM is the HORC manager. It comprises of a number of utilities including pairsplit (split the remote mirror copy) and pairresync (resync the remote mirror copy). It is used in XP256 Business Copy Volume (BCV) implementation.

In your case, HORCM is irrelevant since you are not using them for EMC.

Hope this helps. Regards.

Steven Sim Kok Leong

[Animesh Chakraborty]

//Am I right to say you are assuming that the BCV are dedicated. FYI, two of my application hosts are actually sharing their BCV devices. //

Hi Jayce.
Yes I am talking about dedicated bcv attached to one server.
In your case is it same device group you are sharing for both the server ?or part of bcv devices attached to one server and rest of the bcv devices to another server ?

[raver_1]

Kok Leong, thanks for the info. I guess HORC is the same as EMC SRDF (Symmetrix Remote Data Facility). Afterall, they used to work together closely before they decided to go on seperate way.

Animesh, basically I have a shared pool of BCV devices, where I can use to create a Device group for some of the the HP-UX box. i.e. the BCV devices will be reused on each application host.

To ALL, pls kindly provide some advices regarding the importing of mapfiles of individual application hosts onto the Backup host.
Thank you.

[Krishna Prasad]

Please send your e-mail address. It will be easier for me to send the scripts that way.

Anyone else interested let me know.

[raver_1]

Hi Ron,

Pls send the scripts to ccang@ncs.com.sg

Thank you.

[Jordan Bean]

Hi Jayce,

You have six datasets you wish to backup via a BCV pool, but not necessarily at the same time, right?

It sounds like you don't have enough BCVs to dedicate to each dataset. In that case, you will be recycling them, forcing full establishes each time they are synchronized. I digress, however, for this is a different discussion.

Let's address your concern about importing six different volumes groups: Don't worry. The volume group name (number) doesn't have to be the same. What is vg01 on the source host can be vg07 on the backup host. It doesn't matter as long as you know which is which. You can still import each volume group ONCE to a different vgXX and activate only the ones you will be archiving. To give you some room, I recommend increasing the maxvgs kernel parameter.

[raver_1]

When you mention changing the vg name, are you referring to changing it from the various mapfiles generated?

Do provide more detail steps in convenient.

Thanks

[Jordan Bean]

Hi again,

I forgot to discuss targets and luns... This shouldn't be an issue either if you have enough BCVs which do not inherit TLs from their source volumes. When split, the behave as separate volumes with their own TLs.

However, if you have to share the BCVs between several source volumes, then we have a problem! On the backup host, we are forced to deal with physical volumes that suffer from multiple personalities disorder. A physical volume can belong to only one volume group, uniquely identified by a VGID tag written at the head of the device (and preserved through TimeFinder).

You may have to export and import after all... Let me think about this...

[Jordan Bean]

The volume group name and number are not saved in the mapfiles generated by vgexport. Only the logical volume names (-m) and physical volume paths (-f). A name and number are always assigned during vgimport. For example, let's look at this command:

vgexport -m vg00.map -f vg00.pv -p -v vg00

and look at vg00.map and vg00.pv. You will see that vg00.map is a numbered list of logical volume names:

1 lvol1
2 lvol2
3 lvol3
...

and vg00.pv is a list of physical volume paths specific to the host holding the volume group:

/dev/dsk/c0t0d0
/dev/dsk/c0t0d1
...

You cannot rely on the latter file between hosts, but it does it does tell you which symmetrix volumes are used. If you do not have the former file, then vgimport will assign logical volume names automatically (lvol1, lvol2, etc).

[raver_1]

Does that mean I have to pre-create vg for all the applcation hosts on my backup host before I can do a vgimport of the mapfile?

Oh no, I'm getting stuck, don't know how to proceed further.

[Roger Baptiste]

Jayce,

I setup a similar BCV system which supported backup of databases from two hosts . I think, your case is you are doing it for 6 hosts.
Things to consider:

*)VGnames/numbering on the 6 hosts:
-> Let them NOT be the same!! Start a unique numbering sequence. For eg:
host1 VG -> numbered from 010 to 02f
host2 Vg -> numbered from 030 to 04f

and let the VG names be unique on each system!

This saves you a lot of headache when different VGs may end up coexisting on the BCV server at the same time during backups.

*) BCV devices ->
yes, BCV devices -once you map them to the standard luns will REMAIN the same, as long as you do not change it. (and there will be no good reason t o do so). So, for instance,
on HOST1, if you have standard devices 00,01,02,03 belonging to db_vg volumegroup is mapped to bcv devices 100,101,102,103. Then, they will remain mapped like that.
So, whenever you Sync db_vg, data in 00 is synced to 100, data in 01 is synced to 101
and so on. When you split the BCV, you will access the copy sitting on 100,101... from the BCV server. The point is, the pairing will remain the same.
This pairing info will be sitting as a symm database on the host servers (host1, host2..) under /var/symm .

*) BCV devices again ->
To reemphasise what i mentioned above, you just need to work carefully in doing the pairing the first time on all the systems. Remember you would need to use different Bcv devices for all six hosts!!

*) What info to BCV ->
BE sure what info you want to map onto bcvs. Mostly, it will be a database on the system. Normally, you wouldnt need to bcv userfiles, application or vg00 ... So, work with your user groups and make sure of it.


To the actual implementation,
i strongly suggest that you read the man pages of symmmir and symbcv ,as these are the two commands you will be using. They are simple, but effective.

Regarding VG importing ->
You can use two approaches:

use vgexport -p -v -s -m at the HOST1..6 systems and move the mapfile to the BCV server and do a
vgimport -v -s -m , whenever the backup is needed. The only disadvantage with this method is, it can get slow since it has to search(-s) for the VGIDs, but it is simple.
Another method, is to manually setup the vgimport scripts the first time, by comparing syminq outputs at HOST1..6 and the BCV host and adding the corresponding PVpaths into the vgimport command. You would need to do this only once and use the scripts to import everytime you need to backup.
for instance, in a vgimport command the parameters needed are pvpaths and the mapfile.
Once you have a predefined set of pvpaths, you would just need to give the mapfile for the lvinfo !! That saves the vgimport command from searching the symm for finding VGids corresponding to a VG.

Whenver you add a VG in the future, you would add the vgimport command for that Vg into the script sequence.

The overall sequence of a backup would be:

1) BCV is normally split
2) Few hours before backup,
sync up bcv of the system (host1 or host2...)
3) Check BCVs are synced
4)shutdown or coalese database to freeze activity
5) generate and tranfer vg/lv/fs info to BCV host
5) split bcvs
6) Action shifts to BCV host->
vgimport/create fs structure .. bring up database on bcv host to make sure it works
7) bring database down and start backup
8) unfreeze/restart database on main host
9) once backup is done, blowaway vg/fs structure on BCV host.
10) keep bcv split until next cycle of backup.

Also, note -> the ioscan command on the BCV server will hang if you run it during a BCV establish!.

Give yourself sufficient time and sort out everything at the planning stage itself.

Instead of doing this six servers at a time, try implementing two servers and then gradually introduce others.
HTH
ra

[raver_1]

Hi RajMan,

Thanks for the informative response.

You mentioned to have different vg numbers on each of the 6 application hosts.
I'm afraid that is not possible as the hosts are already in production.

So I guess the only way is to create the vg number on my backup host instead. :(

Will get back to you once I digested your inputs.

Thanks

[Roger Baptiste]

I'm afraid that is not possible as the hosts are already in production.
So I guess the only way is to create the vg number on my
backup host instead. :(
>>

Tough call! It will get tricky, because if at any point of time, you want all or some of the database vg from the six hosts being backed up at the same time, then there could be confusion in figuring out what is what.

I hope the VGnames are not the same across the systems!!

If there is no flexibility in getting the vgnumber/names
changed, then you should atleast ensure that the users dont expect you to backup database from more than one system at the same times.

There should be no confusion with control/diskid numbers, since they are not going to be the same. Use the syminq output and identify the luns from the symlun id. That way, you know which id corresponds to which pv path.

If you are using switches to connected to the EMC frames, you would be using (i guess) volumelogix to make the disks visible (selectively) to the hosts. Make sure, each host sees only the bcvs it needs to see, whereas the BCV host sees all the bcvs.

Take your time and consider all possibilities. Dont worry about the actual commands, until you finish the design of how you want to go about it.

HTH
ra