Very interesting that things worked well !
(I expected since they were both Unix platforms, but wasn't going to bet the
farm)

Let's look at how TSM acts currently...
IF you have a copy pool (say local to the server) and a primary volume is
bad, and a client requests data from that volume, TSM will pull it from the
copy pool volume with no intervention at all. (last time I tested, this was
the case)
OK, an offsite copy pool... just a backup storage pool that you checkout the
volumes, take them offsite, and update the volume(s) with a status of
"offsite".

Now, we have at a remote location a similar atl with the same drives (can't
get around that) and a server on which the tsm db will restore to...
remember, tape volumes are bound to a device class
        device classes have an associated library (when this applies)
YES, you may have tape volumes with absolutely no physical tape devices
defined to TSM (and no libraries)
So now at this remote location you bring up TSM and it may or may not find
what it thinks is the proper library...
And this library has had the copy pool volumes placed in it, and the library
itself just knows them as being in "insert mode"
Now the existing library(ies) within TSM... Who cares, delete the library
definition(s)
You (famous last words) now should be able to perform a "define library
blah" to create a real library definition to the physical library attached
to your current system, update your device class to reference this library
definition, define the existing drives to this library... you are now just
about ready to go !
Get a list of all the volumes in the copypool (q vol stg=blahcopypool)
        for each of these volumes, issue a "checkin libvol" command to check
them in private
        update the volumes to be readwrite (also update all other, not at
this site, volumes to be unavail)
Now if a client connects and attempts to pull data from the server, it
should automatically go to the copypool volumes.
I would not bother trying to recreate primary pool volumes (would take to
long if this is a real disaster situation)
Once client boxes were recovered, you could continue to move towards turning
this current environment into a full production backup server again OR
towards getting in new hardware for such...
(just my random thoughts.../ standard disclaimer :-| )

Dwight