HPUX 11.31 – LUN Expanded at Storage Side, Used vgmodify to Reflect in LVM – Backup/Revers

[coke]

Looking for some expert insights and suggestions here.

Background:

• OS: HPUX 11.31

• LVM version: 1.0

• Volume group and mount are part of a ServiceGuard (MC/SG) package

• The storage team expanded the underlying LUN (100Gb to 150Gb) - Primera 3PAR

• The volume group has only 1 PV and 1 LV

• No new LUNs were added, just a resize of existing one

What I did:

• I used vgmodify (no pvresize) to make LVM aware of the increased LUN size:

  vgmodify -v -a -E /dev/vgname

• Then extended the logical volume:

  lvextend -L 150000 /dev/vgname/lvol1

• And finally grew the VxFS filesystem:

  fsadm -F vxfs -b 157228800 /mount/point

Everything worked perfectly and the new extended filesystem is live and visible in bdf.

---

 My Question: What backups should I have taken before vgmodify, and if I ever wanted to undo this — how would I do it?

P.S. vgmodify initially failed due to Max PE per PV limit. I resolved it by reducing Max PV from 16 to 10, which allowed the LUN expansion to proceed.

[Bill Hassell]

I would backup the files LV on this VG, and save a listing of vgdisplay -v and lvdisplay.
Also, in case you are using a raw database manager such as Informix, make a backup using that database's tools.

If for some obscure reason the VG records became corrupted, you can then replace the bad VG deifinitions with the display listings, then restore the data,

[zayanhani]

expanded the LUN and then used vgmodify to update the LVM. It worked fine, but I always get a bit nervous about the backup part. Did you take a full VG backup before running vgmodify, or do you just rely on the storage side snapshot? am trying to understand the safest rollback method if something goes wrong. Also curious if anyone has tried doing this setup from a remote desktop hosting environment  does it slow down LVM operations at all?