topic Re: regarding vgimport/vgcfgrestore in Operating System - HP-UX

regarding vgimport/vgcfgrestore

Jason Moorhead_2 — Tue, 27 Feb 2001 16:47:24 GMT

I have 2 systems and one disk array, and the disk array is split into primary storage and a mirrored copy (business copy). The primary storage is mounted to one of the servers. I need to split off the mirror copy and mount it to the second server, for backup purposes. Using vgexport on the primary server and vgimport on the backup server seemed like the logical answer, but to no avail. Doing an lvdisplay on the backup server shows me something like the following:
--- Logical extents ---
LE PV1 PE1 Status1
00000 ??? 00000 current

Why do I get the question marks? How do I get the system to identify the physical volume when the mirrored copies are mounted on the backup server? Would vgcfgbackup/restore work on this?

Re: regarding vgimport/vgcfgrestore

Satish Y — Tue, 27 Feb 2001 22:32:35 GMT

Hi,

You should first vgexport on primary in preview mode using -p option:
$ vgexport -p -m mapfile vg_name

Then bring mapfile to secondary(using ftp or rcp,etc.) and vgimport using this map file:
$ vgimport -v -m mapfile vg_name pv_path1 pv_path2 ......

Still It doesn't work you need to run vgcfgrestore... It will fix the problem.

Cheers.....
Satish.

Re: regarding vgimport/vgcfgrestore

Peggy Fong — Wed, 28 Feb 2001 00:59:08 GMT

Hi
The questions marks mean that lvdisplay cannot determine the physical disk associated with the lvol. If you are on 10.20 or later there is an option -k that will give you the PV Key of the disk...not that will help you in your situation. For clarification - on one server you want to split your mirror. On the other server that has access to the disks you want to mount this data. You cannot export a portion of the volume group. Are you exporting the whole volume group?If not, then the previous poster mentions how to vgexport in preview mode of the entire volume group (but not really export it) and import on the other server only the disks that are offline. But both systems will have the lvm configuration. This is not good. Also to import, you have to create a directory and do a mknod for the group file before doing a vgimport. I'm not really giving specifics because I'm afraid this is not the best approach. Maybe you should use nfs and remote mount.

Got any spare disks? You could create another VG and lvols and copy the data to that. Then you could vgexport/vgimport as much as you'd like. It would be a safe offline copy.

Re: regarding vgimport/vgcfgrestore

Unix Systems Admin — Wed, 28 Feb 2001 08:28:56 GMT

Hi Jason,

You are missing a step. We use business copy here.

So far, then you have used created the business copy and split it away from its parent.

What will happen is the system suddenly "sees" a number of new disks which were part of that business copy.

For each of the "new" disks you need to run
vgchgid against these disks _but_in_the_same_VG!

For example, if your Business Copy contains the volume group vg_fred, consisting of three luns and you split the copy then you will have three new luns appear, lets call them c1t2d1 c1t2d2 and c3t4d5. To prepare them for a new volume group run:

vgchgid /dev/rdsk/c1t2d1 /dev/rdsk/c1t2d2 /dev/rdsk/c3t4d5

I believe vgchgid makes a random vg header id on the disk, so you must have each disk in the same group on the same line so they receive the same random number.

You can then import the volume group:

mkdir /dev/vg_banana
mknod /dev/vg_banana/group c 64 0x010000
vgimport vg_banana /dev/dsk/c1t2d1 /dev/dsk/c1t2d2 /dev/dsk/c3t4d5

Now you have the volume group you export it, ready for the second server:
vgexport vg_banana

And then on the new server, import the VG.

If you have any problems I am willing to show you the code I use to do this job.

Best wishes

Adam

Re: regarding vgimport/vgcfgrestore

Jason Moorhead_2 — Wed, 28 Feb 2001 14:45:19 GMT

Adam,

You're definitely of help here! Not sure if our systems are the same, but I have 4 servers total.. 3 of which are app servers and 1 is a dedicated backup server (connected to a tape library), and all 4 are connected to an XP disk array.

Sounds like the vgchgid is what I need. Could you run down exactly what the process is when you split your business copies off every night and mount them to the backup server? This split and mount is what does not seem to be working for me. If it wouldn't be too much trouble, could you start from the beginning, assuming that I have not setup any of the volume groups on the backup server, and have done no vgexports or vgimports? Basically, start from when I have 4 servers connected to the array, and 3 of them have one volume group located on the array (so there are 3 vg's total on the array). How would I split the mirror and mount the 3 business copies to the backup server?

