And to add to Tom's excellent response, if you want to be able to use the
previous database backups, make sure your reusedelay on your tape storage
pools is set appropriately.  If you use a database backup from 2 days ago,
make sure the tapes that may have been emptied via reclamation haven't been
reused yet.  If they've been reused then you're in trouble.  I keep my
database backups for 3 days and have my reusedelay set to 3 also.

Tina

> -----Original Message-----
> From: Thomas A. La Porte [SMTP:tlaporte AT ANIM.DREAMWORKS DOT COM]
> Sent: Monday, August 31, 1998 11:28 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: adsm db backup
>
> I've read many of the responses to this message, and I believe
> that everyone has pointed out what is the correct answer to the
> specific question that Steven asked, i.e. "How do I specify that
> I only want 3 versions of the ADSM db?" I believe, however, that
> that question may have been asked based on incorrect assumptions
> about how ADSM works.
>
> I don't want to start the whole "ADSM is not your father's backup
> product" thread again, but notice the first assumption:
>
> On Mon, 31 Aug 1998, Steven McNicholas wrote:
>
> >The company where I presently work only keep 3 backup versions
> >of data on tape.
>
> This would be the result of defining VEREXISTS=3 for any and all
> backup copy groups.
>
> >Because of this they only want 3 adsm database backup versions on tape.
>
> Under ADSM this statement does not logically follow from the
> first statement--unless the MODE parameter has been set to
> "Absolute" for all backup copy groups, which would mean that a
> full backup is being run every night, which I presume is not the
> case.
>
> Making a backup of the ADSM database serves at least two
> purposes. The first is to be able to restore the database in the
> event of hardware failure (e.g., disk drive failure on the ADSM
> server) or complete loss due to disaster (e.g., flood, fire,
> earthquake, etc.). In this case, one wants to be able to restore
> the database to its most recent point in time. The second reason
> for making a database backup is to provide oneself with the
> ability to revert to an earlier point in time, for example in the
> case of database corruption that goes unnoticed for several days,
> or to rollback the database to a point prior to the introduction
> of a bug.
>
> In the first case, it would theoretically be sufficient to keep
> the one most recent backup of the database. Of course, we being
> the administrators of backup systems, we're far too paranoid to
> rely on a single backup copy, so we tend to keep several days
> worth of database backups--particularly those of us who have to
> do incrementals between fulls.
>
> In the second case, we have to strike a balance between our
> paranoia and our ability to absorb media costs. You could set up
> a system that never expired database backup tapes. A very old
> database backup would be relatively useless, though, because of
> the way ADSM attempts to minimize the overall media usage through
> the facilities of expiration, migration, and reclamation.
>
> I suppose that's a very long-winded way of saying that the
> VEREXISTS parameter for backup copy groups is not in any way
> related to the number of database backups one intends to keep.
> Assume, for example, that one were to set VEREXISTS=3 for all
> backup copy groups, and one were to run a daily administrative
> schedule that performs a full backup of the database. After the
> fourth database backup were performed, the first database backup
> would not be completely irrelevant or invalid. In most cases,
> after running incremental backups of your clients for four days,
> you will *not* have three versions of every file, because not all
> files will change every day. That is the benefit of using ADSM,
> if a file doesn't change, it doesn't get backed up again.
>
> >How do I specify that I only want 3 versions of the ADSM db?,
> >as otherwise it continually uses up valuable scratch tapes.
>
> Having said all of that, all of the solutions provided by others
> regarding the deletion of volhist records are correct. I would
> just caution you to determine the appropriate number of database
> backup versions to keep, and that you not base that number on the
> number of backup versions that you keep.
>
>  -- Tom
>
> Thomas A. La Porte
> DreamWorks Animation
> tlaporte AT anim.dreamworks DOT com