------=_Part_5957_33301039.1126766203205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
No, Mark is correct (as always!). Just to concur with his response :
If you want to set a physical expiration date on your 9940 media, you can.=
=20
But personally I have never bothered. With 9x40, I have only ever=20
expierienced "media errors" during write, so the backup just restarts on a=
=20
different tape, and life is good. The tape gets frozen, then I can do a few=
=20
test later to confirm that the "media error" was actually an O/S or=20
configuration problem.=20
I don't even use a physical expiration on LTO media. If I were still using=
=20
DLT, I probably *would* set physical expiration dates, but thankfully I'm=
=20
not.
I tend to assume that by the time a particular piece of media is physically=
=20
"too old", we will probably have moved on to some other technology (LTO-7?=
=20
9940-T? Holographic data cubes??)
The dates that all backups on a piece of media will expire and the tape wil=
l=20
go back to Scratch can be determined using bpmedialist.
Regards,
Dean
On 9/15/05, Jack L. Forester, Jr. <jack.l.forester AT lmco DOT com> wrote:
>=20
> I thought the expiration date in the vmquery was the date that all of
> the images on the tape would have been expired and the tape can be
> unassigned, ready to be used again. I have many tapes that have an
> expiration date of INFINITY that have images that never expire. Some
> have no expiration date at all. Or, are my 9940 tapes so good that they
> never wear out? :)
>=20
> Are you thinking of the maximum number of mounts allowed?
>=20
> Mark.Donaldson AT cexp DOT com wrote:
>=20
> >These are different dates that you think, I suspect.
> >
> >Vmquery's "expiration date" is the date that the tape media itself=20
> expires,
> >ie: the tape becomes too old to use further). Some companies make the
> >assumption that any tape more than 18 months old is suspect to failure s=
o
> >they refuse to use the tape past that time. This is media expiration=20
> time.
> >Netbackup will refuse to use a tape past it's media expiration date.
> >
> >bpmedialist draws its info from the Image DB and prints the date that th=
e
> >last image on that tape is due to expire. This is the date that the tape=
=20
> is
> >marked empty, is deassigned, and is reusable for new backups.
> >
> >Unfortunately, two different "expiration dates" that are not well
> >differentiated in the command set.
> >
> >-M
> >
> > -----Mensagem original-----
> >De: veritas-bu-admin AT mailman.eng.auburn DOT edu
> >[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]Em nome de Parnell,
> >Bill
> >Enviada em: quinta-feira, 31 de mar=E7o de 2005 05:52
> >Para: veritas-bu AT mailman.eng.auburn DOT edu
> >Assunto: [Veritas-bu] Query regarding the vmquery command
> >
> >
> >Hi all,
> >Can someone tell me why when I execute the following command I do not ge=
t
> >any information in the expiration datetime column?
> >
> >vmquery -a -w
> >
> >I can get expiration dates from the bpmedialist command and can parse th=
e
> >output to associate the exp dates to the media id's I would just like to
> >know why it is not listed in the vmquery command. All the entries are
> >coming back as 00/00/0000 00:00 the rest of the results are fine as far=
=20
> as
> >I can tell.
> >
> >Best Regards,
> >Bill.
> >
> >
>=20
>=20
> --
> Jack L. Forester, Jr.
> UNIX Systems Administrator, Stf
> Lockheed Martin Information Technology
> (304) 625-3946
>=20
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
------=_Part_5957_33301039.1126766203205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
No, Mark is correct (as always!). Just to concur with his response :<br>
<br>
If you want to set a physical expiration date on your 9940 media, you
can. But personally I have never bothered. With 9x40, I have only ever
expierienced "media errors" during write, so the backup just rest=
arts
on a different tape, and life is good. The tape gets frozen, then I can
do a few test later to confirm that the "media error" was actuall=
y an
O/S or configuration problem. <br>
<br>
I don't even use a physical expiration on LTO media. If I were still
using DLT, I probably *would* set physical expiration dates, but
thankfully I'm not.<br>
<br>
I tend to assume that by the time a particular piece of media is
physically "too old", we will probably have moved on to some othe=
r
technology (LTO-7? 9940-T? Holographic data cubes??)<br>
<br>
The dates that all backups on a piece of media will expire and the tape
will go back to Scratch can be determined using bpmedialist.<br><br>
Regards,<br>
Dean<br>
<br><div><span class=3D"gmail_quote">On 9/15/05, <b class=3D"gmail_senderna=
me">Jack L. Forester, Jr.</b> <<a href=3D"mailto:jack.l.forester AT lmco DOT
co=
m">jack.l.forester AT lmco DOT com</a>> wrote:</span><blockquote
class=3D"gmail=
_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt=
0pt 0.8ex; padding-left: 1ex;">
I thought the expiration date in the vmquery was the date that all of<br>th=
e images on the tape would have been expired and the tape can be<br>unassig=
ned, ready to be used again. I have many tapes that have an<br>e=
xpiration date of INFINITY that have images that never expire. S=
ome
<br>have no expiration date at all. Or, are my 9940 tapes so good that they=
<br>never wear out? :)<br><br>Are you thinking of the maximum number of mou=
nts allowed?<br><br><a href=3D"mailto:Mark.Donaldson AT cexp DOT
com">Mark.Donalds=
on AT cexp DOT com
</a> wrote:<br><br>>These are different dates that you think, I suspect.=
<br>><br>>Vmquery's "expiration date" is the date that the =
tape media itself expires,<br>>ie: the tape becomes too old to use furth=
er). Some companies make the
<br>>assumption that any tape more than 18 months old is suspect to fail=
ure so<br>>they refuse to use the tape past that time. This is media exp=
iration time.<br>>Netbackup will refuse to use a tape past it's media ex=
piration date.
<br>><br>>bpmedialist draws its info from the Image DB and prints the=
date that the<br>>last image on that tape is due to expire. =
This is the date that the tape is<br>>marked empty, is deassigned, and i=
s reusable for new backups.
<br>><br>>Unfortunately, two different "expiration dates" t=
hat are not well<br>>differentiated in the command set.<br>><br>>-=
M<br>><br>> -----Mensagem original-----<br>>De: <a href=3D"mailto:=
veritas-bu-admin AT mailman.eng.auburn DOT edu">
veritas-bu-admin AT mailman.eng.auburn DOT edu</a><br>>[mailto:<a
href=3D"mailt=
o:veritas-bu-admin AT mailman.eng.auburn DOT edu">veritas-bu-admin AT
mailman.eng DOT aub=
urn.edu</a>]Em nome de Parnell, Bill<br>>Enviada em: quinta-feira, 31 de=
mar=E7o de 2005 05:52
<br>>Para: <a href=3D"mailto:veritas-bu AT mailman.eng.auburn DOT
edu">veritas-=
bu AT mailman.eng.auburn DOT edu</a><br>>Assunto: [Veritas-bu] Query
regarding =
the vmquery command<br>><br>><br>>Hi all,<br>>Can someone tell =
me why when I execute the following command I do not get
<br>>any information in the expiration datetime column?<br>><br>>v=
mquery -a -w<br>><br>>I can get expiration dates from the bpmedialist=
command and can parse the<br>>output to associate the exp dates to the =
media id's I would just like to
<br>>know why it is not listed in the vmquery command. All th=
e entries are<br>>coming back as 00/00/0000 00:00 the rest of=
the results are fine as far as<br>>I can tell.<br>><br>>Best Rega=
rds,<br>>Bill.
<br>><br>><br><br><br>--<br>Jack L. Forester, Jr.<br>UNIX Systems Adm=
inistrator, Stf<br>Lockheed Martin Information Technology<br>(304) 625-3946=
<br><br>_______________________________________________<br>Veritas-bu maill=
ist -
<a href=3D"mailto:Veritas-bu AT mailman.eng.auburn DOT edu">Veritas-bu AT
mailman DOT eng=
.auburn.edu</a><br><a href=3D"http://mailman.eng.auburn.edu/mailman/listinf=
o/veritas-bu">http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu</a>
<br></blockquote></div><br>
------=_Part_5957_33301039.1126766203205--
|
