Re: SQLBacktrack/Sybase and expiration.

Hi David.  SQL BackTrack generates new "names" each time it does a backup,
so ADSM's file versioning is basically nullified since versioning is based
on files with the same name.  Setup the SQL Backtrack generation values to
what you want.  When those generations expire, SQL BackTrack will tell the
ADSM server to "delete" those files.  If you use the recommended  mgmt.
class settings, this deletion will take place at the next ADSM expiration
process.

Key item to remember here:  SQL BackTrack controls number of versions kept
and uses ADSM to store them.  You can setup ADSM to keep them longer, but
SQL BackTrack will not be able to make use of them without some fancy
footwork.

Paul L. Bradshaw                                phone: (408) 617-9125
BMC Software (previously DataTools)             fax: (408) 617-9101 or 9162
965 Stewart Dr.                                 mailto:paulb AT datatools DOT 
com
Sunnyvale, CA 94086                             http://www.datatools.com

----------
> From: David Wilshire <DWILSHIR AT LENSCRAFTERS DOT COM>
> From: David Wilshire <DWILSHIR AT LENSCRAFTERS DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: SQLBacktrack/Sybase and expiration.
> Date: Monday, June 16, 1997 7:04 AM
>
> Here's a question for those of you that are using SQL Backtrack's
> OBSI module and ADSM for doing backups...
>
> When I originally switched our backups from 4mm tape to ADSM,
> we started with level 0 backups daily, unlimited generations, to
> our default management class (5 versions exists, 1 version
> deleted, 365 days each).  Our thinking was that only 5 versions
> would be retained on the ADSM server.
>
> However, we are saw that nothing was being expired out, and our
> storage pool occupancy continued to grow.
>
> I called DataTools tech support, who recommended that I set up
> a new management class for SQLBacktrack files.  The values
> recommended were:  1 versions exists, 0 versions deleted, 0
> days each.  Also, the include-exclude file now contains the
> stanza, "include /FILESPACE_TAG:*/.../* MGMTCLASS".
>
> I've run backups several times already, thinking that the backup
> files would then be bound to the new management class and
> that old versions would be deleted, but occupancy continues to
> grow.
>
> I have to backup my storage pools for offsite storage, but I've got
> about 94GB in old backups I'd rather not save.  It's a waste of
> tapes and a waste of time.
>
> Has anyone run into this before?  Is there a safer way to delete
> these old backups short of deleting the filespaces and starting
> over?
>
> Thank you in advance for your assistance.
>
> David Wilshire, Systems Administrator
> LensCrafters, Inc.
> dwilshir AT lenscrafters DOT com
> (513)583-6801
> "Knowledge Is Support"