Thanks so much for all the responses.  I'd like to reply to just a few
responses for clarification.

Regarding simultaneous copies, Howard Coles said:
>I have had migration happening while
>backing up to a copypool, while a client was trying to fill up the disk
>pool and TSM handled it just fine.

and Paul Zarnowski said:
>I don't really see the need to write to two devices simultaneously as the
backup
>data is coming in over the network from clients

I'm not talking about migration and backups happening at the same time, or
even multiple migrations happening at the same time.

First, let me verify what I was told TMS _could_ do.  I was told that during
the initial backup (if you went straight to tape, such as with a large
dataset), TSM could write to two tape drives simultaneously, making two
copies in the time it takes to make one.  Is that part true?

I was told that, while it could do that during backups, it couldn't do it
during migration/copies.  I'm talking about one process reading from the
disk pool, simultaneously putting a copy of each file in the dataset into
the primary tape pool and in the copy pool.

When used in NBU and disk staging, it means you can back up once to disk,
then copy once to tape, but when that copy is done, you have an onsite copy
and an offsite copy, but you only had to do one operation.  It would seem
that doing it twice would take longer.

Regarding the TSM server having to do all migrations/copies, Howard Coles
said:
>Why would you want the client to be worried about that?
>The server is the box that you want
>handling the data once its handed off so that the client can go about
>its main purpose.

NBU has the concept of media servers, which are subordinate to the master
server.  The master server _controls_ and creates database entries for all
operations, but the I/O of these operations can be done on these subordinate
servers, allowing you to scale a single NBU environment to beyond the
capabilities of a single NBU instance beyond that of a physical server.

TSM seems to be the opposite, as you sometimes have multiple instances of
TSM in a single physical server.  Why is that?

Howard Coles said:
>You use the TSM GUI and/or command line to
>do all the restores whether it be a backup set, or a backup from the TSM
>server.

But the contents of the backup set aren't in the TSM database, right?  Isn't
that the point of the backup set, to make an archive of a bunch of files
that aren't tracked in the database, and that can be read outside of TSM?
So if the contents of the backup set aren't in the database, how could you
do restores the same way as you do with regular backups?

Thanks again for my overlooking my ignorance.  I'm just trying to understand
how I would architect a new system based on TSM.  How do you recommend
someone mostly new to TSM moving forward with such a thing?