> Ok, will tivoli handle rebuilding the file systems in this case?
< snippage due to top-posting >
No, TSM is for data, not the FS/LVM structure.
The only way to get back the FS/LVM structure is via importvg.
Caveat, if no exportvg has been run then the ODM should still contain
the names of the LVs entries for the other VGs which you can recover
odmget -q parent=$VG_NAME CuDv
and then you could get the details of the LV with:
odmget -q name=$LV_NAME CuAt
With this data you could then run exportvg to clean out the ODM and
/etc/filesystems and then manually rebuild your VGs. Note, the size of
the LVs in this output is in multiples of PP (physical partitions) and
if you don't know what that was set at you'll just have to take a 'best
guess' based on the disk/LUN size, try 16M for 9G disks and 32M for
For future reference:
When using a 3rd party product to handle data backups my preferred
1) ensure that the backup/archive client is part of rootvg
2) create archives of other VGs LVM/FS structure using savevg with an
exclude file of "/" to backup the LVM/FS structure to a file stored in
rootvg (I store them in /var/savevg).
This gives you a layered method of handling both data & disaster
recovery, ie, when things go totally wrong you rebuild the system from
the mksysb, rebuild the other VGs from the savevg archives in
/var/savevg then restore the data using the backup/archive client.