full backup and no ignite

[steven Burgess_2]

Hi all

'hmmm' I hear you say, but honest I have never been in this situation and wanted to have a procedure before I do

scenario

I have a running system with mirrored logical volumes in vg00 and other volume groups.
I have a problem with vg00 , stale extents and a ghost disk. If the lvreduce fails I have no ignite (please don't ask why. I have already got a bruise on my head) I do though have a full backup ,CD-ROM and the HP11 cd's.

Whats the best way to get back to a fully running system following a problem with the root volume group where the server won't boot ?

Here's my procedure

1st for the lvreduce I have this docid

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&admit=-938907319+1034269393294+28353475&docId=200000063208748

If the lvreduce fails I have this procedure

1. Boot into LVM maintenance mode. (hpux -lm)
2. vgexport -m vg00
3. Recreate the group file for vg00:
mkdir /dev/vg00
mknod /dev/vg00/group c 64 0x000000
4. vgimport -m /dev/vg00 pv_path ...

If vgimport gives errors then run the additional steps:
vgreduce -f /dev/vg00
mv /etc/lvmtab /etc/lvmtab.old
vgscan -v

5. vgdisplay vg00 <--- it should now show the Cur PV = Act PV
6. lvlnboot -v <--- verify root, boot, swap and dump settings
7. Reboot the system.
/sbin/reboot

If that fails and I have a copy of the filesystem layout. Build the server from the CD using the initial boot disk.

Once the server has returned here's where I am stuck.

Before the OS build from CD do i need to export vg01 and vg02 to a mapfile and have this file on tape along with /etc/fstab

Restore the map files and fstab then reimport the volume groups as above and then mount -a ?

The data should still reside on the disks ? therefore I shouldn't need my full backup tape apart from data lost in vg00 ?

Thanks in advance for any input

Steve

[John Dvorchak · Accepted solution]

Steve, here is the proceedure that I have used in the past to recover a failed disk in vg00:


I have a process now to recover the failed boot disk /dev/dsk/c0t1d0:

1. Make sure of the hardware and devices files path of the failed drive.
2. use setboot to see if your primary and alternate are setup correctly. How ever you do it make sure of the hardware path and the device file of the failed disk and write it down some where.
3. If the system has "hot swap" drives, like the new "N's" etc then have the HP CE verify the disk has failed and replace the failed disk back to the previous hardware path. You will not need to reboot to replace the failed disk or to recover it. You will only have to reboot to test that the disk has been recovered and is bootable.
4. After the new disk is in place you will have to restore the lvm configuration back to it:

vgcfgrestore -n vg00 /dev/rdsk/c0t1d0

5. Then make the volume group active, this puts the failed disk back into active status:

vgchange -a y vg00

6. Make the disk bootable and verify LIF area contents:

mkboot /dev/rdsk/c0t1d0
mkboot -b /usr/sbin/diag/lif/updatediaglif -p ISL -p AUTO -p HPUX -p LABEL /dev/rdsk/c0t1d0
lifls -l /dev/rdsk/c0t1d0
mkboot -a "hpux -lq" /dev/rdsk/c0t1d0

7. Verify the autoboot contents (Don't forget the - at the end):

lifcp /dev/dsk/c0t1d0:AUTO -

8. Store and update BDRA:

lvlnboot -Rv

9. Then vgsync the volume group to restore the mirrors and all data (this will take a long time):

vgsync vg00

10. Complete. First chance you get reboot it off of the new disk to make sure that all went well with the recovery.

[James R. Ferguson]

Hi Steve:

Other than not having an Ignite tape which makes this all so simple...you have thought this out well.

Yes, the data will be intact on your non-vg00 disks even if you cold-install.

Since you know from your paper documentation the disk device files that comprise each volume group, you *don't* really need to worry about mapfiles!

Knowing the device files associated with each volume group means that you can specify the pv_paths for a 'vgimport'. If you use the standard, default logical volume group names, the mapfile is superflous. If you don't, and you forget (or past-tense) to do a 'vgexport' to create a mapfile, *make one*. A mapfile looks like this:

1 lvol1
2 lvol2
...

Regards!

...JRF...

[John Poff]

Hi Steve,

You can vgexport vg01 and vg02 to create the map files and use them for vgimport, or if you know which disks those VGs live on you can specify the PVs on the vgimport command line. The map files save you from having to figure out which PVs to use, and also will help if you have used any non-standard names for the lvols.

JP

P.S. I hope your bruise gets better soon. Ignite makes for a nice helmet! ;)

[steven Burgess_2]

Hi fellas

Thanks for the replies

After I do the vgimport do I need to

vgchange -a y

then

vgcfgrestore (or vice-versa)

or does the vgimport restore the volume configuration ?

Yes, I need to go on the lvm course

Thanks again

Steve

[John Poff]

Hi,

After doing vgimport for your vg01 and vg02 VGs you will have to do vgchange -a y on them. The vgimport doesn't do it. You shouldn't need to do vgcfgrestore on them after the vgimport, but after you look them over and are satisfied they are completely and successfully back in business, you might want to do a vgcfgbackup on them.

JP

[John Dvorchak]

Steve, you will note in my previous answer step 5 is vgchange -a y vg00

Yes once the pv is back in the vg you have to re-activate the vg so it sees the new disk.

[S.K. Chan]

Yes you need to activate (vgchange -a y /dev/vgXX) the VG after you vgimport it. No vgcfgrestore is not needed because you're not restoring LVM header information onto those disks. You would only do vgcfgrestore onto a new disk or onto an existing "corrupted LVM header" disk. Vgimport keep the LVM information intact. You would want to run "vgcfgbackup vgXX" as your final step so that /etc/lvmconf/vgXX.conf is updated.

[steven Burgess_2]

Hi all

Right I'm nearly there now

Just a couple of steps back here

From my full backup I am going to recovery data from vg00. So that the 'ghost disk' information isn't restored

here's what I would plan to exclude

??? /etc/lvmtab
??? /etc/checklist
??? /etc/inittab
??? /etc/ioconfig
??? /etc/lvmconf
??? /etc/lvmpvg
??? /etc/mnttab
??? /etc/utmp
??? /etc/lvmrc
??? /dev
??? /stand/vmunix


Any further input on this

I'm off home now 19:30pm UK. I will post the full procedure from the information you guys have supplied tomorrow , plus dish out the points

Thanks again

Steve