This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C4AACB.8C4BD700
Content-Type: text/plain;
charset="iso-8859-1"
All,
We have what appear to be continual successfull RMAN backups everynight.
However, every now and then, when we do a RMAN directed alternate client hot
restore, we get the "backup id XXX is not a tar formatted image" error and
the restore fails, this can sometimes be after restoring for a couple of
hours.
Can anyone throw any light on this? - What is most concerning is that the
restore can be tried again and may/may not work.......
Thanks
Kev Smith
-----Original Message-----
From: Michael.F.Lavelle AT abbott DOT com [mailto:Michael.F.Lavelle AT abbott
DOT com]
Sent: Friday, October 01, 2004 9:29 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Volume Expiration and ScratchPool
----- Forwarded by Michael F Lavelle/LAKE/CHMS/ABBOTT on 10/01/2004 03:30 PM
-----
Michael F Lavelle
10/01/2004 11:47 AM
To: veritas-bu-admin AT mailman.eng.auburn DOT edu
cc: Michael F Lavelle/LAKE/CHMS/ABBOTT@ABBOTT
Subject: Volume Expiration and ScratchPool
Hi,
I don't want to start a shoot-from-the-hip philosophical discussion,
but my topic is Volume Expiration.
I understand the treatment of tape expiration varies widely.
Q: In practice, in large environments with multiple PetaBytes on
record in a single domain's catalog, using a mix of DLT 7000 and SDLT 220
tape drives and their media (two different animals - I know), to what extent
should a hard expiry date be de-emphasized?
Q: Is the default of 200 mounts a useful real-world end-of-life
measure for DLT or SDLT-I media?
Q: How many shops actually wait until individual tapes fail with
frequency and are FROZEN to retire tapes?
Here's why I ask. NetBackup v4.5 allows a tape to silently expire
within a library and become a ZOMBIE.
While informed administrative practice would defend against this
problem, (fill in my excuse...).
I recently had to address a problem in a large (500 tapes, 10 DLT
7000 drives) tape library with 48 ScratchPool tapes in it, yet none were
migrating into the other production Volume Pools when they ran low. Lots of
96 errors.
After digging into the legacy scripts the Operations staff use daily
to identify how many ScratchPool tapes they need to inject into the various
libraries, vmquery was correctly reporting that this library did have 48
ScratchPool taped loaded. One of these has the lowest value Media ID in the
entire Domain, so it was not much of a leap to the correct conclusion. All
were ejected, placed in a new EXPIRED Volume Pool, and ScratchPool was
properly loaded into the library.
Now I want to determine what to do with the expired volumes.
Q: Extended their use by tacking another 2 years on to their lives?
Q: If so, do I down-select their allowed mount counts?
Q: Or do I just wait until they fail?
I know I have suffered declining expectations with NetBackup
Enterprise v4.5 (scheduled to go v5.1 FP1 in November), especially in
recovery behaviour after FC-SCSI router "glitches" (Chicken Little would use
more enthusiastic word choice :-). While I'm reducing my ignorance on the
operational side of an NBU environment, I did not expect Volume Expiry to be
an unremarked event.
Q: On a day-to-day basis, how do large environments protect against
ZOMBIE behaviour of expired Volumes, especially when the clock strikes
midnight while the Volume is in a library?
------_=_NextPart_001_01C4AACB.8C4BD700
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2>All,</FONT></SPAN></DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff size=2>We
have what appear to be continual successfull RMAN backups everynight. However,
every now and then, when we do a RMAN directed alternate client hot restore, we
get the "backup id XXX is not a tar formatted image" error and the restore
fails, this can sometimes be after restoring for a couple of
hours.</FONT></SPAN></DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff size=2>Can
anyone throw any light on this? - What is most concerning is that the restore
can be tried again and may/may not work.......</FONT></SPAN></DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=252220411-05102004><FONT face=Verdana color=#0000ff size=2>Kev
Smith</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Michael.F.Lavelle AT abbott
DOT com
[mailto:Michael.F.Lavelle AT abbott DOT com]<BR><B>Sent:</B> Friday, October
01, 2004
9:29 PM<BR><B>To:</B> veritas-bu AT mailman.eng.auburn DOT
edu<BR><B>Subject:</B>
[Veritas-bu] Volume Expiration and ScratchPool<BR><BR></FONT></DIV><BR><FONT
face=sans-serif color=#800080 size=1>----- Forwarded by Michael F
Lavelle/LAKE/CHMS/ABBOTT on 10/01/2004 03:30 PM -----</FONT> <BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<TD><FONT face=sans-serif size=1><B>Michael F Lavelle</B></FONT>
<P><FONT face=sans-serif size=1>10/01/2004 11:47 AM</FONT> <BR></P>
<TD><FONT face=Arial size=1> </FONT><BR><FONT
face=sans-serif size=1> To:
veritas-bu-admin AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT
face=sans-serif size=1> cc:
Michael F Lavelle/LAKE/CHMS/ABBOTT@ABBOTT</FONT> <BR><FONT
face=sans-serif size=1> Subject:
Volume Expiration and
ScratchPool</FONT></TR></TBODY></TABLE><BR><BR><FONT face=Arial
size=2>Hi,</FONT> <BR><FONT face=Arial size=2> I
don't want to start a shoot-from-the-hip philosophical discussion, but my
topic is Volume Expiration.</FONT> <BR><BR><FONT face=Arial size=2>
I understand the treatment of tape expiration varies
widely.</FONT> <BR><BR><FONT face=Arial size=2>Q:
In practice, in large environments with multiple PetaBytes on record in
a single domain's catalog, using a mix of DLT 7000 and SDLT 220 tape drives
and their media (two different animals - I know), to what extent should a
hard
expiry date be de-emphasized?</FONT> <BR><FONT face=Arial size=2>Q:
Is the default of 200 mounts a useful real-world
end-of-life measure for DLT or SDLT-I media?</FONT> <BR><FONT face=Arial
size=2>Q: How many shops actually wait until
individual tapes fail with frequency and are FROZEN to retire tapes?</FONT>
<BR><BR><BR><FONT face=Arial size=2> Here's why I
ask. NetBackup v4.5 allows a tape to silently expire within a library
and become a ZOMBIE.</FONT> <BR><FONT face=Arial size=2>
While informed administrative practice would defend against this
problem, (fill in my excuse...).</FONT> <BR><BR><FONT face=Arial
size=2>
I recently had to address a problem in a large (500
tapes, 10 DLT 7000 drives) tape library with 48 ScratchPool tapes in it, yet
none were migrating into the other production Volume Pools when they ran low.
Lots of 96 errors.</FONT> <BR><FONT face=Arial size=2>
After digging into the legacy scripts the Operations staff use
daily to identify how many ScratchPool tapes they need to inject into the
various libraries, vmquery was correctly reporting that this library did have
48 ScratchPool taped loaded. One of these has the lowest value Media ID
in the entire Domain, so it was not much of a leap to the correct conclusion.
All were ejected, placed in a new EXPIRED Volume Pool, and ScratchPool
was properly loaded into the library.</FONT> <BR><BR><FONT face=Arial
size=2> Now I want to determine what to do with
the
expired volumes.</FONT> <BR><BR><FONT face=Arial size=2>Q:
Extended their use by tacking another 2 years on to their
lives?</FONT> <BR><FONT face=Arial size=2>Q: If
so,
do I down-select their allowed mount counts?</FONT> <BR><FONT face=Arial
size=2>Q: Or do I just wait until they
fail?</FONT>
<BR><BR><BR><FONT face=Arial size=2> I know I have
suffered declining expectations with NetBackup Enterprise v4.5 (scheduled to
go v5.1 FP1 in November), especially in recovery behaviour after FC-SCSI
router "glitches" (Chicken Little would use more enthusiastic word choice
:-).
While I'm reducing my ignorance on the operational side of an NBU
environment, I did not expect Volume Expiry to be an unremarked event.</FONT>
<BR><BR><BR><FONT face=Arial size=2>Q: On a
day-to-day basis, how do large environments protect against ZOMBIE behaviour
of expired Volumes, especially when the clock strikes midnight while the
Volume is in a library?</FONT> <BR></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C4AACB.8C4BD700--
|
