Collocation is wonderful for onsite primary pools. But what about during a
disaster where you lost your lovely collocated primary pools?

The usual copy pool method, where you take tapes offsite each day, mixes
your data from all machines each day on the tape, or tapes, you haul
offsite. So that kind of storage pool will take forever to restore from if
you need to do full restores of a bunch of server; billions and billions of
tape mounts.

I looked at using server-to-server copy pool backups, via the new ADSM V3
"virtual volumes" feature. I had *HOPED* that the filespace name of the
archive data that ends up in the remote server's storage pools would be
something like "AdsmServerName,NodeName,FilespaceName,TimeStamp" -- for
example,
"ADSMSERV1.IBM.COM,ORACLE1.ITDEPT.IBM.COM,/u01,1998/06/12-16:34:42-001"
 Then, you could just enable COLLOCATE=FILESPACE on the remote server's
storage pools. Presto, you'd have collocated data, and restores would be
wonderful.

But unfortunately, I found that the real filespace name it uses is always
(at least in the cases I've checked) "ADSM.SERVER".  It encodes the node
name, timestamp, etc. in actual file names in its filespace which is of
type ADSM_FS.

Does anybody have any suggestions for how to have a disaster recovery site
that has a collocated storage pool for speedy recovery?

--
John Dawson <jdawson AT tkg DOT com>
John Dawson <jdawson AT tkg DOT com>