It can be thought of as the "just in case" backup operation.  You may
well have had migrations.

I'm not sure if data that gets migrated, cached or not, is backed up
from disk or from tape.  I'm thinking that if it has been migrated and
is cached, the backup will occur from the nextstgpool in any event.
Perhaps an IBM dude can clear that up.  Or Mr. Sims. 


Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David Bronder
Sent: Tuesday, October 02, 2007 4:10 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] BACKUP STGPOOL puzzle: why so much from tape?

Nick Laflamme wrote:
>
> If the disk pools are sized correctly, migrations should occur once a 
> day or less, after the daily backup window has ended. The storage 
> pools should be backed up after migrations are "encouraged" (by 
> updating storage pools with new migration thresholds). We backup the 
> disk storage pools and then the one large tape storage pool.
>
> What I don't understand is, why does anything on tape get backed up to

> the copy pool?
>
> Anything on tape should have been resident in the disk pools when they

> were backed up. We don't migrate everything in the disk pools to tape,

> but even objects that were migrated to tape remain resident in the 
> disk pools until forced out by new backups from clients. But when I 
> query the SUMMARY tape for STGPOOL BACKUP activities, backups from 
> TP-ALL to CP-ALL are quite large.

If you don't have caching enabled on your disk pools, any data migrated
to tape will not remain resident in the disk pools.  If your
disk-to-tape migrations complete before you back up the disk pools to
the copy pool, all the migrated data will live only on primary tape.

You should back up your disk pools, then your primary tape, then kick
off the migrations.

If you _do_ have caching enabled on the disk pools, it's still possible
for some data to get migrated to tape and not remain cached on disk,
based on thresholds and natural variations in amount of data sent by the
clients from day to day.

(P.S. In TSM 5.3, you don't have to fiddle with the migration thresholds
anymore.  Use the "migrate stg" command instead.)


> Is this a result of aggregation of objects on sequential media, that 
> somehow TSM doesn't recognize that everything in each aggregate has 
> been backed up, so the aggregate itself doesn't need to be?

That shouldn't be the case.


--
Hello World.                                    David Bronder - Systems
Admin
Segmentation Fault                                     ITS-SPA, Univ. of
Iowa
Core dumped, disk trashed, quota filled, soda warm.
david-bronder AT uiowa DOT edu