make_recovery error (296)

[Satar Naghshineh]

Hello,

My knowledge of Ignite and the "make_recovery" command are limited. I have a unique situation, I have two K servers (one app and one DB) connected to the same storage array (HP 12h). Two of the drives belong to the app server and the rest of the drives belong to the database server. The reason I state this is because I believe that's why my "make_recovery" is bombing out. Please advise me as to a way of solving this problem. I want to be able to create a recovery tape for our systems.

Some info:
I inherited the system, and I am unable to determine whether it ever worked.

OS version is 10.20
Ignite version is A.1.59

My e-mail from cron:
From: root
Subject: cron

make_recovery(296): Incorrect use /dev/rmt/0mn
Option -A specified. Entire Core Volume Group/disk will be backed up.
make_recovery: usage make_recovery [-ACprv][-d destination][-b bootimage]
make_recovery(210): Encountered a fatal error.
make_recovery(212): Please fix errors and re-try.
Cleanup


*************************************************
Cron: The previous message is the standard output
and standard error of one of your crontab commands:

/opt/ignite/bin/make_recovery -A -v /dev/rmt/0mn #system recovery tape

Info from the makereclog1:
vgdisplay: Warning: couldn't query all of the physical volumes.
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c0t0d3":
The specified path does not correspond to physical volume attached to
this volume group.

Thanks in Advance,
Satar

[Vincenzo Restuccia · Accepted solution]

#rm /etc/lvmtab
#vgscan -v

[Pedro Sousa]

Hi Satar
1st I would say that your command line is not correct. If you want to specify your tape drive, then you should use "-d" flag.
You should use something like this:
2nd - you should install the latest version of ignite http://www.software.hp.com/products/IUX/download.html
3rd http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xdc98ee3e323bd5118fef0090279cd0f9,00.html

Now, about your physical volumes problem, try to check your VGs consistency with vgdisplay -v.
went OK? Did it give the errors you posted?
If so - http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x989dee3e323bd5118fef0090279cd0f9,00.html

good luck.

[Satar Naghshineh]

Thanks for the quick responses!! I assigned you points for helping me out.

Vincenzo, thanks for the command. I was already aware of the command and the results are the same.

Pedro,
1. That's what I thought and tried the -d option. However, the man pages said that it will default to the device driver that I am currently using, so I omitted it.

2. I know, and will do it as soon as possible. But I wanted to know if I can correct this problem.

3. Thanks for the link, I already read it and it didn't apply to my situation.

The last link confirmed my guess as to my the vgdisplay was bombing out. However, it didn't tell me how to correct this problem so that I can run the make_recovery command. Both K boxes are connected to the same storage array and they all can see one another's hard drives. Now, is there a way (or option)to tell "make_recovery" to exclude the volumn group associated with the other server's hard drives? What are other people (in my situation) doing?

Thanks again for any help!

Regards,
Satar

[Pedro Sousa]

Hi again.
So, does this disk c0t0d3 belong to vg00?
if so, you need to take care.
check if it has problems by doing:
dd if=/dev/dsk/c0t0d3 of=/dev/null bs=64

If this disk was from another VG other then vg00, it wouldn't give any error!! And if you try to make a vgdisplay of one of other the system's VGs you'll get a message like:
"vgdisplay: Volume group not activated"
please post more information.

[Pedro Sousa]

Another thing:
strings /etc/lvmtab
can you post it?

[Satar Naghshineh]

Pedro,

Thanks again for comming to the rescue!

It appears that this c0t0d3 belongs to vg02. Now you have made me scared as to whether or not I have a hardware problem.

Here is strings output from the database server (the one that I am trying to make a recovery tape from):
mellesdb:/:>strings /etc/lvmtab
/dev/vg01
/dev/dsk/c0t0d0
/dev/dsk/c0t0d1
/dev/dsk/c0t0d2
/dev/dsk/c0t0d4
/dev/dsk/c1t1d0
/dev/dsk/c1t1d1
/dev/dsk/c1t1d2
/dev/dsk/c1t1d4
/dev/vg00
/dev/dsk/c2t6d0
/dev/dsk/c5t6d0
/dev/vg02
/dev/dsk/c0t0d5
/dev/dsk/c1t1d5
/dev/dsk/c1t1d6
/dev/dsk/c0t0d7
/dev/dsk/c1t1d7
/dev/dsk/c0t0d6
/dev/dsk/c0t0d3

Here is the strings output from the App server (the server that has drives in the same shared disk array):
mellesap:/:>strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t6d0
/dev/dsk/c2t6d0
/dev/vg02
/dev/dsk/c7t0d3
/dev/dsk/c0t1d3

regards,
Satar

[Satar Naghshineh]

Vincenzo,

Thanks for the reply, i did the "vgscan -p" option, but it wasn't until I looked at your post again that I realized I should have done the "vgscan -v" option. It cleared the problem!

Regards,
Satar

[Pedro Sousa]

Hi Satar, I will ask you one more thing.
Can you post th results of "vgdisplay -v vg02" and "ioscan -fnC disk" on both systems?
Don't worry...

Is this VG02 shared for both systems?
It has more disks on one system than the other! Why?

[Pedro Sousa]

Sorry, it seems it's solved already.