ADSM-L

Re: [ADSM-L] Daily TSM maintenance schedules

2009-08-28 11:25:31
Subject: Re: [ADSM-L] Daily TSM maintenance schedules
From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 28 Aug 2009 11:23:46 -0400
-----Sergio O. Fuentes wrote: -----

>I'm revising my TSM administrative schedules and wanted to take an
>informal poll on how many of you lay out your daily TSM maintenance
>routines.  Functions I'm talking about here include:
>
>BACKUP DISK STGPOOLS
>BACKUP TAPE STGPOOLS
>BACKUP DEVCONFIG
>BACKUP VOLHIST
>BACKUP DB TYPE=FULL
>PREPARE
>DELETE VOLHIST
>MIGRATE STG
>EXPIRE INV
>RECLAIM TAPE
>RECLAIM OFFSITES
>CLIENT BACKUP WINDOW STARTS (back to top)
>
>The above sequence is roughly how I handle our maintenance and is
>based off of the IBM Redbook (sg247379) TSM Deployment Guide for 5.5
>(page 300).  I'm seriously considering altering it in this manner:
>
>BACKUP STGPOOLS
>BACKUP DEVCONFIG
>BACKUP VOLHIST
>BACKUP DB
>PREPARE
>DELETE VOLHIST
>EXPIRE INV
>RECLAIM
>MIGRATE STG
>CLIENT BACKUP WINDOW STARTS (back to top)
>
>The key difference here, is that I'd be expiring right after the DB
>Backups, and reclaiming space before migration.  I feel that this
>would be more efficient in terms of processing actual unexpired data
>and data storage (since reclamation would have freed up storage
>space).  I would be concerned that migration would run in perpetuity
>in cases where the migration window runs into the client backup
>window.  Therefore, I might have migrations run before reclamations.
>Does anyone else expire data right after your DB backups on a daily
>basis?  Suggestions from anyone?  Thank you kindly.

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.