I lost an entire VG in a similar way last week, this is how I recovered it. I called IBM support, their answer was to restore
from tape backup (which I didn’t have), but they did point me to the readvgda command (see below). The LVM redbook vol. 2 did the rest.
As always, *use this at your own risk!!*
1. Use the (undocumented) readvgda command to get the detailed VGDA from one of the disks, e.g. “readvgda /dev/hdisk3”. I’d
advise you to do the same on a disk that *didn’t* fail and compare (a disk that didn’t fail might be a more reliable source). Check the list of PVIDs and make sure they are all present and accessible by the system (no hardware problems).
Save the readvgda output in a file, you will need it if you make a mistake later and want to start over.
2. Among the readvgda output is the layout of each LV on the PVs, from which you can construct LV map files for the mlkv command.
3. You will also need a good copy of the /etc/filesystems file, unless you remember the original LV mount points and filesystem types.
4. When you have all the LV map files, export the volume group and re-create it on the original PVs, with the original PP size:
mkvg -f -y vgdvd -s 1024 hdisk3 hdisk4 …
5. Re-create each LV using the map files. I assume here that your filesystems were jfs (change accordingly if you had jfs2):
mklv -y loglv02 -m <loglv02_mapfile> -t jfslog vgdvd <numlp>
mklv -y data1 -m <data1_mapfile> -t jfs vgdvd <numlp>
…
6. Restore /etc/filesystems or add the missing stanzas manually.
*Do not mount the filesystems yet.*
7. For each filesystem LV, update the LVCB with the log and label
information:
chfs -a log=/dev/loglv02 <mountpoint>
chlv -L <mountpoint> data1
…
8. Run a fsck on each filesystem. This is the critical step – if the command fails because it can’t find the superblock, then the LVs were not re-created correctly, stop and check your map
files. If the jfslog LV was not re-created correctly, fsck will not be able to replay the log and you will probably lose some data. Consider stopping and double-checking the map files before answering yes to the fsck “fix” questions. Also, if filesystems were active at the time of the crash, fsck might find unrecoverable errors on some inodes or blocks, your only option here is to fix these errors at the risk of losing some inodes (the price for not having a tape backup). If errors were fixed, re-run fsck until there are no errors.
9. When fsck run without errors on each FS, mount the filesystems. If errors were fixed during fsck, check the lost+found directories, they might contain missing files or directories you can salvage.
http://unix.derkeiler.com/Newsgroups/comp.unix.aix/2006-04/msg00174.html
Comment