Updating the BCV vg on backup server !!!

[Mihaita Bighiu]

Hi,

I have the following problem.
After I have extended the vgdata on production system with 2 EMC disks I had to add 2 more disks for BCV (we are doing BCV backup using OB).

BVC disks are connected to backup server using V-logix (via brocade switch).

Afer I did all the EMC tasks (assigned disks update full sync and split the vgdata device group), when I tried to import the vgdata on backup server (using the map file from production) the 2 new added disk are not present in /etc/lvmtab (the new disks are /de/dsk/c14t7d7 and c14t7d7).

Both disks are visible on backup server and I successfuly used them to create a test vg. Was Ok. After this I did pvreate -f and full sync again.

More than that. After I did all of the bellow steps Istill have the same problem:
# lvreduce /dev/vgdata/lvdata11 ( to reduce all disks with ???) ( was oK)
# vgreduce -f vgdata
...
"PV with key 7 sucessfully deleted....
"PV with key 8 sucessfully deleted....

# mv /etc/lvmtab /etc/lvmtab.orig
# vgscan -v (OK)
# vgcfgbackup -u vgdata ( is OK)

At this step the 2 new disk are not part of the vgdata on backup server. So I have to add them into vgdata.

I did again on backup server:
# symfcg discover
# syminq ( shows the newdisks c14t7d6 and c14t7d7)
# inq (same as above_
# ioscan ( same as above)

# diskinfo /dev/rdsk/c14t7d6
SCSI describe of /dev/rdsk/c14t7d6:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 8838720 Kbytes
bytes per sector: 512
rev level: 5566
blocks per disk: 17677440
ISO version: 0
ECMA version: 0
ANSI version: 2
removable media: no
response format: 2

# diskinfo /dev/rdsk/c14t7d7
SCSI describe of /dev/rdsk/c14t7d7:
vendor: EMC
product id: SYMMETRIX
type: direct access
size: 8838720 Kbytes
bytes per sector: 512
rev level: 5566
blocks per disk: 17677440
ISO version: 0
ECMA version: 0
ANSI version: 2
removable media: no
response format: 2

# dd if=/dev/dsk/c14t7d6 of=/dev/null
# dd if=/dev/dsk/c14t7d7 of=/dev/null
(both of them are OK and does not return any error message)

# vgexport vgdata
# mknod /dev/vgdata/group c 64 0x11000
(0x110000 is unique on backup server and same as is on production server)
# vgimport -s -m /tmp/mapfile /dev/vgdata
(I used a fresh copy of mapfile of vgdata from production system created with vgexport -s -p -m mafile vgdata)

After vg import all the lv's of vgdata are in /dev/vgdata but the 2 new disks still missing (are not in /etc/lvmtab and also the vgdisplay vgdata does not show same CUR PV and ACT PV) In my case CUR PV = 21; ACT PV = 19.

I did again vgscan -v ( after I rm /etc/lvmtab) an I got the following messages related to the 2 new disks:

Couldn't stat physical volume "/dev/dsk/c14t6d6":
Invalid argument
Couldn't stat physical volume "/dev/dsk/c14t6d7":
Invalid argument
Physical Volume "/dev/dsk/c14t7d6" is not part of a Volume Group
Physical Volume "/dev/dsk/c14t7d7" is not part of a Volume Group

Note that /dev/dsk/c14t6d6 and c14t6d7 are on the same VG with the new disks.

So after all this work I am at the same point:
- I could do everything with the 2 new disks on backup server but extending the vgdata.

What is next?

Thanks,
MB

[George A Bodnar]

You are going about this the wrong way. When you do the BCV sync you basically completely overwrite the disk so having them imported in a VG on the backup server will not work. Here is an outline of what you need to do:

* Make sure the BCV disk are exported from the backup server.
* Perform BCV establish.
* Perform BCV split when ready to backup.
* If the backup server has a VG of the same ID as on the primary server do a vgchgid against the PVs.
* Do a vgimport on the PVs. You'll need to create the directory and group file with this since the vgcreate doesn't do this.
* Mount your disks.
* Run your backup.
* Repeat for next night.

Basically just remember that BCV is overwriting the entire disk so you overwrite your VG information which is what is happening to you.

[Mihaita Bighiu]

Hi George,

Thanks for feedback.
My probelm is that the BCV backup worked until I had to add 2 more BCV's.

Before adding the new disks the vgdata minor number was 0x110000 ( same as in production system).

After the new BCV disks have been addeed to the device group I did a full symc. As result all BCV's updated their vg information with the new vgdata vg from production.

