|
[Veritas-bu] Questions on Staging to Disk and MS Exchange Age nt
2003-01-31 01:01:46
|
Subject: |
[Veritas-bu] Questions on Staging to Disk and MS Exchange Age nt |
|
From: |
res17ps5 AT gte DOT net (Thomas Jacob) |
|
Date: |
Thu, 30 Jan 2003 22:01:46 -0800 |
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C2C8AB.2EA0FB20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Are you vaulting disk to tape on NB 4.5 mp2 or is it vault 3.4 ? I have
had success with tape to tape dup, but the disk to tape dup take too
long.
I run SQL tr. logs to disk and am trying to vault these small images to
tape, once a day. I seem to have run into performance issues. I guess it
is the number of files. The total disk usage is just 4 GB in 24 hours
and it took 8 hours to dup. The backups to disk are fast, so the disk is
not the bottleneck. I am using IBM LTO drives (50GB/hr) and local disk
on the media server as the disk stu. I am using 4.5 mp2 and vault 4.5
mp2.
Any clues ?
Tom
-----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 Donaldson,
Mark
Sent: Tuesday, January 28, 2003 8:41 AM
To: 'William H Blandy'; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Questions on Staging to Disk and MS Exchange
Age nt
I've got a total of eight DLT7000 drives across two libraries (roughly
220 slots total). Deciding on which backups to go which storage units &
for how long is purely an operation decision with the limiting factor
being disk space. For that reason, I'd stick to a full/diff pattern and
forget the cummulative images. There's really only two reasons to do
cummulatives, IMO, and that's speed of restore (which'd be fast enough
from disk) and image protection from tape loss/damage (also negated by
disk).
The quick skeleton method below would work fine for what you're talking
about, rather than set an expiration date of "0" with bpexpdate, you
could set it at a week or something & NB will automatically reclaim your
disk space as the images expire. The on-tape image automatically
becomes your primary restore image following the expiration of the
on-disk image.
I immediately expire since my disk "buffer" region is a mere 200G and I
just don't have the space for any retained images once they're
successsfully on tape. The reason I do it in the first place is that I
have 7 production databases and I hourly do an incremental backup of the
archived redo logs to protect against data failure. This made the
library constantly thrash loading & unload tapes. Buffering to disk
lets me collect a set of these, then a cron-job starts every four hours
to dup them to tape. If the tape machine is busy or unavailable &
continue to buffer until it becomes available. 200M will hold about 2-3
days worth for me - less if it's been busy.
Let me know if you need help.
-M
------=_NextPart_000_0007_01C2C8AB.2EA0FB20
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Are=20
you vaulting disk to tape on NB 4.5 mp2 or is it vault 3.4 ? I have had =
success=20
with tape to tape dup, but the disk to tape dup take too long.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2>I run=20
SQL tr. logs to disk and am trying to vault these small images to tape, =
once a=20
day. I seem to have run into performance issues. I guess it is =
the=20
number of files. The total disk usage is just 4 GB in 24 hours and it =
took 8=20
hours to dup. The backups to disk are fast, so the disk is not the =
bottleneck. I=20
am using IBM LTO drives (50GB/hr) and local disk on the media =
server=20
as the disk stu. I am using 4.5 mp2 and vault 4.5 =
mp2.</FONT></SPAN></DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Any=20
clues ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D558273705-31012003><FONT face=3DArial color=3D#0000ff =
size=3D2>Tom</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
veritas-bu-admin AT mailman.eng.auburn DOT edu=20
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] <B>On Behalf Of=20
</B>Donaldson, Mark<BR><B>Sent:</B> Tuesday, January 28, 2003 8:41=20
AM<BR><B>To:</B> 'William H Blandy';=20
veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> RE:
[Veritas-bu]=20
Questions on Staging to Disk and MS Exchange Age =
nt<BR><BR></FONT></DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff size=3D2>I've=20
got a total of eight DLT7000 drives across two libraries (roughly 220 =
slots=20
total). Deciding on which backups to go which storage units =
& for=20
how long is purely an operation decision with the limiting factor =
being disk=20
space. For that reason, I'd stick to a full/diff pattern and =
forget the=20
cummulative images. There's really only two reasons to do =
cummulatives,=20
IMO, and that's speed of restore (which'd be fast enough from disk) =
and image=20
protection from tape loss/damage (also negated by =
disk).</FONT></SPAN></DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
quick skeleton method below would work fine for what you're talking =
about,=20
rather than set an expiration date of "0" with bpexpdate, you could =
set it at=20
a week or something & NB will automatically reclaim your disk =
space=20
as the images expire. The on-tape image automatically becomes =
your=20
primary restore image following the expiration of the on-disk =
image. =20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
immediately expire since my disk "buffer" region is a mere 200G and I =
just=20
don't have the space for any retained images once they're =
successsfully on=20
tape. The reason I do it in the first place is that I have 7 =
production=20
databases and I hourly do an incremental backup of the archived redo =
logs to=20
protect against data failure. This made the library constantly =
thrash=20
loading & unload tapes. Buffering to disk lets me collect a =
set of=20
these, then a cron-job starts every four hours to dup them to =
tape. If=20
the tape machine is busy or unavailable & continue to buffer =
until=20
it becomes available. 200M will hold about 2-3 days worth for me =
- less=20
if it's been busy.</FONT></SPAN></DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff size=3D2>Let=20
me know if you need help.</FONT></SPAN></DIV>
<DIV><SPAN class=3D583241716-28012003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>-M</FONT></SPAN></DIV>
<BLOCKQUOTE><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT> </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0007_01C2C8AB.2EA0FB20--
|
|
|
