LVM Recovery - HPUX 10.x - 11.x migration

[Dave van Nierop]

Hi there,

We have a K570 running HPUX 10.20, and are considering a cold install to HPUX 11.x. Our primary data resides on a AutoRAID configuraiton.

Does anybody know if it is possible to recover a 10.20 AutoRAID volume group configuration using vgcfgbackup/vgcfgrestore or if there are specific AutoRAID utilities to do this.

Can it be done at all?

Your assistance is much appreciated. Thanks a lot - Dave

[James R. Ferguson · Accepted solution]

Hi Dave:

You merely need to 'vgexport' and subsequently 'vgimport' your non-vg00 volume groups. To make things easy, use the '-m' and '-s' options. Have a look at the man pages for both commands.

Regards!

...JRF...

[hpuxrox]

You should be able to just export your map file and reimport them on the 11.x server once you switch the cables.

lookup vgexport/vgimport

[S.K. Chan]

This recipe works for me all the time ..

Example you want to move vg02.
1) Umount all filesystem associate with vg02.

2) Deactivate vg02

# vgchange -a n /dev/v02

3) Remove the VG entry from /etc/lvmtab & the associated device files from the system.

# vgexport -m /tmp/mapfile /dev/vg02

Make sure you transfer a copy of /tmp/mapfile to some other server first, we'll need that file later.

4) Shutdown the systems (or move hardware to a new path if you want to). Power up system.

5) Recreate the VG (you don't have to call it vg02, it can be vg08, etc)

# mkdir /dev/vg02
# mknod /dev/vg02/group c 64 0x0X0000

Note: The minor number (0x0X0000) must be unique for each volume group. Substitute X for a number not in use on the system. Use: ll /dev/*/group to see existing group files on the system. (Ex: # mknod /dev/vg02/group c 64 0x020000)

6) Import the VG info for all disks that are associated with it as follows:

# vgimport -m /tmp/mapfile /dev/vg02 /dev/dsk/pv_name1 /dev/dsk/pv_name2 ......

Note: The "pv_name" is a list each of the block device(s) corresponding to the new hardware path(s). The new device files should have been created during system start up. Use: ioscan -fn to get the new device file names if needed.

7) Activate the VG.

# vgchange -a y /dev/vg02

8) Backup the VG configuration.

# vgcfgbackup /dev/vg02

[Helen French]

Hi Dave:

vgcfgbackup/vgcfgrestore is best when you need to re-create the VG information on a new/replaced hard disk/LUN. While doing a cold install you are not going to write anything to the AUTORAID array disks/LUN, which have your data. The installation will be on the root hard disk which resides ( normally ) in the server.

You can just 'vgexport' the VGs except /dev/vg00 with -m and -s options before the install. After installation, import it back to the new system with 'vgexport' using -m and -s options.

There are lot of threads in this forum about this topic and you can easily search and browse it. Make 2 ignite recovery tapes and full system backups before doing the install.

Good luck !

HTH,
Shiju

[Helen French]

oops...

the import command is - vgimport

typos =))

HTH,
Shiju

[Mike_305]

Hi,

I have to agree with Chan???s reply. I have also done this using vgexport and vgimport and works very well. One additional thing I do all the time is copy my /etc/passwd. Group and hosts files so I don???t have to create the entire user manually.

Thanks,

Mike

[Mike_305]

Hi,

One thing I forgot to put is use the syntax for vgexport.

vgexport -p -v -s -m /tmp/vg01.map /dev/vg01

If you use this then you don't have to worry about specifying which disk. It keeps track of the volume group information using vgid from Disk Array and after cold install do vgimport.

THX - Mike

[Darrell Allen]

Hi Dave,

You should save a copy of /etc/fstab so you'll be able to easily modify it after your cold install.

Be sure you have a couple of good Ignite backups in case you have to revert back to 10.20. You'll probably find you want to compare some config files or perhaps even restore some from the backups after you install 11.x.

vgexport's and vgimport's -m and -s options make the process a piece of cake. Just don't install anything on any of the disks used for vg02.

Darrell

[Darrell Allen]

I see I only referred to vg02. Obviously all this refers to whatever VGs you have.

Darrell

[A. Clay Stephenson]

While the -s vgexport/vmimport makes things easy; the downside is that all of your 12H LUN's primary paths will be through Controller X and Y will only be used as alternate for all LUN's. If you want your 12H to operate more efficiently and utilize both external SCSI paths, you will be better advised to do your vgimport and specify the SCSI paths explicitly. The order in which you list the pv_paths determines which is the primary path and which is the secondary.

[Darrell Allen]

Very good point Clay. If you are using PV links, "vgimport -s" doesn't care what path was primary. The first path found to a lun will be the primary path.

It may be a good idea to save "vgdisplay -v" output for the VGs you plan to import.

If by chance your primary and alternate paths are reversed you can use "pvchange -s /dev/dsk/c#t#d#" to make the primary path the one you want.

Darrell

[Darrell Allen]

Even though it's a month later, I need to correct my last reply for future reference.

"pvchange -s" will change which path the disk is accessed by. However, this is only temporary. Once the VG is de-activated and re-activated, it reverts to the original paths.

To permanently switch the paths, vgreduce the primary path from the VG then vgextend it back in.

Example:

/dev/dsk/c4t5d1 is the primary path / link
/dev/dsk/c3t5d1 is the alternate path / link

# vgreduce vgname /dev/dsk/c4t5d1
# vgextend vgname /dev/dsk/c4t5d1

c3t5d1 is now the primary and c4t5d1 is the alternate.

I apologize for providing mis-leading "dis-information".

N/A please.

Darrell