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_01C30387.F2026F60
Content-Type: text/plain
We have different pools for different types of backups so we can better tell
what systems or projects are consuming our DLT tapes. Once we visually see a
pool consuming tapes and color-coded labels at an alarming rate, thus
causing us supply problems, we then know that someone needs to do a better
job of policy scheduling and setting appropriate retention rates.
Here is an example of why I like different pools: There have been times when
we had run out of tapes, one of out Tape Library robots did not have enough
AVAILABLE tapes, and the next shipment hadn't arrived yet. In one case I
knew that a certain project was done and its tapes (located in a different
robot) had either expired or maybe had not even been used. Because it had
its own color-coded bar-code label, it was a simple matter to just open the
robot, start pulling them out, and then I could re-label them for another
pool and the other Tape Library that was in dire need. If that job policy
had shared a pool with other policies, all going to the same color-coded
labels, it would take more time (running commands and eject procedures) to
figure out what tapes could come out of the robot.
If that is not an issue, then having one or two pools will work fine, but we
are very budget oriented, project oriented, and tape allotment oriented, so
we need to be able to have better control on how to distribute our tape
usage as well as balance them between three Tape Library robots. We don't
want to go over our monthly P.O. tape budget limit!
Paul Griese
System Management
Telecheck Services
Houston, TX
-----Original Message-----
From: Kathryn Riddlemoser [mailto:kathy AT mitre DOT org]
Sent: Tuesday, April 15, 2003 1:14 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Volume Pools and Barcode Rules
I work with a bunch of people that are use to doing things one way and I
think
it's time to make a change. I'd like your opinion.
We currently have a few barcode rules associated with a bunch of different
volume pools. The idea is not to mix Windows data with Unix data on the
same
tape. Also, not to mix Unix with AFS on the same tape. Of course AFS runs
on the unix box. Then there are those special servers that can use the same
barcode rule but should not share tapes.
Here's a few examples:
Barcode Pool
UXA................Unix_Archive
UXI..................Unix_Incremental
UXA................AFS_Archive
UXI..................AFS_Incremental
WNA..............Windows_Archive
WNI................Windows_Incremental
WNA..............SpecialServer_Archive
WNI................SpecialServer_Incremental
Here's what I think we should do:
Barcode Pool
A0000# NetBackup
Let everything go to the same tape. Scheduled full backups with a retention
level of Infinity will not share the same tape as scheduled incremental
backups with a regular expiration. So there is no need to have an Archive
pool and an Incremtal pool. I see no reason not to backup Unix and AFS to
the
same tape, so there goes more pools.
My co-workers say, Unix and Windows should not backup to the same tapes
because their backup format differs (tar versus winzip). Bottom line...
NetBackup uses tar so I don't think it matters. Agree??
Appreciate any opinions on this matter.
Regards
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
(c) 2003 TeleCheck International, Inc. THIS DOCUMENT, AND ANY ATTACHED
INFORMATION: 1) IS PROPRIETARY, PRIVILEGED AND CONFIDENTIAL PROPERTY OF
TELECHECK UNDER APPLICABLE LAW, AND 2) IS INTENDED EXCLUSIVELY FOR INTERNAL
USE BY TELECHECK EMPLOYEES AND INTENDED RECIPIENTS WITH A LEGITIMATE
TELECHECK BUSINESS NEED THEREFORE. ITS REPRODUCTION, DISSEMINATION,
DISTRIBUTION AND/OR DISCLOSURE, EXCEPT TO SUCH TELECHECK EMPLOYEES AND
INTENDED RECIPIENTS, IS STRICTLY PROHIBITED . IF YOU ARE NOT SUCH A
TELECHECK EMPLOYEE OR INTENDED RECIPIENT, OR THE EMPLOYEE OR AGENT
RESPONSIBLE FOR DELIVERING THIS MESSAGE TO THE INTENDED RECIPIENT, YOU ARE
HEREBY NOTIFIED THAT ANY REPRODUCTION, DISSEMINATION, DISTRIBUTION AND/OR
DISCLOSURE OF THIS DOCUMENT, OR ANY ATTACHMENTS, IS STRICTLY PROHIBITED.
------_=_NextPart_001_01C30387.F2026F60
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Veritas-bu] Volume Pools and Barcode Rules</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>We have different pools for different types of =
backups so we can better tell what systems or projects are consuming =
our DLT tapes. Once we visually see a pool consuming tapes and =
color-coded labels at an alarming rate, thus causing us supply =
problems, we then know that someone needs to do a better job of policy =
scheduling and setting appropriate retention rates. </FONT></P>
<P><FONT SIZE=3D2>Here is an example of why I like different pools: =
There have been times when we had run out of tapes, one of out Tape =
Library robots did not have enough AVAILABLE tapes, and the next =
shipment hadn't arrived yet. In one case I knew that a certain project =
was done and its tapes (located in a different robot) had either =
expired or maybe had not even been used. Because it had its own =
color-coded bar-code label, it was a simple matter to just open the =
robot, start pulling them out, and then I could re-label them for =
another pool and the other Tape Library that was in dire need. If that =
job policy had shared a pool with other policies, all going to the same =
color-coded labels, it would take more time (running commands and eject =
procedures) to figure out what tapes could come out of the =
robot.</FONT></P>
<P><FONT SIZE=3D2>If that is not an issue, then having one or two pools =
will work fine, but we are very budget oriented, project oriented, and =
tape allotment oriented, so we need to be able to have better control =
on how to distribute our tape usage as well as balance them between =
three Tape Library robots. We don't want to go over our monthly P.O. =
tape budget limit!</FONT></P>
<P><FONT SIZE=3D2>Paul Griese</FONT>
<BR><FONT SIZE=3D2>System Management</FONT>
<BR><FONT SIZE=3D2>Telecheck Services</FONT>
<BR><FONT SIZE=3D2>Houston, TX</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kathryn Riddlemoser [<A =
HREF=3D"mailto:kathy AT mitre DOT org">mailto:kathy AT mitre DOT org</A>]
</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 15, 2003 1:14 PM</FONT>
<BR><FONT SIZE=3D2>To: veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Subject: [Veritas-bu] Volume Pools and Barcode =
Rules</FONT>
</P>
<P><FONT SIZE=3D2>I work with a bunch of people that are use to doing =
things one way and I think</FONT>
<BR><FONT SIZE=3D2>it's time to make a change. I'd like your =
opinion.</FONT>
</P>
<P><FONT SIZE=3D2>We currently have a few barcode rules associated with =
a bunch of different</FONT>
<BR><FONT SIZE=3D2>volume pools. The idea is not to mix Windows =
data with Unix data on the same</FONT>
<BR><FONT SIZE=3D2>tape. Also, not to mix Unix with AFS on =
the same tape. Of course AFS runs</FONT>
<BR><FONT SIZE=3D2>on the unix box. Then there are those special =
servers that can use the same</FONT>
<BR><FONT SIZE=3D2>barcode rule but should not share tapes.</FONT>
</P>
<P><FONT SIZE=3D2>Here's a few examples:</FONT>
</P>
<P><FONT =
SIZE=3D2>Barcode &n=
bsp; Pool</FONT>
<BR><FONT SIZE=3D2>UXA................Unix_Archive</FONT>
<BR><FONT SIZE=3D2>UXI..................Unix_Incremental</FONT>
<BR><FONT SIZE=3D2>UXA................AFS_Archive</FONT>
<BR><FONT SIZE=3D2>UXI..................AFS_Incremental</FONT>
<BR><FONT SIZE=3D2>WNA..............Windows_Archive</FONT>
<BR><FONT SIZE=3D2>WNI................Windows_Incremental</FONT>
<BR><FONT SIZE=3D2>WNA..............SpecialServer_Archive</FONT>
<BR><FONT SIZE=3D2>WNI................SpecialServer_Incremental</FONT>
</P>
<P><FONT SIZE=3D2>Here's what I think we should do:</FONT>
</P>
<P><FONT SIZE=3D2>Barcode =
Pool</FONT>
<BR><FONT SIZE=3D2>A0000# =
NetBackup</FONT>
</P>
<P><FONT SIZE=3D2>Let everything go to the same tape. Scheduled =
full backups with a retention</FONT>
<BR><FONT SIZE=3D2>level of Infinity will not share the same tape as =
scheduled incremental</FONT>
<BR><FONT SIZE=3D2>backups with a regular expiration. So there is =
no need to have an Archive</FONT>
<BR><FONT SIZE=3D2>pool and an Incremtal pool. I see no reason =
not to backup Unix and AFS to the</FONT>
<BR><FONT SIZE=3D2>same tape, so there goes more pools.</FONT>
</P>
<P><FONT SIZE=3D2>My co-workers say, Unix and Windows should not =
backup to the same tapes</FONT>
<BR><FONT SIZE=3D2>because their backup format differs (tar versus =
winzip). Bottom line...</FONT>
<BR><FONT SIZE=3D2>NetBackup uses tar so I don't think it =
matters. Agree??</FONT>
</P>
<P><FONT SIZE=3D2>Appreciate any opinions on this matter.</FONT>
</P>
<P><FONT SIZE=3D2>Regards</FONT>
</P>
<BR>
<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Veritas-bu maillist - =
Veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu"; =
TARGET=3D"_blank">http://mailman.eng.auburn.edu/mailman/listinfo/veritas=
-bu</A></FONT>
<BR><B><FONT SIZE=3D1>(c) 2003 TeleCheck International, Inc. THIS =
DOCUMENT, AND ANY ATTACHED INFORMATION: 1) IS PROPRIETARY, PRIVILEGED =
AND CONFIDENTIAL PROPERTY OF TELECHECK UNDER APPLICABLE LAW, AND =
2) IS INTENDED EXCLUSIVELY FOR INTERNAL USE BY TELECHECK =
EMPLOYEES AND INTENDED RECIPIENTS WITH A LEGITIMATE TELECHECK BUSINESS =
NEED THEREFORE. ITS REPRODUCTION, DISSEMINATION, DISTRIBUTION =
AND/OR DISCLOSURE, EXCEPT TO SUCH TELECHECK EMPLOYEES AND =
INTENDED RECIPIENTS, IS STRICTLY PROHIBITED . IF YOU ARE =
NOT SUCH A TELECHECK EMPLOYEE OR INTENDED RECIPIENT, OR THE EMPLOYEE OR =
AGENT RESPONSIBLE FOR DELIVERING THIS MESSAGE TO THE INTENDED =
RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY REPRODUCTION, =
DISSEMINATION, DISTRIBUTION AND/OR DISCLOSURE OF THIS DOCUMENT, OR ANY =
ATTACHMENTS, IS STRICTLY PROHIBITED.</FONT></B></P>
</BODY>
</HTML>
------_=_NextPart_001_01C30387.F2026F60--
|
