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
|
