On Sep 26, 2006, at 7:58 AM, Adrian Compton wrote:
To keep Tivoli running we have had to exclude this FS (/backup/) from mounting, but are now running without the DISKPOOL. Hence my question about the OVERFLOW storage pool automatically becoming the recipient in place of the DISKPOOL without having to change any parameters.
If your TSM server came up, it should see all the DISKPOOL volumes missing, and so all incoming data should then go to the next level of the storage pool hierarchy, assuming that's in writable condition and has space. You might formally perform an Update Stgpool to mark it Unavailable until such time as its original volumes are returned to service, or (RLV) substitutes might be put into place. The more awkward situation is outgoing data, which is to say that any data which arrived in the backup disk pool but which is not represented in the overflow area is unavailable for restorals - something which needs to be publicized to the affected client community before they attempt to restore data and find some or all of it missing. Richard Sims