> 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?
Yes.  Normally when the servers receives the data from the client, this data
is placed on disk and later migrated to disk.  You can configure TSM so it
also places the data in the offsite storage pool.  Most of the time the data
is placed on disk and the offsite storage pool is tapes.  As a result, when
the offsite storage pool can not follow the data stream, TSM will skip the
extra copy to the offsite storage pool.  So TSM _can_ do this, but most of
the time will not be able to do this.
When you do a copy storage pool command later on in your DR plan, all the data
that is not in the copy storage pool is copied from primary to offsite
storage.  So all the data can be placed offline.

> 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.
Because the disk -> tape stuff, making that extra copy simultanuous is never
going to work because tape is too slow.
Idem voor copying during migration.  You copy from disk to tape and you want
to do this as fast as possible so the disks are empty enough to receive the
data from the clients.  So no tape drives left for the extra copy to the copy
storage pool.  TSM can _not_ do this.

Sata disks are cheap.  Most of the time we use a few TB of SATA disks as the
primary storage pool.  You can mix the primary pool with tapes.  Sometimes,
even the offsite copy storage pool is disk.  When the primary storage pool is
disk (of at least enough to hold the daily backup), you don't need the tape
drives for the backup.  So the tape drives are free to make the offsite copy
and you can make the offsite copy every hour.  Why not?  Each time the
offsite copy is made, the remaining data is copied.  And TSM has no problem
running multiple commands at the same time.

> 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.
Not really.  I'm always pleased to see that making the copy storage pool is
maxing out everything.  So by the time the cients ends the backup at 08:00,
the copy storage pool is updated.  When the IT staff enters and had the time
to drink a cup of coffee, the tapes can be brought offsite.

> 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?
Because TSM is a central backup solution.  1 servers has all the storage.
That's how it is designed.

> 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?
Backupsets are complicated because there are some possiblities:

- the backupset is defined on the TSM server, so the TSM server has a table of
contents in the database and can mount the backupset:  you can restore on the
client from the backupset, the TSM server will mount the backupset and send
the files.  This is the same as a regular restore.

- the backupset is not defined on the TSM server: after a while, the table of
content is erased from the TSM server to free the space in the database.  You
can reread the whole backupset so the TSM server has the table of contents
(this can take some time) and then you have the same situation as the
previous point.

- the backup set is send to the client (this can be a tape or a file): you can
restore from the client with the GUI but in this case you access the local
mounted backupset (no TSM server is needed).  You can restore files after
reading the table of content of the backupset.


Stef