Well, this gets a little confusing, so maybe I will just bump my numbers
up and not try to figure it out. Right now I have my DRMDBExpire set to
7 days, the Delete DBVolhist runs weekly on Monday at 5 p.m. with today
-8. DB backups run daily at 1 p.m., offsite tapes are returned and sent
Monday around 11 a.m. These are the revised numbers after another kind
Monday around 11 a.m. These are the revised numbers after another kind
person on the list suggested this might be the problem. I think with
the current settings I might lose 1 tape a week (4/month), but I don't
think it will account for the 3-5 tapes per week that I am losing.
Before I call this in to IBM again, I will try adjusting these numbers
one more time. Perhaps I will up the delete dbvolhist to a large number
for now, like maybe -20, just to see if the problem clears up. This is
a good time to try it though, as we just inventoried the tapes this past
Monday. Thanks for the help!
> -----Original Message-----
> From: Prather, Wanda [SMTP:PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU]
> Sent: Friday, July 17, 1998 2:23 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Useful 'move data' options
>
> I used to "Lose" tapes in the vault, too.
>
> Discovered it was due to the DRMDBBACKUPEXPIREDAYS parm being set
> longer
> than my DELETE VOLHIST schedule.
>
> If you do a DELETE VOLHISTORY to expire your DBBACKUP tapes, so the DB
> backup volume entries are gone, then DRM won't know to bring them back
> on
> site. In other words, they get deleted before they have a chance to
> cycle
> through VAULTRETRIEVE and COURIERRETRIEVE status.
>
> If you think the "lost" tapes are your former DBBACKUPS, that's
> probably the
> problem.
>
> So if your DELETE VOLHIST schedule deletes tapes after 15 days, for
> example,
> do this:
>
> SET DRMDBBACKUPEXPIREDAYS 10
>
> That way DRM will put your DB backups into VAULTRETRIEVE status after
> 10
> days, and they will get cycled back onsite before your DELETE VOLHIST
> blows
> the entries away.
>
> Hope that helps..
>
> ===============================================================
> Wanda Prather
> Johns Hopkins Applied Physics Lab
> 443-778-8769
> wanda_prather AT jhuapl DOT edu
>
> "Intelligence has much less practical application than you'd think."
> - Scott Adams/Dilbert
> ===============================================================
>
>
>
> > ----------
> > From: Weeks, Debbie[SMTP:debbie AT admin.usf DOT edu]
> > Sent: Friday, July 17, 1998 1:56 PM
> > To: ADSM-L AT vm.marist DOT edu
> > Subject: Re: Useful 'move data' options
> >
> > We also have and like DRM, but as far as I know the entire copypool
> goes
> > to vault. You can't seperate out just active versions.
> >
> > On a similar issue, we still "lose" tapes at the vault. They
> apparently
> > go into VAULTR status during the week, but are deleted from the
> > inventory before we pull the tapes weekly on Monday. So we manually
> > check our vault inventory monthly now, and I always find at least 20
> > tapes that have disappeared from ADSM and can be checked back in as
> > scratch.
> >
> > > -----Original Message-----
> > > From: Jackie Balboni [SMTP:JBALBONI AT OCEANSPRAY DOT COM]
> > > Sent: Friday, July 17, 1998 12:11 PM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: Useful 'move data' options
> > >
> > > We use DRM for our copy storage pool. Reclamation can be done
> against
> > > these tapes and the will go in vault retrieve and can then go to
> > > scratch.
> > >
> > > >>> "Weeks, Debbie" <debbie AT ADMIN.USF DOT EDU> 07/17 11:21 AM >>>
> > > We only have backup activity at night at this time, all to
> diskpool,
> > > so
> > > I backup my diskpool to copypool every morning prior to migration
> for
> > > efficiency (like you say). So, can you take it a little further?
> > > How
> > > would I track just active versions beyond that? Eventually the
> > > offsite
> > > tapes would contain (as they do now) a mix of active and inactive
> > > versions, with no way of expiring inactive versions on copypool
> only.
> > >
> > > I realize that a lot of installations require a copy of the entire
> > > storage pool to ensure recovery from media failure, but not all
> sites
> > > find that insurance worth the price of the tapes. I think I have
> > > expressed this to this list before, so I won't bore you with my
> > > whining
> > > about this again. But if there is an easy, viable way to achieve
> this
> > > with ADSM, I would like to hear it.
> > >
> > > > -----Original Message-----
> > > > From: Bill Colwell [SMTP:bcolwell AT DRAPER DOT COM]
> > > > Sent: Friday, July 17, 1998 10:30 AM
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Subject: Re: Useful 'move data' options
> > > >
> > > > In <1A16375E84ABD111AF2200203568362F30AF AT calypso.cfr.usf DOT edu>,
> on
> > > > 07/17/98
> > > > at 09:15 AM, "Weeks, Debbie" <debbie AT ADMIN.USF DOT EDU> said:
> > > >
> > > > >I agree! This type of function might also enable me to only
> send
> > > the
> > > > >active versions offsite, something we are truly interested in.
> > > >
> > > > >> -----Original Message-----
> > > > >> From: Hilton Tina [SMTP:HiltonT AT TCE DOT COM]
> > > > >> Sent: Friday, July 17, 1998 8:16 AM
> > > > >> To: ADSM-L AT VM.MARIST DOT EDU
> > > > >> Subject: Re: Useful 'move data' options
> > > > >>
> > > > >> I think another handy addition to either mov data or
> reclamation
> > > > would
> > > > >> be to move all the active files to a set of tapes, separate
> from
> > > > the
> > > > >> inactive files. It that was done every so often it would
> reduce
> > > > the
> > > > >> number of tapes needed to restore a node. I've had some
> people
> > > try
> > > > to
> > > > >> get me to schedule full backups to accomplish this, but I've
> been
> > > > able
> > > > >> to refuse so far.
> > > > >>
> > > > >> Anyone else agree?
> > > > >>
> > > >
> > > > Slow down and and think this thru a little bit. To make
> copypool
> > > > tapes as
> > > > efficiently as possible you should be backing up the disk
> > > storagepool
> > > > frequently. I do it 4 times a day. Since backup storagepool is
> an
> > > > incremental process it only takes the new files which are all
> active
> > > > versions.
> > > >
> > > > Regarding enhancing move data, I know IBM already has a user
> > > > requirement for it because I submitted one at a GUIDE conference
> > > more
> > > > than 3
> > > > years ago. Unfortunately it was returned as a suggestion.
> Perhaps
> > > > someone
> > > > at IBM could look up the number so others
> > > > can concur on it. This is still the best procedure isn't it?
> > > >
> > > > --
> > > > -----------------------------------------------------------
> > > > Bill Colwell
> > > > C. S. Draper Lab
> > > > Cambridge, Ma.
> > > > bcolwell AT draper DOT com
> > > > -----------------------------------------------------------
> >
|
