Why did I loose vg02?

[Charles Holland]

As part of our normal monthy proces we make ignite backups on the 1st and 3rd Saturdays of the month. Recently we were working with trying to recover a K560 from an ignite server. When we were FINALLY successful in recovering the back up we had no vg02 and had to do a vgscan, vgimport for all the disks and vgchange to activate them.

Reviewing the > backup < script output :

______________________________________________________________

Command line=
make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

______________________________________________________________
* Creating NFS mount directories for configuration files.
* Recovery Archive Name = 2005-06-18,00:36

* Lanic Id = 0x080009D8D0FD

* Ignite-UX Server = private_rp5450


======= 06/18/05 00:36:34 EDT Started make_net_recovery. (Sat Jun 18 00:36:34
EDT 2005)
@(#) Ignite-UX Revision B.5.4.50
@(#) net_recovery (opt) $Revision: 10.637 $

* Testing pax for needed patch
* Passed pax tests.
* Recovery Archive Description = Archive_of_SANDBOX

* Recovery Archive Location =
private_rp5450:/ignite/recovery/archives/sandbox

* Number of Archives to Save = 3

* Pax type = tar


In? dsk/vg name minor# Associated disks/mountpoints
0 v /dev/vg01 0x01 /dev/dsk/c1t0d0 /dev/dsk/c9t0d0
/dev/vg01/lvol1 /sapdb 0
/dev/vg01/lvol2 /usr/sap/PRD 0
/dev/vg01/lvol3 /sapdb_backup0 0
-1 v /dev/vg02 0x02 /dev/dsk/c1t1d0 /dev/dsk/c9t1d0 /dev/dsk/c1t2d0 /dev/dsk/c9t2d0 /dev/dsk/c1t3d0 /dev/dsk/c9t3d0 /dev/dsk/c1t4d0 /dev/dsk/c9t4d0 /dev/dsk/c1t5d0 /dev/dsk/c9t5d0 /dev/dsk/c1t6d0 /dev/dsk/c9t6d0 /dev/dsk/c1t7d0 /dev/dsk/c9t7d0 /dev/dsk/c1t8d0 /dev/dsk/c9t8d0 /dev/dsk/c1t9d0 /dev/dsk/c9t9d0
/dev/vg02/lvol01
/dev/vg02/lvol02
/dev/vg02/lvol03
/dev/vg02/lvol04
/dev/vg02/lvol05
/dev/vg02/lvol06
/dev/vg02/lvol07
/dev/vg02/lvol08
/dev/vg02/lvol09
/dev/vg02/lvol10
/dev/vg02/lvol11
/dev/vg02/lvol12
/dev/vg02/lvol13
/dev/vg02/lvol14
/dev/vg02/lvol15
/dev/vg02/lvol16
/dev/vg02/lvol17
/dev/vg02/lvol18
/dev/vg02/lvol19
/dev/vg02/lvol20
/dev/vg02/lvol21
/dev/vg02/lvol22
/dev/vg02/lvol23
/dev/vg02/lvol24
/dev/vg02/lvol25
/dev/vg02/lvol26
/dev/vg02/lvol27
/dev/vg02/lvol28
/dev/vg02/lvol29
/dev/vg02/lvol30
/dev/vg02/lvol31
/dev/vg02/lvol32
/dev/vg02/lvol33
/dev/vg02/lvol34
1 v /dev/vg00 0x00 /dev/dsk/c2t4d0 /dev/dsk/c2t5d0 /dev/dsk/c2t6d0
/dev/vg00/lvol1 /stand 2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol4 /home 2
/dev/vg00/lvol5 /opt 2
/dev/vg00/lvol6 /tmp 0
/dev/vg00/lvol7 /usr 2
/dev/vg00/lvol8 /var 1
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
80009D8D0FD/recovery/2005-06-18,00:36/system_cfg vg00
* Backing Up Volume Group /dev/vg01
* /usr/sbin/vgcfgbackup /dev/vg01 Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
* Creating Map Files for Volume Group /dev/vg01
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg01.mapfile /dev/vg01
vgexport: Volume group "/dev/vg01" is still active.

* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00 Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00
vgexport: Volume group "/dev/vg00" is still active.

* Creating Control Configuration.
* Creating Archive File List
* Creating Archive Configuration

* /opt/ignite/bin/make_arch_config -c /var/opt/ignite/recovery/client_mn
t/0x080009D8D0FD/recovery/2005-06-18,00:36/archive_cfg -g /var/opt/ign
ite/recovery/client_mnt/0x080009D8D0FD/recovery/2005-06-18,00:36/flist
-n 2005-06-18,00:36 -r 64 -d Archive_of_SANDBOX -L
/var/opt/ignite/recovery/arch_mnt -l
private_rp5450:/ignite/recovery/archives/sandbox -i 1 -m t
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

* /opt/ignite/data/scripts/make_sys_image -d
/var/opt/ignite/recovery/arch_mnt -t n -s local -n 2005-06-18,00:36 -m
t -w /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/recovery/2005-
06-18,00:36/recovery.log -u -R -g /var/opt/ignite/recovery/client_mnt/
0x080009D8D0FD/recovery/2005-06-18,00:36/flist -a 3368460

* Preparing to create a system archive
* The archive is estimated to reach 1684230 kbytes.
* Free space on /var/opt/ignite/recovery/arch_mnt
after archive should be about 35225682 kbytes.

* Archiving contents of sandbox via tar to
/var/opt/ignite/recovery/arch_mnt/2005-06-18,00:36.
* Creation of system archive complete

* Creating CINDEX Configuration File

* /opt/ignite/bin/manage_index -q -c 2005-06-18,00:36\ Recovery\ Archive
-i /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/CINDEX -u
Archive_of_SANDBOX

* Cleaning up Archives
NOTE: Archive: 2005-05-07,00:36 is being deleted
* /opt/ignite/bin/manage_index -d -c 2005-05-07,00:36\ Recovery\ Archive
-i /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/CINDEX

======= 06/18/05 01:29:32 EDT make_net_recovery completed successfully!


A bit hard to read, sorry. But I note that on the vg02 information line, under the In? column, it has a entry of -1. I can find in the admin guide what a 0,1,2 represent but no - numbers. Other than "sorry you won't be able to recover this volumn group" ( a guess on my part) what caused this, and more importantly how do I resolve this for the future? Please not as part of the process it did a vgcfgbackup for both vg00 and vg01 but not vg00.

Any help would be appreciated and I do assign points.

Thanks

[MarkSyder]

The best resolution is only to use ignite for vg00, which is what it's designed for - it really isn't very good for backing up non-operating system stuff.

Better to use something like fbackup or Data Protector for vg01 and vg02 - daily rather than twice a month.

Mark Syder (like the drink but spelt different)

[Pete Randall]

Your answer lies in the command you used to create your archive:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

Note the "-x inc_entire=vg00" portion. If you wanted to include other VGs, they would have to be identified similarly. Note also that this is outside of Ignite's intended scope. While it can be done, it is not recommended.


Pete

[Devender Khatana]

Hi,

It is required for all the VG's which were not included in the backup. This is usual & the actual purpose of ignite backup is to recover system from boot disk failures & not any other faiures in other VG's. So use other methods of backup for other VG's & ignite for backing up vg00. This will make your recovery fast when vg00 disk fails & will not require to recover when disk in some other VG fails.

HTH,
Devender

[harry d brown jr]

You didn't specify vg02 or even vg01 in the backup:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

where you should specify vg02 and vg01 specifically:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -x inc_entire=vg01 -x inc_entire=vg02 -P s -d Archive_of_SANDBOX

I don't know why it backed up vg01, but it did (huh!).

What does this command return?

what `which make_net_recovery`

live free or die
harry d brown jr

[melvyn burnard]

One question to ask, was vg02 activated at the time of creating the recovery archive?
If not, and you are using version 5.4 or below of Ignite, then it will NOT backup the information for the deactivated vg's.
This is a standard problem for servers that are memners of a Serviceguard cluster, and this issue has been fixed in the 6.x release of Ignite.

Just a thought.

[Charles Holland]

First I wish to thank everyone for their quick replies. Although I must confess I don't understand the answers to some of them. First off I understand what make_net_recovery is supposed do. Back up vg00, with the options to include other vg's in it if you want to.

In most everyones response it is assumed that I want to back up vg01 and vg02 using make_net_recovery. Let me make this clear..I do not want to back up > ANYTHING < except VG00
in this proces. Yes Mark we already to use fbackup or Data Protector to take care of the vg01 and vg02 data.

By a man page on make_net_rrecovery :
-x inc_entire=/dev/dsk/|vg_name
Includes all file systems contained on the specified disk or volume group. Use a block device file of the format /dev/dsk/ when specifying a whole-disk (non-LVM) file system. Use the volume group name (such as vg00) when you want all file systems that are part of that LVM volume groupto be included in the archive.

That is why I specifically specified "-x inc_entire=vg00" in the command line.

Harry - I scanned through the flist file that
is located at /var/opt/ignite/clients/sandbox/recovery/latest and there is NOTHING in it other than vg00 file structure, do I have to presume that it didn't back up anything in any other vg.

In regards to your what command the results are
# what `which make_net_recovery`
/opt/ignite/bin/make_net_recovery:
Ignite-UX Revision B.5.4.50
net_recovery (opt) $Revision: 10.637

Yes I know I'm a bit behind, tried to dowload 6.1.44 this morning by service was not available at that time.

Melvyn - Yes vg02 was activated at the time of creating the archive. In vg02 is where our database (raw file system) resides. As you can see above it is version 5.4 but there is no Serviceguard involved (don't have it).

I have just been able to download the new version of ignite. Can someone advise if I have to uninstall the 5.4 version from all the clients and the Ignite server first and then install the 6.1.44 version, or (I hope) simpley install it on all servers and be done with it.

Still looking for answers why vg02 had to recreated by hand. Or better yet why the backup procedure recognized the existance of vg02 but did not run a vgcfgbackup on it.

Regards

[Steven E. Protter]

What Ignite is good at:

Getting a good image of your boot volume group, usually vg00

What Ignite can not do:
Get an image of an open database like oracle and such.

When you get your vg00 image it should include the setup for all the other volume groups within that Ignite image.


Hopefully this simplification will be useful. You are getting excellent help here.

SEP

[Pete Randall]

Charles,

I don't believe vg01 was backed up either. The only thing it did was run vgcfgbackup against it. Can you examine your archive to see if anything of vg01 was backed up?


Pete

[Charles Holland]

SEP - I just reviewed the other 2 systems that have a database on them and they also had the "-1" in the In? column. In both cases it identified the existance of the vg and listed the disks in the vg but did not run a vgcfgbackup process on it. I agree with you that it should have the setup for all the other vg's also. But it apparently didn't as we had to go through the above process to get it back.

Pete - see above the answer to Harry about looking at the flist file.

Regards.