Hmm.. seems like I'm not explaining the my whole story here. The purpose for this tinkering of admin schedules is to be as efficient as possible so I'm examining the repercussions of adjusting the expiration schedule. We do in fact have a larger SATA pool we use for storing about a week's worth of backup data. In addition to that, a few of our retention policies limit backup versions to only 2 or 7 versions. Given these parameters, there may be instances where there is expired data on the SATA pools (devclass file). I'm trying to avoid data movement (SATA to SATA or SATA to TAPE) of expired data which may still be processed if expire inventory has not yet run. Seems like there would be little benefit in doing so. However, we may be running into a situation from noon to 5pm where the only thing I will be allowed to do is reclamations or expirations. Which is why I wanted to do migrations last. Well, back to the drawing board.
SF -----Original Message---- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Thomas Denier Sent: Friday, August 28, 2009 11:24 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Daily TSM maintenance schedules I don't understand what benefit to hope for in terms of 'processing actual unexpired data'. You seem to be described a system in which disk storage pools are short-term buffers for incoming backups. With this usage pattern, disk storage pools will contain few inactive backup files of any sort, and no backup files that have been inactive long enough to be candidates for removal by an expiration process. The 'expire-reclaim-migrate' version of the proposed change will cause reclaimed volumes to revert to scratch or 'Empty' status a few hours earlier than they would under your current policy. The 'expire-migrate-reclaim' version of the proposed change would eliminate even this marginal advantage.
