Hot Diggety! Prather, Wanda was rumored to have written:
> 1) Is there any particular reason to set a max file size for a disk stgpool?
>    (Assuming a setup where disk stgpool will migrate to tape stgpool)
>
> >>>The rationale for setting a max file size goes something like this:
>
> Suppose you have mostly small files backing up, and just a few humongous
> ones:  say you have a 50 GB disk pool, and one data base that backs up 30 GB
> per night.

[...snip great explanation...]

Prevent tape thrashing...makes sense. Same reason why I'm not going to
enable caching... would speed up restores if I used HSM for certain
frequently accessed data or for a big (and recent) restore, but 99.999% of
the time, the tape drives are going to be busy writing out tapes. Restores
are very rare, so no sense in causing unnecessary head movement/slow media
access; I'll just take that extra delay hit at restore time.

I know my way around news servers (which is a pretty large 2 TB+ database)
and optimize it to prevent disk thrashing, so the idea of preventing tape
thrashing (cpu/mem always faster than slow tape access = big hit in perf)
makes sense.

> 2) Should the TSM server have its own stgpool for backing up itself?
>
> >>>No need.

Ok.

> >>> Yes.  If you are using the GUI, look at the box at the top of the
> window.  INCREMENTAL (in most cases use "incremental complete") just backs
> up changed files.  Pull down  ALWAYS BACKUP instead to force a backup
> whether changed or not.  If you are using the command line, it's "dsmc
> incremental" vs. "dsmc selective".

Ahh-ha!

> Remember though, if your management class/backup copy group sets a limit on
> the number of versions you retain for files, that doing forced backups

Makes sense.

Copy pools used to make copies of whatever primary pool... so if I attach
one to all tape stgpools, it will get a copy of data on all the tapes.

So in essence, I need 2x number of tapes to cover any given quantity of
data; one pile for on-site, and one pile for off-site.

That makes more sense. Don't know why that didn't come across so clearly
in the documentation. ;)

I guess the docs talked more about how to do things rather than what/why,
or glossed over the latter. Not uncommon for authors that knows the stuff
so well they've forgotten what it looks like to a newbie ;)

-Dan Foster
IP Systems Engineering (IPSE)
IP Systems Engineering (IPSE)
Global Crossing Telecommunications