I did split and vgexport/vgimport on backup server. Should I do vgexport fisrt and after this syns/split and vgimport ?

For consistency I like to have the same minor # for vgdata as is on production system. This shoudn't be a problem as worked before! And in this way and don't have to export the BCV disks from backup server every time when the backup run. Is this correct or not?

Thanks,
MB

[Roger Baptiste]

hi,

The procedure is simple. You are adding
two disks to existing vg - Vgdata .
First, make absolutely sure that the volume logix actually sees these two disks and their
corresponding BCVs. Ensure that the BCV disks
are visible *only* to the backup server and not the production server. Once the volumelogix part is done, get on to the production systems and run insf -e to create the device file. (do the same on BCV server).
Then, run inq and check whether the two PVS are visible. There will two luns on production server and two different luns on backup server (with bcv tag).
Then, do the bcv mapping for the production Luns and bcv luns. To do this, you have to find out which Devicegroup does vgdata belong to. Do a
symdg list to display device groups
symmir -query will also give the full details.
Once you identify the Devicegroup, add the two primary luns and two bcv luns to the device group using symld -add command. Then, you have to map these luns as primary <->bcv ,to assign mirror-pairing. With the pairing done, anything on the primary will be mirrored to the BCV during the establish process.

Rest of the stuff is normal (adding pvs to VG, export, import, mknod etc..). Only after you establish(full establish for the first time) and split , you should vgimport vgmaps. Vgexport can be done at any time, as long as it has the current VG information.

HTH

[Mihaita Bighiu]

Hi RajMan,

Thanks for your thoughts.

As I mentioned the problem is not on updating the BCV device group. L-logix is OK and the new disks are visible only to the backup server.
I could play with vgdata device group ( sync split, etc).

The problem is when I try to updata the vg vgdata on backup server. Vgimpot is OK ( all the lvo's of vgpdata are imported) but I do not have available the 2 new disks in /etc/lvmtab. When I activate the vgdata on backup server the CUR PV and ACT PV are not the same ( CUR PV =21, ACT PV=19) The 2 new added disk are missing.

Thanks,
MB

[Tim D Fulford]

Hi

curious problem....I have two similar suggestions that may help in diagnosing where the problem is. It basically revolves VGID & does it exist on the devices. I'd check these on the source machine before the BCV split, after the BCV split & on the target (OmniBack server/client)

o Check the VGID's of the disks in vgdata includeing the two mysterious ones... the following thread gives info on how to check..
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x65d7d08cc06fd511abcd0090277a778c,00.html

basically (this is not the method I used but I'm at home without my little blue book)
# echo 2000?c+8x | adb /dev/rdak/cXtYdZ
Also check this against the VGID in the /etc/lvmtab file by using "od" on it. the VGID is listed on the same line as the /dev/vgdata will be listed.

o The second method checks if LVM believes these disks are indeed part of the same VG.
# vgscan -apv
-apv ~= all disks, preview (do not overwrite /etc/lvmtab), verbose

using teh above two you should be able to see if there is a problem with LVM

IF the disks do indeed have the same vgid & should be part of the same VG, then I suspect (I'm only guessing here) that a kernel parameter(s) on your OmniBack machine restricts the number of disks in an VG, or something of that nature... Again I'm not at work etc...

Tim

[Mihaita Bighiu]

Hi,

I got the following results:

# vgscan -apv

.....
Physical Volume "/dev/dsk/c14t7d6" is not part of a Volume Group
Physical Volume "/dev/dsk/c14t7d7" is not part of a Volume Group
......

# echo 2000?8c+8x |adb /dev/dsk/c14t7d6
2000: LVMREC012850 45C7 3D13 8315 0 0 0 0

# echo 2000?8c+8x |adb /dev/dsk/c14t7d7
2000: LVMREC012850 45C7 3D13 8315 0 0 0 0

I did also:
# echo 0x2010?2X|adb /dev/dsk/c14t7d6 |expand|tr -d " "|sed "s/2010:/VGID /"

# echo 0x2010?2X|adb /dev/dsk/c14t7d7 |expand|tr -d " "|sed "s/2010:/VGID /"

On both cased I got the same result:

VGID 00

Same command on a disk which is part of a vg return the good resultsfor VGID. For example on /dev/dsk/c14t7d5
# echo 0x2010?2X|adb /dev/dsk/c14t7d5 |expand|tr -d " "|sed "s/2010:/VGID /"

VGID 28BB153738E4B9D7

At this point I thing the BCV disks are bad. I have to call EMC to fix this. I'll let you know where the problem was.

Thanks a lot for all your help.
MB.