This is a multipart message in MIME format.
--=_alternative 005DF94B86256CD3_=
Content-Type: text/plain; charset="us-ascii"
You can get rid of the 11 errors without disabling OTM if you tune it
properly. Then you'll still be using OTM and hopefully have a better
chance of skipping less files. When the OTM cache fills, it will do one
of three things. One of them is error out, which causes the 11 errors.
Change the OTM Error Control to "Retry OTM" or "Disable OTM". Retry works
fine.
The cache temp files could cause system problems if they are filling the
entire partition that the system files are on. One thing to do is move
the cache file to another location, however, this would not be my
recommendation.
The cache temp files are often left uncleaned (it is supposed to clean
them up and this can be seen in bpbkar logs at the end of the job) if the
backup fails (system hangs, network issues, reboot while backup still
running, etc.). We have also seen problems leaving cache files if using
too large of a max cache size (or 0, which equals 10% of disk) space. OTM
uses memory space that has limits. If you exceed this, OTM will error out
behind the scenes and the files can be left uncleaned. See caveats
section of this for more info.
http://seer.support.veritas.com/docs/233254.htm
For those of you that don't like OTM, do the following and I think you'll
agree that, while not perfect, OTM can be removed from your
"thorn-in-my-side" list.
- change Error Control to something other than "abort on error"
- decrease your busy file wait a few seconds
- increase your busy file timeout to a few minutes
- change your initial cache size to something like 100 MB
- change your max cache size to something other than 0, higher than the
initial size, and lower than the allowed limit for your OS per technote
article above
- Scott
"Steven L. Sesar" <ssesar AT mitre DOT org>
Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
02/20/2003 10:17 AM
To: "Nash, Ebon" <Ebon_Nash AT compuware DOT com>
cc: "'Weber, Philip'" <Philip.Weber AT egg DOT com>,
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] NT OTM Questions
I don't recall seeing this option in 3.4, but on a 4.5 master, you can
disable OTM at the client level. It's just a checkbox, and it rid me of
those pesky 11 system call failure errors.
Here's couple of links to some good info on NBU and OTM:
http://www.backupcentral.com/foms/netbackup-serve/cache/151.html
--Steve
Nash, Ebon wrote:
> I would recommend either increasing the size of the system drive, which
is
> most likely your C: drive. If that is not possible, I believe there is
a
> way to tell NetBackup to write OTM files to a different location
(anything
> other than c:). I believe their web site has information on how to do
this.
> One other thing you can try is disabling OTM to see if that fixes the
> problem. That should be documented on Veritas' web site as well.
>
>
> Ebon Nash
> Compuware Corp.
>
> -----Original Message-----
> From: Weber, Philip [mailto:Philip.Weber AT egg DOT com]
> Sent: Thursday, February 20, 2003 6:17 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] NT OTM Questions
>
>
> Dear all,
>
> We are experiencing system problems with a large NT4 fileserver (500 Gb
> storage, 2 * P3 Xeon 550, 512 Gb RAM), the system has been found hanging
the
> last three mornings & had to be cold restarted. We are running
Netbackup
> 3.4 patch level 3 on the Solaris servers & patch level 1 on the NT
clients.
>
> Fingers are being pointed at OTM (because yesterday when the problem
> occurred the winnt system drive was found to have filled up, & an old
OTM
> cache file was found on it).
>
> I have seen on this list that other people have had issues with OTM. I
know
> it is a pain to configure and doesn't seem to work very well, can it
cause
> system problems?
>
> I have also seen that people have turned OTM off. What are the effects
of
> this - I would assume that all open files would therefore not be backed
up
> and we would get lots of 1 return codes.
>
> When OTM is working correctly I does it create cache files & delete
after
> use? Can it create multiple? Why would it leave them lying around?
>
> Any help appreciated ... thanks, Phil
>
> Phil Weber
> Egg Distributed Hosts - UNIX Systems Engineer
> Phone: 01384 26 4136
> Mobile:
>
>
> -----Original Message-----
> From: Liddle, Stuart [mailto:liddles AT amgen DOT com]
> Sent: 19 February 2003 22:48
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] Catalog backup question (NetBackup Datacenter 3.4
> UNIX)
>
>
> I need a way to find out how much data is actually being written to our
> catalog tape. I used the following:
>
> bpbackupdb -v
>
> and looked at the /usr/openv/netbackup/logs/admin/log.<date> file
>
> It did not have the total number of bytes written to the tape anywhere
in
> the output. I'd like to know how close I'm getting to filling my
catalog
> tape.
>
> Is there an easy way to determine this information, or do I have to just
> guess that since the data in the
>
> /usr/openv/netbackup/db
>
> directory is mostly text that it will get at least a 2:1 compression
> (probably closer to 4:1) and use that as a guide for how much will fit
on my
> DLT7000 tapes? Since the hardware compression will get about 70GB of
> compressed data on a tape, what's the realistic amount to expect that
will
> fit on the tape? Would I have to worry if my db directory is about
50GB?
> 100GB?
>
> thanks,
>
> --stuart
> _________________________
> Stuart W. Liddle
> Amgen Corp.
> liddles AT amgen DOT com
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
> This private and confidential e-mail has been sent to you by Egg.
> The Egg group of companies includes Egg Banking plc
> (registered no. 2999842), Egg Financial Products Ltd (registered
> no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
> carries out investment business on behalf of Egg and is regulated
> by the Financial Services Authority.
> Registered in England and Wales. Registered offices: 1 Waterhouse
Square,
> 138-142 Holborn, London EC1N 2NA.
> If you are not the intended recipient of this e-mail and have
> received it in error, please notify the sender by replying with
> 'received in error' as the subject and then delete it from your
> mailbox.
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
> The contents of this e-mail are intended for the named addressee only.
It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
--
===================================
Steven L. Sesar
Ops. Sys. Programmer/Analyst, Sr.
Application Operations R10A
The MITRE Corporation
202 Burlington Road - R101
Bedford, MA 01730
tel: (781) 271-7702
fax: (781) 271-2600
email: ssesar AT mitre DOT org
mobile: (617) 893-9635
===================================
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--=_alternative 005DF94B86256CD3_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Arial">You can get rid of the 11 errors without
disabling OTM if you tune it properly. Then you'll still be using OTM and
hopefully have a better chance of skipping less files. When the OTM cache
fills, it will do one of three things. One of them is error out, which
causes the 11 errors. Change the OTM Error Control to "Retry
OTM" or "Disable OTM". Retry works fine.</font>
<br>
<br><font size=2 face="Arial">The cache temp files could cause system problems
if they are filling the entire partition that the system files are on.
One thing to do is move the cache file to another location, however, this
would not be my recommendation.</font>
<br>
<br><font size=2 face="Arial">The cache temp files are often left uncleaned (it
is supposed to clean them up and this can be seen in bpbkar logs at the end of
the job) if the backup fails (system hangs, network issues, reboot while backup
still running, etc.). We have also seen problems leaving cache files if
using too large of a max cache size (or 0, which equals 10% of disk) space.
OTM uses memory space that has limits. If you exceed this, OTM will
error out behind the scenes and the files can be left uncleaned. See
caveats section of this for more info.</font>
<br>
<br><font size=2
face="Arial">http://seer.support.veritas.com/docs/233254.htm</font>
<br>
<br>
<br><font size=2 face="Arial">For those of you that don't like OTM, do the
following and I think you'll agree that, while not perfect, OTM can be removed
from your "thorn-in-my-side" list.</font>
<br><font size=2 face="Arial">- change Error Control to something other than
"abort on error"</font>
<br><font size=2 face="Arial">- decrease your busy file wait a few
seconds</font>
<br><font size=2 face="Arial">- increase your busy file timeout to a few
minutes</font>
<br><font size=2 face="Arial">- change your initial cache size to something
like 100 MB</font>
<br><font size=2 face="Arial">- change your max cache size to something other
than 0, higher than the initial size, and lower than the allowed limit for your
OS per technote article above</font>
<br>
<br>
<br><font size=2 face="Arial">- Scott</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Steven L. Sesar" <ssesar AT
mitre DOT org></b></font>
<br><font size=1 face="sans-serif">Sent by: veritas-bu-admin AT
mailman.eng.auburn DOT edu</font>
<p><font size=1 face="sans-serif">02/20/2003 10:17 AM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
"Nash, Ebon" <Ebon_Nash AT compuware DOT
com></font>
<br><font size=1 face="sans-serif"> cc:
"'Weber, Philip'" <Philip.Weber AT egg DOT
com>, veritas-bu AT mailman.eng.auburn DOT edu</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [Veritas-bu] NT OTM Questions</font></table>
<br>
<br>
<br><font size=2 face="Courier New">I don't recall seeing this option in 3.4,
but on a 4.5 master, you can <br>
disable OTM at the client level. It's just a checkbox, and it rid me of <br>
those pesky 11 system call failure errors.<br>
<br>
Here's couple of links to some good info on NBU and OTM:<br>
<br>
http://www.backupcentral.com/foms/netbackup-serve/cache/151.html<br>
<br>
--Steve<br>
<br>
<br>
Nash, Ebon wrote:<br>
> I would recommend either increasing the size of the system drive, which
is<br>
> most likely your C: drive. If that is not possible, I believe there
is a<br>
> way to tell NetBackup to write OTM files to a different location
(anything<br>
> other than c:). I believe their web site has information on how to
do this.<br>
> One other thing you can try is disabling OTM to see if that fixes the<br>
> problem. That should be documented on Veritas' web site as well.<br>
> <br>
> <br>
> Ebon Nash<br>
> Compuware Corp.<br>
> <br>
> -----Original Message-----<br>
> From: Weber, Philip [mailto:Philip.Weber AT egg DOT com]<br>
> Sent: Thursday, February 20, 2003 6:17 AM<br>
> To: veritas-bu AT mailman.eng.auburn DOT edu<br>
> Subject: [Veritas-bu] NT OTM Questions<br>
> <br>
> <br>
> Dear all,<br>
> <br>
> We are experiencing system problems with a large NT4 fileserver (500 Gb<br>
> storage, 2 * P3 Xeon 550, 512 Gb RAM), the system has been found hanging
the<br>
> last three mornings & had to be cold restarted. We are running
Netbackup<br>
> 3.4 patch level 3 on the Solaris servers & patch level 1 on the NT
clients.<br>
> <br>
> Fingers are being pointed at OTM (because yesterday when the problem<br>
> occurred the winnt system drive was found to have filled up, & an old
OTM<br>
> cache file was found on it).<br>
> <br>
> I have seen on this list that other people have had issues with OTM.
I know<br>
> it is a pain to configure and doesn't seem to work very well, can it
cause<br>
> system problems?<br>
> <br>
> I have also seen that people have turned OTM off. What are the
effects of<br>
> this - I would assume that all open files would therefore not be backed
up<br>
> and we would get lots of 1 return codes.<br>
> <br>
> When OTM is working correctly I does it create cache files & delete
after<br>
> use? Can it create multiple? Why would it leave them lying
around?<br>
> <br>
> Any help appreciated ... thanks, Phil<br>
> <br>
> Phil Weber<br>
> Egg Distributed Hosts - UNIX Systems Engineer<br>
> Phone: 01384 26 4136<br>
> Mobile: <br>
> <br>
> <br>
> -----Original Message-----<br>
> From: Liddle, Stuart [mailto:liddles AT amgen DOT com]<br>
> Sent: 19 February 2003 22:48<br>
> To: veritas-bu AT mailman.eng.auburn DOT edu<br>
> Subject: [Veritas-bu] Catalog backup question (NetBackup Datacenter 3.4<br>
> UNIX)<br>
> <br>
> <br>
> I need a way to find out how much data is actually being written to our<br>
> catalog tape. I used the following:<br>
> <br>
> bpbackupdb -v<br>
> <br>
> and looked at the /usr/openv/netbackup/logs/admin/log.<date> file<br>
> <br>
> It did not have the total number of bytes written to the tape anywhere
in<br>
> the output. I'd like to know how close I'm getting to filling my
catalog<br>
> tape.<br>
> <br>
> Is there an easy way to determine this information, or do I have to
just<br>
> guess that since the data in the <br>
> <br>
> /usr/openv/netbackup/db <br>
> <br>
> directory is mostly text that it will get at least a 2:1 compression<br>
> (probably closer to 4:1) and use that as a guide for how much will fit on
my<br>
> DLT7000 tapes? Since the hardware compression will get about 70GB
of</font>
<br><font size=2 face="Courier New">> compressed data on a tape, what's the
realistic amount to expect that will<br>
> fit on the tape? Would I have to worry if my db directory is about
50GB?<br>
> 100GB?<br>
> <br>
> thanks,<br>
> <br>
> --stuart<br>
> _________________________<br>
> Stuart W. Liddle<br>
> Amgen Corp.<br>
> liddles AT amgen DOT com<br>
> <br>
> <br>
> _______________________________________________<br>
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<br>
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
> <br>
> <br>
> This private and confidential e-mail has been sent to you by Egg.<br>
> The Egg group of companies includes Egg Banking plc<br>
> (registered no. 2999842), Egg Financial Products Ltd (registered<br>
> no. 3319027) and Egg Investments Ltd (registered no. 3403963) which<br>
> carries out investment business on behalf of Egg and is regulated<br>
> by the Financial Services Authority. <br>
> Registered in England and Wales. Registered offices: 1 Waterhouse
Square,<br>
> 138-142 Holborn, London EC1N 2NA.<br>
> If you are not the intended recipient of this e-mail and have<br>
> received it in error, please notify the sender by replying with<br>
> 'received in error' as the subject and then delete it from your<br>
> mailbox.<br>
> <br>
> _______________________________________________<br>
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<br>
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
> <br>
> <br>
> <br>
> The contents of this e-mail are intended for the named addressee only.
It<br>
> contains information that may be confidential. Unless you are the named<br>
> addressee or an authorized designee, you may not copy or use it, or
disclose<br>
> it to anyone else. If you received it in error please notify us
immediately<br>
> and then destroy it. <br>
> <br>
> _______________________________________________<br>
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<br>
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
> <br>
<br>
<br>
-- <br>
===================================<br>
<br>
Steven L. Sesar<br>
Ops. Sys. Programmer/Analyst, Sr.<br>
Application Operations R10A<br>
The MITRE Corporation<br>
202 Burlington Road - R101<br>
Bedford, MA 01730<br>
tel: (781) 271-7702<br>
fax: (781) 271-2600<br>
email: ssesar AT mitre DOT org<br>
mobile: (617) 893-9635<br>
<br>
===================================<br>
<br>
<br>
_______________________________________________<br>
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu<br>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu<br>
</font>
<br>
<br>
--=_alternative 005DF94B86256CD3_=--
|
