Paul - The HSM redbook "Using ADSM Hierarchical Storage Management"
       (SG24-4631) is a bit old now, but nicely explains a lot of things about
using HSM, including your recovery issue.

>If I migrate the files to a spacemgtpool and then use a threshold on that
>pool to spool files off to tape, and I choose the "migrate only if backup
>exists" option (assuming I backup the file first) will I end up with 2
>copies of the file in the tape pool? This obviously is crucial for sizing.

Here are some notes I wrote a while ago for my own site's reference, which
elaborate on the number of file image instances...

    HSM is more expensive in terms of ADSM server space than an ordinary file 
system

        Consider the simple case of an ordinary file system with static files...
        One instance of the file exists on the client file system.  Backup then
        creates a second instance in the server Backup Storage Pool.  Good ADSM
        administration will further perform a Backup Stgpool operation, which
        results in a third instance of the file in the Copy Storage Pool.

        Now consider an HSM file system with static files...
        A file of significant size will typically have been migrated, leaving a
        stub file in place on the client file system: this results in an
        instance of the file in the HSM Storage Pool.  Good ADSM administration
        will further perform a Backup Stgpool operation, which results in a
        second instance of the file in the Copy Storage Pool.
        HSM file systems should also be backed up, which results in a third
        instance of the file, in the Backup Storage Pool.  And, again, good ADSM
        administration will further perform a Backup Stgpool operation, which
        results in a fourth instance of the file in the Copy Storage Pool.

        Thus, with ordinary file systems there will be two images of the file in
        server storage pools whereas with HSM there will be typically be four
        images of the file in server storage pools - twice as many.

        An additional issue with HSM is that it does not participate in ADSMv3
        Aggregation: every file is its own entry in the database, rather than
        being within an Aggregate of files such that the server can more
        efficiently handle the data and catalog it in less space.

Advisory: it can be deadly to use HSM via NFS.  We've had to do this under
AIX, and have suffered much as a result.  The problem is that NFS is like a
pipeline through the kernel, and is poorly architected for handling blockages.
Example: Data is being fed to the HSM file system over NFS, but the file
system gets full.  HSM has to perform reconciliation - which it does
ploddingly slowly - and creates a blockage that causes your AIX system to
clog.  Or HSM has to migrate its storage pool data and no tape drive is
available (given that HSM migration is a low-priority task in TSM): it sits
there waiting indefinitely for a tape drive while the HSM file system is
blocked, and everything upstream gets blocked as well, and AIX goes bananas.
Suffice to say that, though it has lots of potential value, HSM is awfully
clunky, and is the seldom-mentioned member of the TSM family because of it.

    Richard Sims, BU