ADSM-L

Re: [ADSM-L] BACKUP STGPOOL puzzle: why so much from tape?

2007-10-02 18:01:24
Subject: Re: [ADSM-L] BACKUP STGPOOL puzzle: why so much from tape?
From: Larry Clark <lclark01 AT NYCAP.RR DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 2 Oct 2007 17:58:59 -0400
??What I don't understand is, why does anything on tape get backed up to
the copy pool?

I'd look at your admin scheds. There needs to be an explicit backup stg
<tape pool> <tape copy pool>

My guess is that was never set up.

----- Original Message -----
From: "Nick Laflamme" <nick.laflamme AT NIST DOT GOV>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, October 02, 2007 4:36 PM
Subject: [ADSM-L] BACKUP STGPOOL puzzle: why so much from tape?


Our TSM server has several storage pools on disk, DP1-DP6. There's a
primary sequential storage pool, TP-ALL, and a sequential copy pool,
CP-ALL. Each of the six disk pools migrates to TP-ALL, and all of the
disk pools as well as TP-ALL are backed up to CP-ALL.

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.

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?

TSM 5.3.4.2 on AIX, if it matters.

Thanks,
Nick