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_01C2C943.182D9EF0
Content-Type: text/plain
I've got NB v3.4 but not the Vault product. I'm just using plain scripts &
the bpduplicate command. Lots & lots of small files is a problem for NB, it
has to organize & inventory & track them all.
To make it clear, I do hourly differential incremental backups from my
Oracle archived-redo filesystems to a disk STU. I then have an
every-four-hour cron job that wakes & makes a duplicate of the images on the
disk STU to tape, then expires the disk images.
For performance issues, the first think I check is the buffer settings.
Here's a technote on it that's very good. Increasing buffers made a big
difference to my backups. Don't forget the clients.
<http://seer.support.veritas.com/docs/183702.htm>
http://seer.support.veritas.com/docs/183702.htm
-M
-----Original Message-----
From: Thomas Jacob [mailto:res17ps5 AT gte DOT net]
Sent: Thursday, January 30, 2003 11:02 PM
To: 'Donaldson, Mark'; '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
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_001_01C2C943.182D9EF0
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>
<META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff size=2>I've
got NB v3.4 but not the Vault product. I'm just using plain scripts &
the bpduplicate command. Lots & lots of small files is a problem for
NB, it has to organize & inventory & track them all.</FONT></SPAN></DIV>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff size=2>To
make it clear, I do hourly differential incremental backups from my Oracle
archived-redo filesystems to a disk STU. I then have an every-four-hour
cron job that wakes & makes a duplicate of the images on the disk STU
to tape, then expires the disk images.</FONT></SPAN></DIV>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff size=2>For
performance issues, the first think I check is the buffer settings.
Here's
a technote on it that's very good. Increasing buffers made a big
difference to my backups. Don't forget the clients.</FONT></SPAN></DIV>
<DIV><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=483455515-31012003>
<P><A href="http://seer.support.veritas.com/docs/183702.htm";><FONT
size=2>http://seer.support.veritas.com/docs/183702.htm</FONT></A></P>
<P><SPAN class=483455515-31012003><FONT face=Arial color=#0000ff
size=2>-M</FONT></SPAN></P></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Thomas Jacob
[mailto:res17ps5 AT gte DOT net]<BR><B>Sent:</B> Thursday, January 30, 2003
11:02
PM<BR><B>To:</B> 'Donaldson, Mark'; 'William H Blandy';
veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> RE: [Veritas-bu]
Questions on Staging to Disk and MS Exchange Age nt<BR><BR></FONT></DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff size=2>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.
</FONT></SPAN></DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff size=2>Any
clues ?</FONT></SPAN></DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=558273705-31012003><FONT face=Arial color=#0000ff
size=2>Tom</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] <B>On Behalf Of
</B>Donaldson, Mark<BR><B>Sent:</B> Tuesday, January 28, 2003 8:41
AM<BR><B>To:</B> 'William H Blandy';
veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> RE:
[Veritas-bu]
Questions on Staging to Disk and MS Exchange Age nt<BR><BR></FONT></DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2>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).</FONT></SPAN></DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2>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. </FONT></SPAN></DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2>Let me know if you need help.</FONT></SPAN></DIV>
<DIV><SPAN class=583241716-28012003><FONT face=Arial color=#0000ff
size=2>-M</FONT></SPAN></DIV>
<BLOCKQUOTE><FONT face=Arial color=#0000ff
size=2></FONT> </BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2C943.182D9EF0--
|
