??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" <[EMAIL PROTECTED]> To: <[email protected]> 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
