ADSM-L

Re: [ADSM-L] Daily TSM maintenance schedules

2009-08-28 15:23:14
Subject: Re: [ADSM-L] Daily TSM maintenance schedules
From: Howard Coles <Howard.Coles AT ARDENTHEALTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 28 Aug 2009 14:19:11 -0500
Correction, it's "marked for expiration" and it is still recoverable,
until the "Expire" process runs and removes it from the Database.  I
know this from experience, as we disable our expiration process for a
few days due to a server failure, and once due to a legal request.  The
Expire Process actually removes the DB entry for that version of the
file.  

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Wanda Prather
> Sent: Friday, August 28, 2009 11:21 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Daily TSM maintenance schedules
> 
> Agreed.
> "expire inventory" is actually something of a misnomer.
> 
> If you have your retention set to 14 versions, and someone takes the
> 15th
> backup, the oldest version expires right then, you can't get it back.
> That
> type of "expiration" takes place, no matter whether EXPIRE INVENTORY
> runs or
> not.
> 
> The EXPIRE INVENTORY is what updates the %utilization on your tapes,
> based
> on the files that have expired.  I think it also does some cleanup to
> make
> space in the DB for the expired files reusable.
> 
> So you want to run EXPIRE INVENTORY before reclaim.
> But I don't think it affects your migration in any way.
> 
> W
> 
> On Fri, Aug 28, 2009 at 11:23 AM, Thomas Denier <
> Thomas.Denier AT jeffersonhospital DOT org> wrote:
> 
> > -----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.
> >