After the backups are done, are there any special procedures you need to run against the BC disks before you resync them?

Sorry to go back to basics here! I just want to be sure that I'm not forgetting something. Thanks Adam!

Jason

Re: regarding vgimport/vgcfgrestore

Unix Systems Admin — Wed, 28 Feb 2001 18:31:19 GMT

Well, here goes...!

We have four volume groups here which have a business copy on them. The machine is called 'tyne'. The volumes are vg1, vg2, vg3, vg4.

Structure of vgs when in BC pair:

vg1: c4t6d0
vg2: c11t6d0
vg3: c4t7d2, c11t7d2
vg4: c11t6d2

business copy groups: vg1, vg2, vg3, vg4

What happens is this:

1. At midnight our databases are shut down and the business copy is split:

pairsplit -g vg1
pairevtwait -g vg1 -t 600 -s psus

what this does is split the BC pair, the wait for 600 seconds for the system to be in suspended state - 'psus'. This can be verified by doing

pairdisplay -g vg1

This is done for each business copy group.

2. When the BC pair splits a new lun will appear (the first time) and you may have to do an insf to create the device files.

What happens here is:

vg1 goes to c4t6d0 *plus* c4t12d0 (BC)
vg2 goes to c11t6d0 *plus* c11t12d0 (BC)
vg3 goes to c4t7d2,c11t7d2 *plus* c4t13d2,c11t13d2 (BC)
vg4 goes to c11t6d2 *plus* c11t12d2 (BC)

So the status is that we have a number of disks 'floating' which the OS does not think are part of a VG, but if you force it to read the VGRA then it will say 'hold on, its disk 1 of vg1!' and get thoroughly confused.

After this step our DBs are restarted.

3. We now create new volume groups based on the new disks. Lets call them vg1_bc, vg2_bc, vg3_bc and vg4_bc.

First of all we need to prepare the volume groups.

cd /dev
mkdir vg1_bc vg2_bc vg3_bc vg4_bc
mknod vg1_bc/group c 64 0x050000
mknod vg2_bc/group c 64 0x060000
mknod vg3_bc/group c 64 0x070000
mknod vg4_bc/group c 64 0x080000

Obviously change the minor number to the correct values for your system.

4. Now change the volume group IDs on the new disks:

vgchgid /dev/rdsk/c4t12d0
vgchgid /dev/rdsk/c11t12d0
vgchgid /dev/rdsk/c4t13d2 /dev/rdsk/c11t13d2
vgchgid /dev/rdsk/c11t12d2

Note that we have two disks on one line. If you don't they end up with a different VGID on each which means that you can't import them (take it from me, after much pain!).

5. Create a map file of each of your volume groups...

vgexport -m vg1.mapfile -p vg1
vgexport -m vg2.mapfile -p vg2
vgexport -m vg3.mapfile -p vg3
vgexport -m vg4.mapfile -p vg4

REMEMBER THE -p OPTION! This will cause the mapfile to be created (only needs doing once, or each time you add a LV), and the existing VG to be left alone.

6. Import the volume groups into the new volumes.

vgimport -m vg1.mapfile vg1_bc /dev/dsk/c4t12d0
vgimport -m vg2.mapfile vg2_bc /dev/dsk/c11t12d0
vgimport -m vg3.mapfile vg3_bc /dev/dsk/c4t13d2 /dev/dsk/c11t13d2
vgimport -m vg4.mapfile /dev/dsk/c11t12d2

7. Activate the volume groups.

vgchange -a y vg1_bc
vgchange -a y vg2_bc
vgchange -a y vg3_bc
vgchange -a y vg4_bc

You can now mount the logical volumes and do what you want.

8. When you want to finish using the business copies and re-sync them you need to
a) umount all filesystems.
b) deactivate the volume group (vgchange -a n VG)
c) export the volume group (vgexport vgX)
d) resync the BC:
pairresync -g vgX
pairevtwait -g vgX -t 600 -s pair

Each time you split off a copy you need to do a vgchgid then a vgimport.

If you wish to use another server to import the VGs then I still suggest you use a vgchgid before an import, assuming you know the target names (cXtYdZ) - using Brocade switches gets confusing with all the disks! You may already have a VG with the same ID.

I hope this has been of help. If you would like any further help please feel free to email me at Adam.Wainwright@pgen.com

Best wishes

Adam