ADSM-L

Re: Deleting MS-SQL backups

1998-09-21 22:48:15
Subject: Re: Deleting MS-SQL backups
From: Bruce Elrick <belrick AT HOME DOT COM>
Date: Mon, 21 Sep 1998 20:48:15 -0600
Just thought I'd put my vote in for an "obvious" solution...
see below.

Del Hoobler wrote:
>
> Fred,
>
> Bruce is correct. For the SQL and Exchange Agents...
> when you "delete" a file, it really just inactivates
> it on the ADSM Server.  Then it falls into the
> expiration policy management class settings.
>
> Take a look into the archives of this list to see
> how some customers are solving the problem.
> Specifically, look at an append by me,
> hoobler AT us.ibm DOT com on 6/18/1998 at 07:46:21.
>
> I appended an example of perl script that
> Phil Chissell shared with the user community.
> He has written a perl script that allows him to
> schedule a "deletion" of old backups.  This, along
> with the correct management class settings, will
> give you the desired results.
>
> We know this isn't the nicest way to solve the
> problem and we are looking at ways to make it better.
Allow SQL Server backups and MS Exchanges backups to go
to archive copy groups instead of backup copy groups
(e.g. ... -usearch -archmc=30day ...).  Then the server
can automatically expire archive versions.  People can
use a retain version nolimit to mimic the current backup
based scheme where the agent needs to explicitly delete
the version.  Since you can allow a client to delete
archives (by default), an agent can delete an archive
version early.

The only complication is that with a switch like "-usearch"
people may use it one time and not another, so the agent
may have to be "smart" and show backups that have been
sent to both backup copy groups and archive copy groups
when you query the ADSM server for what it has.  The
Agent GUI might show which backup versions are "backup" and
which backup versions are "archive", and for the latter show
when they are due to expire.

Those are my two cents....
Bruce

>
> Del Hoobler
> ADSM Agent Development
>
> ----------------------------------------------------------------------
>
> >> Two things come to mind.
> >>
> >> Does the backup copy group for the management class to which the backups
> >> are sent to have retain-only-version set to 0?  If not,  the "last good
> >> copy" of a "file" (the active version which is inactivated when a file
> >> is deleted from the fs) is retained for that number of days (60 by
> >> default).
> >>
> >> Also, my understanding of how the server operates is that when you
> >> delete the file-version with the agent, the version gets mark inactive
> >> (as the last active version).  Later, when expiration runs, the policy
> >> of the management class is used to determine that yes, that version
> >> should be deleted from the database.
> >>
> >>
> >> Cheers...
> >> Bruce
> >>
> >> Fred Johanson wrote:
>
> >
> > I've a user who is using the MS-SQL connect agent.  Works find from a
> > schedule and everything.  But getting rid of old copies is a problem.  the
> > user a\has sat at the keyboard and done a delete according to the
> > documentation, but when I do a Q OCC, the number never diminishes.  (I've
> > got the same problem with SQL-Backtrack, but that's for BMC.)  Has anyone
> > out there figured out a way to automate the deletion process that actually
> > gets rid of old copies?  Any help will be appreciated.
<Prev in Thread] Current Thread [Next in Thread>