Thanks for your suggestion but it wouldn't work unless I was able to script it 
to do the suspend at the moment the stream finished one tape rather than at the 
end of the stream.   Each stream can use 2-3 tapes (actually 4-6 since we're 
doing 2 copies at once) so that a retry on another stream could grab a tape 
from the first stream even though the first stream is currently writing to 
another tape.

However if anyone has a suggestion on how I could actually determine whether a 
running stream was done with a given tape from a command line I'd be interested 
to hear it.   If there's a command line I can script it myself.  This might be 
an acceptable work around since we kick the backup off via cron we could kick 
off the suspend script at the same time and just have it do a while loop for 
this.



-----Original Message-----
From: Tim Hoke [mailto:thoke AT northpeak DOT org] 
Sent: Tuesday, January 31, 2006 11:08 AM
To: Jeff Lightner
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Restricting tapes to a single stream

Well, there's no setting of this kind, so you'll need other 
workarounds...

As you mentioned, single stream backup.  Not very desirable, so that's 
out.

The only other item I can think of is to suspend the tapes which were 
used when each stream is done.  This will prevent any subsequent 
backups from selecting it again.  You'd have to script this and I'm 
sure someone has an example you could work from.  Essentially, this is 
a backup exit script which will determine the tape which was used, then 
issue a bpmedia -suspend command.Î

HTH.
-Tim

On Jan 31, 2006, at 9:53 AM, Jeff Lightner wrote:

>
> To forestall further answer of this kind:
>  
> I am NOT looking for assistance in resolving the 52 error on the 
> backup.  This problem would be caused if the issue had been any other 
> issue that caused a retry so wouldn't be restricted to a status 52 
> exit in any event.
>  
> I am NOT looking for "better" methods of doing a refresh.
>  
> What IS being asked is if there is a way to prevent a single backup 
> from using the same tape on two different streams given that the 
> backup in question has multiple streams (e.g. please do not respond 
> that I could prevent it by doing the backup as a single stream).
>  
>
> From: Greenberg, Katherine A [mailto:GreenbergKA AT aetna DOT com]
> Sent: Tuesday, January 31, 2006 10:22 AM
> To: Jeff Lightner; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Restricting tapes to a single stream
>  
> Why don't you try to identify and repair what is causing the 52 errors?
>  
> There are a few technotes and fixes for that specific error code, as 
> it is fairly common.
>  
> ~Kate
>  
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu 
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Jeff 
> Lightner
> Sent: Tuesday, January 31, 2006 9:20 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] Restricting tapes to a single stream
>
> Is it possible to setup a policy in such a way that any stream will 
> not use a tape previously used within another stream of the same 
> backup?
>
> Background:
>
> We run our Production DB backup using 3 streams.   This backup is used 
> for doing refreshes to test and training databases.   On occasion 
> during the original backup we'll see a status 52 forces one of the 
> streams to timeout and do a new try which is successful.  
> Unfortunately the new try on that stream may occur after one of the 
> other 2 streams has finished with a tape so it grabs that tape for 
> this stream.   This is OK but on restore it won't even schedule the 
> 3rd stream until after the stream that originally used the tape has 
> finished restoring so of course it causes a long delay in refresh.   I 
> didn't see a setting in the policy definition so I'm wondering if 
> there is a bp.conf or other setting that would prevent the use of the 
> same tape within two different streams of the same backup?
>
> Jeffrey C. Lightner
>
> Unix Systems Administrator
>
> DS Waters of North America
>
> 678-486-3516
>
>
> This e-mail may contain confidential or privileged information. If you
> think you have received this e-mail in error, please advise the sender
> by
> reply e-mail and then delete this e-mail immediately. Thank you.
> Aetna