Re: [ADSM-L] expiring older versions of files

Hello Andrew,
      Thank you for clarifying this for me. I agree.  I am going to create
a new management class and try it this way.

Avy Wong
Business Continuity Administrator
Mohegan Sun
1 Mohegan Sun Blvd
Uncasville, CT 06382
ext 28164




             Andrew Raibeck
             <storman AT US DOT IBM.C
             OM>                                                        To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Re: [ADSM-L] expiring older
                                       versions of files

             06/03/2007 12:24
             PM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






Hello Avy,

Backup versions are bound to a given management class. The backup
copygroup for that management class dictates the retention of the data
based on the VEREXISTS, VERDELETED, RETEXTRA, and RETONLY settings.

So if you have these settings configured for 7-day retention, then the
deletion should take care of itself (provided that you run inventory
expiration on a regular basis).

For example, the following settings will allow you to keep up to 7 days
worth of backups (unlimited versions, but no version older than 7 days):

VEREXISTS=NOLIMIT
VERDELETED=NOLIMIT
RETEXTRA=7
RETONLY=7

Also note that TSM *always* keeps the latest backup version as long as the
file exists; this would be the "active" backup version. This is regardless
of the above settings, which apply only to "inactive" versions (versions
that are not active).

With all of the above in mind, the members of this list could provide much
better aid if you could provide more details of your scenario, and how it
might vary from the above rules.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html


The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2007-06-02
16:23:54:

> Richard.
>         Sorry I did not make it clear earlier. Basically we only want to
> keep 7 days worth of the db filles(the most recent 7 days), any files
more
> than 7days old can be deleted. Is there a way to go back into the backup
> pools to clean house?
>
> Avy Wong
> Business Continuity Administrator
> Mohegan Sun
> 1 Mohegan Sun Blvd
> Uncasville, CT 06382
> ext 28164
>
>
>
>
> Richard Sims <rbs AT BU DOT EDU>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 06/02/2007 10:03 AM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: [ADSM-L] expiring older versions of files
>
>
>
>
>
>
> On Jun 2, 2007, at 1:21 AM, Avy Wong wrote:
>
> > Hello,.
> >          Recently we have decided to change the backup of a db file
> > from
> > forever to 7days only. When I do a 'q backup \ora_secure_db\*
> > -subdir=yes', I see many older versions of the db file backups exist
> > in the backup pool. Is there a way to expire the unwanted versions? Is
> > there a way to do it based on dates? Thank you.
>
> Did you perform the necessary VALidate POlicyset and ACTivate
> POlicyset to commit the TSM server retention policy changes?  And, of
> course, EXPIre Inventory needs to run regularly, to completion.
>
>     Richard Sims
>
>
>
>
**************************************************************************************************

> The information contained in this message may be privileged and
> confidential and
> protected from disclosure. If the reader of this message is not the
> intended recipient, or
> an employee or agent responsible for delivering this message to the
> intended recipient,
> you are hereby notified that any dissemination, distribution, or copy of
this
> communication is strictly prohibited. If you have received this
> communication in error,
> please notify us immediately by replying to the message and deleting
> it from your
> computer.
>
**************************************************************************************************



**************************************************************************************************
The information contained in this message may be privileged and confidential and
protected from disclosure. If the reader of this message is not the intended 
recipient, or
an employee or agent responsible for delivering this message to the intended 
recipient,
you are hereby notified that any dissemination, distribution, or copy of this
communication is strictly prohibited. If you have received this communication 
in error,
please notify us immediately by replying to the message and deleting it from 
your
computer.
**************************************************************************************************