[Veritas-bu] Restricting tapes to a single stream

This is a multi-part message in MIME format.


------_=_NextPart_001_01C6267A.165D0BBC
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Why don't you try to identify and repair what is causing the 52 errors?=0D=
=0A =0D=0AThere are a few technotes and fixes for that specific error code,=
 as it=0D=0Ais fairly common=2E=0D=0A =0D=0A~Kate=0D=0A =0D=0A-----Original=
 Message-----=0D=0AFrom: veritas-bu-admin@mailman=2Eeng=2Eauburn=2Eedu=0D=
=0A[mailto:veritas-bu-admin@mailman=2Eeng=2Eauburn=2Eedu] On Behalf Of Jeff=
=0D=0ALightner=0D=0ASent: Tuesday, January 31, 2006 9:20 AM=0D=0ATo: verita=
s-bu@mailman=2Eeng=2Eauburn=2Eedu=0D=0ASubject: [Veritas-bu] Restricting ta=
pes to a single stream=0D=0A=0D=0A=0D=0A=0D=0AIs it possible to setup a pol=
icy in such a way that any stream will not=0D=0Ause a tape previously used =
within another stream of the same backup?=0D=0A=0D=0ABackground:=0D=0A=0D=
=0AWe run our Production DB backup using 3 streams=2E   This backup is used=
=0D=0Afor doing refreshes to test and training databases=2E   On occasion d=
uring=0D=0Athe original backup we'll see a status 52 forces one of the stre=
ams to=0D=0Atimeout and do a new try which is successful=2E  Unfortunately =
the new try=0D=0Aon that stream may occur after one of the other 2 streams =
has finished=0D=0Awith a tape so it grabs that tape for this stream=2E   Th=
is is OK but on=0D=0Arestore it won't even schedule the 3rd stream until af=
ter the stream=0D=0Athat originally used the tape has finished restoring so=
 of course it=0D=0Acauses a long delay in refresh=2E   I didn't see a setti=
ng in the policy=0D=0Adefinition so I'm wondering if there is a bp=2Econf o=
r other setting that=0D=0Awould prevent the use of the same tape within two=
 different streams of=0D=0Athe same backup?=0D=0A=0D=0AJeffrey C=2E Lightne=
r=0D=0A=0D=0AUnix Systems Administrator=0D=0A=0D=0ADS Waters of North Ameri=
ca=0D=0A=0D=0A678-486-3516=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-------------------=
----------------------=0D=0AThis e-mail may contain confidential or privile=
ged information=2E  If you=0D=0Athink you have received this e-mail in erro=
r, please advise the sender=0D=0Aby=0D=0Areply e-mail and then delete this =
e-mail immediately=2E  Thank you=2E=0D=0AAetna=0D=0A
------_=_NextPart_001_01C6267A.165D0BBC
Content-Type: text/html;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<HTML>=0D=0A<BODY>=0D=0A<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Trans=
itional//EN">=0D=0A<HTML><HEAD><TITLE>Message</TITLE>=0D=0A<META http-equiv=
=3DContent-Type content=3D"text/html; charset=3Dus-ascii">=0D=0A<META conte=
nt=3D"MSHTML 6=2E00=2E2800=2E1523" name=3DGENERATOR></HEAD>=0D=0A<BODY>=0D=
=0A<DIV><SPAN class=3D593482015-31012006><FONT face=3DVerdana size=3D2>Why =
don't you try =0D=0Ato identify and repair what is causing the 52 errors?</=
FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D593482015-31012006><FONT face=3D=
Verdana =0D=0Asize=3D2></FONT></SPAN>&nbsp;</DIV>=0D=0A<DIV><SPAN class=3D5=
93482015-31012006><FONT face=3DVerdana size=3D2>There are a few =0D=0Atechn=
otes and fixes for that specific error code, as it is fairly =0D=0Acommon=
=2E</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D593482015-31012006><FONT fa=
ce=3DVerdana =0D=0Asize=3D2></FONT></SPAN>&nbsp;</DIV>=0D=0A<DIV><SPAN clas=
s=3D593482015-31012006><FONT face=3DVerdana =0D=0Asize=3D2>~Kate</FONT></SP=
AN></DIV>=0D=0A<DIV><SPAN class=3D593482015-31012006><FONT face=3DVerdana =
=0D=0Asize=3D2></FONT></SPAN>&nbsp;</DIV>=0D=0A<DIV></DIV>=0D=0A<DIV><FONT =
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =0D=0Aver=
itas-bu-admin@mailman=2Eeng=2Eauburn=2Eedu =0D=0A[mailto:veritas-bu-admin@m=
ailman=2Eeng=2Eauburn=2Eedu] <B>On Behalf Of </B>Jeff =0D=0ALightner<BR><B>=
Sent:</B> Tuesday, January 31, 2006 9:20 AM<BR><B>To:</B> =0D=0Averitas-bu@=
mailman=2Eeng=2Eauburn=2Eedu<BR><B>Subject:</B> [Veritas-bu] Restricting =
=0D=0Atapes to a single stream<BR><BR></DIV></FONT><!-- Converted from text=
/rtf format -->=0D=0A<P align=3Dleft><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>Is it possible to setup a =0D=0Apolicy in such a way that any stre=
am will not use a tape previously used within =0D=0Aanother stream of the s=
ame backup?</FONT></SPAN></P>=0D=0A<P align=3Dleft><SPAN lang=3Den-us><FONT=
 face=3DArial =0D=0Asize=3D2>Background:</FONT></SPAN></P>=0D=0A<P align=3D=
