ADSM-L

Re: Reclaming offsite tapes

2002-05-11 20:15:42
Subject: Re: Reclaming offsite tapes
From: Don France <DFrance-TSM AT ATT DOT NET>
Date: Sun, 12 May 2002 00:16:01 +0000
The "Pending" state simply means the reuse-delay is in
effect!  That is, after expiration occurs, *all* offsite
tapes go thru the period defined for "re-use delay"...
which is intended to protect from over-writing tapes
that might be needed during the period immediately
following expiration -- usually about 4 days.

You should read about it in the Admin. Guide, for a
thorough understanding (of how offsite tapes are expired
then actually made "scratch" again thru DRM).

The main thrust is to protect offsite tapes released
thru reclamation from being over-written while there are
still unexpired db backup tapes that might be needed
(using db restore) to recover data from such tapes.

Hope this helps.

-Don
> If it is "Pending", it means that, even though the tape has no valid
> If it is "Pending", it means that, even though the tape has no valid
> contents for
> your current production database could recover, you still have a valid
> database
> backup offsite that has not expired that does know what is on that tape, and
> if
> in a disaster situation you need to use that old database backup, it would
> need
> the tape that is currently "Pending".
>
> Once it is shown as Free or Empty rather than Pending, you can re-use that
> tape.
>
> > -----Original Message-----
> > From: Adamson, Matt [SMTP:matt.adamson AT ATTWS DOT COM]
> > Sent: Friday, May 10, 2002 4:50 PM
> > To:   ADSM-L AT VM.MARIST DOT EDU
> > Subject:      Re: Reclaming offsite tapes
> >
> > Sorry if I sound a little ignorant.  I took our backup environment over a
> > few months ago and have been trying to learn how it was set up.  It was
> > explained to me that I could not get tapes back from offsite, just in case
> > we need to do a Point in time restore with DRM. I have asked if we could
> > bring tapes back that are in a Pending state and was told NO.  Example: If
> > we pulled a DBSnap from lets say August 2001, it was explained to me that
> > some of these tapes that are marked Pending now, As of August 2001 they
> > could have data on them at that point in time.
> > Am I missing something or am I to assume that I can pull these(Pending)
> > tapes back.
> >
> > ={
> >
> > -----Original Message-----
> > From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
> > Sent: Friday, May 10, 2002 11:34 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Reclaming offsite tapes
> >
> >
> > When you start reclaims on a COPY pool where the tapes are OFFSITE, TSM
> > knows that the tapes aren't available (they are marked OFFSITE, yes?).  So
> > TSM does the reclaim using only the ONSITE tapes.
> >
> > If you have 3 tapes offsite that are only 10% good, TSM will mount a
> > scratch
> > tape, find the onsite copies of all those files, and create a new tape in
> > the OFFSITE tape pool that is 30% full.  Then it marks the OFFSITE tapes
> > as
> > EMPTY.  So you send the new tape offsite, and then you can bring the EMPTY
> > tapes back on site and reuse them.
> >
> > We do it constantly.
> >
> >
> > -----Original Message-----
> > From: Adamson, Matt [mailto:matt.adamson AT ATTWS DOT COM]
> > Sent: Friday, May 10, 2002 2:17 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Reclaming offsite tapes
> >
> >
> > Here is my scenario...
> >
> > We currently send all of our tapes offsite for 7 years.  In the library we
> > collocate by filespace.  But, when we send the tapes offsite they are
> > uncollocated.  We have retired a number of servers in the past couple
> > years,
> > meaning we no longer need that data.  Being that we send the tapes offsite
> > Uncollocated, data from a retired server could be on the same tape of a
> > server that we still have in production.  Is there a way for me find out
> > if
> > this is so?  Is there a way I can call the tapes back from offsite and
> > perform some sort of reclamation?
> >
> > Any ideas would be great, but if I'm stuck I can deal with it.  Tape costs
> > are making look into all different scenarios.
> >
> > Thanks,
> >
> > Matt
<Prev in Thread] Current Thread [Next in Thread>