left><SPAN lang=3Den-us><FONT face=3DArial size=3D2>We run our Production D=
B =0D=0Abackup using 3 streams=2E&nbsp;&nbsp; This backup is used for doing=
 refreshes to =0D=0Atest and training databases=2E&nbsp;&nbsp; On occasion =
during the original backup =0D=0Awe&#8217;ll see a status 52 forces one of =
the streams to timeout and do a new try =0D=0Awhich is successful=2E&nbsp; =
Unfortunately the new try on that stream may occur =0D=0Aafter one of the o=
ther 2 streams has finished with a tape so it grabs that tape =0D=0Afor thi=
s stream=2E&nbsp;&nbsp; This is OK but on restore it won&#8217;t even sched=
ule =0D=0Athe 3</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><=
SUP><FONT =0D=0Aface=3DArial size=3D2>rd</FONT></SUP></SPAN><SPAN lang=3Den=
-us></SPAN><SPAN =0D=0Alang=3Den-us><FONT face=3DArial size=3D2> stream unt=
il after the stream that =0D=0Aoriginally used the tape has finished restor=
ing so of course it causes a long =0D=0Adelay in refresh=2E&nbsp;&nbsp; I d=
idn&#8217;t see a setting in the policy definition so =0D=0AI&#8217;m wonde=
ring if there is a bp=2Econf or other setting that would prevent the use =
=0D=0Aof the same tape within two different streams of the same =0D=0Abacku=
p?</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN></P>=0D=
=0A<P align=3Dleft><SPAN lang=3Den-us></SPAN><A name=3D""><SPAN lang=3Den-u=
s>Jeffrey C=2E =0D=0ALightner</SPAN></A></P>=0D=0A<P align=3Dleft><SPAN lan=
g=3Den-us>Unix Systems Administrator</SPAN></P>=0D=0A<P align=3Dleft><SPAN =
lang=3Den-us>DS Waters of North America</SPAN></P>=0D=0A<P align=3Dleft><SP=
AN lang=3Den-us>678-486-3516</SPAN></P>=0D=0A<P align=3Dleft><SPAN lang=3De=
n-us></SPAN></P></BODY></HTML>=0D=0A=0D=0A=0D=0A<P><hr size=3D1></P>=0D=0A<=
P><STRONG>=0D=0AThis e-mail may contain confidential or privileged informat=
ion=2E  If you<br>think you have received this e-mail in error, please advi=
se the sender<br>by<br>reply e-mail and then delete this e-mail immediately=
=2E  Thank you=2E<br>Aetna=0D=0A</STRONG></P>=0D=0A</BODY>=0D=0A</HTML>=0D=
=0A
------_=_NextPart_001_01C6267A.165D0BBC--