Mohamed,
First ping the client if the ping is OK, check the throughput of the
client and that is where usually you get the error code 41 because that
is an indication of the throughput is less than 1MB/s for the backup
interface of the client.
-Karim
-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of
veritas-bu-request at mailman.eng.auburn.edu
Sent: Tuesday, May 23, 2006 11:40 AM
To: veritas-bu at mailman.eng.auburn.edu
Subject: Veritas-bu Digest, Vol 1, Issue 5257
Send Veritas-bu mailing list submissions to
veritas-bu at mailman.eng.auburn.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
or, via email, send a message with subject or body 'help' to
veritas-bu-request at mailman.eng.auburn.edu
You can reach the person managing the list at
veritas-bu-owner at mailman.eng.auburn.edu
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Veritas-bu digest..."
Today's Topics:
1. Exclude lists (Mohamed Wahdan)
2. count of scratch tapes (Covington, Garrett)
3. Re: compression to disk staging unit (Darren Dunham)
4. Re: count of scratch tapes (Hampus Lind)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 May 2006 18:13:21 +0300
From: "Mohamed Wahdan" <mwahdan at Mobinil.com>
Subject: [Veritas-bu] Exclude lists
To: <veritas-bu at mailman.eng.auburn.edu>
Message-ID:
<FCD9B20EBC734B4AA3B9C8E25FC4DA292DA107 at HQ-MAIL-NC.mobinil.corp>
Content-Type: text/plain; charset="us-ascii"
Hello,
I have a problem that we have a policy for a filesystem which contains a
large number of files with a differential backup and it fails with
status
41 (network connection timed out) I tried first to increase the
CLIENT_READ_TIMEOUT to 1800 and it worked for some time then failed
again with the same error.
I got a list of directories (which contain the largest number of files)
to exclude from the backup with exclude lists. I created the file
exclude_list.POLICY-NAME in the path /usr/openv/netbackup including
these directories like:
/dir1/*
/dir2/*
and I got the same error again. I think the exclude list didn't work and
I am asking for any way to trace or monitor its work or any other
suggested solution for my problem.
our netbackup version is netbackup enterprise server 5.1 and our master
& client is HP-UX 11.11.
Thanks,
Mohamed Wahdan
*******
IMPORTANT
Confidentiality: This e-mail communication and any attachments thereto
contain information which is confidential and are intended only for the
use of the individuals or entities named above. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution or the taking any action in reliance on the
contents of these documents is strictly prohibited and may be illegal.
Please notify us of your receipt of this e-mail in error and delete the
e-mail and any copies of it.
Monitoring/Viruses: Mobinil may monitor all incoming & outgoing e-mails
in line with current legislation. Although we have taken steps to ensure
that this e-mail and attachments are free from any Virus, we advise that
in keeping with good computing practice the recipient should ensure they
are actually virus free.
The Egyptian Company for Mobile Services (Mobinil) www.mobinil.com
*******
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060523/
38d83be9/attachment-0001.html
------------------------------
Message: 2
Date: Tue, 23 May 2006 09:26:33 -0600
From: "Covington, Garrett" <Garrett.Covington at trizetto.com>
Subject: [Veritas-bu] count of scratch tapes
To: "'veritas-bu at mailman.eng.auburn.edu'"
<veritas-bu at mailman.eng.auburn.edu>
Message-ID:
<A32D73B2BBA55B4F8491C41A8B98F6DC0B5AD17A at den-tzg-exmb-02.corp.trizetto.
com>
Content-Type: text/plain; charset="us-ascii"
I run Solaris9 - NBU 5.1mp4
Is there a good way to output the number or tapes within a pool or
robot,
ie: to count the number of SCRATCH tapes within a robot?
Thanks,
Garrett Covington
The TriZetto Group, Inc.
Garrett.Covington at TriZetto.com <mailto:Garrett.Covington at TriZetto.com>
p: 3032046695 at vtext.com <mailto:3032046695 at vtext.com>
w: 303-323-6886
c: 303-204-6695
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060523/
bbeb4a13/attachment-0001.html
------------------------------
Message: 3
Date: Tue, 23 May 2006 08:39:20 -0700 (PDT)
From: Darren Dunham <ddunham at taos.com>
Subject: Re: [Veritas-bu] compression to disk staging unit
To: Veritas-bu at mailman.eng.auburn.edu
Message-ID: <200605231539.IAA04619 at redwood.taos.com>
Content-Type: text/plain; charset=us-ascii
> > The idea is if you are using your VTL to produce not just random
> > storage, but map directly onto physical tape. If your local
> > compression is greater than the drive's, then when you go to realize
> > the virtual tape onto physical storage, Nebackup may be tracking a
> > single tape (TAP001), but that data will not fit onto a physical
> > device. Very annoying. You now have to either get the application
> > involved and duplicate the data, or you have to track two pieces of
> > physical media as a single unit and try to keep the application from
> > knowing that....
> > Good luck with restores that don't involve the VTL.
>
> "[M]ap directly onto physical tape?" With my usual subtlety and
> understatement, let me say that this is absolutely insane. <insert
> smiley> A TAPE IS NOT A FIXED NUMBER OF BYTES/BLOCKS/SECTORS LONG.
Of course not. But I can assume with reasonable certainty that if 99%
of the advertised uncompressed capacity of a tape doesn't fit, it's a
problem with the tape that can be handled by swapping it out. And in
practice, I've never run into capacity issues with an uncompressed
volume like this.
If I attempt to use a greater amount though, I may run into an issue
that has nothing to do with a failing of a particular tape and cannot be
solved that way.
> This has nothing to do with compression; it has everything to do with
> the nature of the medium. Gaps vary, speed can vary, BOT/EOT
> (archaic) positions vary, tape backs up and erases a couple of inches
> of tape after r-a-w errors, ... Not only do different tapes hold
> different amounts of identical data, but the same tape will likely
> hold a different amount of data if you write the same data to it
twice.
As an absolute, I agree with you. In practice, I've never found it to
be a significant issue.
> There is no way to guarantee that the contents of tape A fit onto tape
> B. Because of that, as I said earlier, no tape software ever made,
> AFAIK, makes such an assumption. If your method of using a VTL does
> make that assumption, that's between you and the VTL vendor--but I
> doubt you'll find support in NetBackup for that.
You got it. Nonetheless, it was very handy. The VTL can go in without
changing how the system works (it just assumes it's writing to tape),
and the tape can be realized after the fact and used without a VTL in
the future or at another location (something we did a lot). The
drawback was that we couldn't use drive compression. Instead we used
client-side compression. I was actually very skeptical that we could
use client-side compression effectively, but it worked pretty well for
the most part. We had a lot of beefy clients, so CPU didn't tend to be
an issue.
> > is greater than the drive's, then when you go to realize the virtual
> > tape onto physical storage,
>
> The way to realize virtual tape onto real (or virtual) tape is to do
> it the way all tape-to-tape is done: by software that understands
tape.
> bpduplicate, for instance. It's trivial to dup a 1TB SDLT600 tape
> onto [a ton of] DAT4 cartridges.
If I were setting up the system today, I'd have no reservations about
using NBU for it all the way. When the VTL was put in, we had a lot of
concerns about how the management of the disk units would be done. The
hardware could be plopped in and not significantly change the existing
operation of the system. All told, it worked pretty well. Our problems
with it had nothing to do with the inability to realize uncompressed
tapes due to data not fitting.
> Perhaps I misunderstand what you're doing, but if you're using some
> VTL utility to do duplication, I don't believe you'll be happy.
> NetBackup won't know a darned thing about it, giving you a management
> problem for tracking, re-creating and restoring and raising TCO.
The VTL sees physical tapes in the physical library and creates virtual
tapes with the same "barcode". NBU writes to the virtual tapes. Later
they can be written to the physical tape. For a restore, there's no
confusion or change in how the volumes are tracked. NBU never needs to
understand that the duplication has occured because both volumes have
the same data and the same "barcode". I don't have to worry about
duplicate barcodes because only one of them is physically extant.
> If you use a VTL the way all I've seen are promoted--and the way it is
> tested before being supported by NetBackup, it is indistinguishable
> from a real library and drives and tapes; you should not have to
> change your operation at all.
For the setup I was using, it is indistinguishable (on the host side)
from a real library and drives and tapes. The difference is that on the
back end, it turns virtual tapes into physical tape from time to time.
For that purpose, it is useful to have all the data on a virtual volume
fit on a physical cartridge. As you mention, it may be impossible to
guarantee that as an absolute, but I don't remember a failure of that
type in practice.
> > (TAP001), but that data will not fit onto a physical device. Very
> > annoying. You now have to either get the application involved and
> > duplicate the data, or you have to track two pieces of physical
> > media as a single unit and try to keep the application from knowing
> > that....
> > Good luck with restores that don't involve the VTL.
>
> But it doesn't sound like it [using the VTL exactly as a tape
library].
> Sounds like you're running a complex operation out of sight of
> NetBackup, which puts the burden on you to put things back together.
> Nothing wrong with that if you're up to it. Good luck.
>
> > would fit otherwise. I think now they do a better job of emulating
> > the compression used by the drive and lopping off a bit so that
> > you're reasonably certain of the data fitting onto good media even
> > with local compression.
>
> >From your writing, you seem to be a person with experience. Isn't
> "kinda-sorta emulating some drive firmware, then fudging a bit, and
> hoping to be reasonably certain" an alternative spelling of "kludge?"
That's all I've ever expected a drive-side VTL (as opposed to app-side
disk managment like a DSU) to be. I'm assuming that tape and library
vendors aren't bending over backward helping someone else try to emulate
their product exactly.
I've certainly had problems with them, but they really have nothing to
do with the emulation stuff like that. It's the back end VTL database
and general hardware problems like other libraries.
--
Darren Dunham ddunham at taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Message: 4
Date: Tue, 23 May 2006 17:39:29 +0200
From: "Hampus Lind" <hampus.lind at rps.police.se>
Subject: Re: [Veritas-bu] count of scratch tapes
To: "'Covington, Garrett'" <Garrett.Covington at trizetto.com>,
<veritas-bu at mailman.eng.auburn.edu>
Message-ID: <003101c67e7f$14b35040$6400a8c0 at rps183476>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
?vmquery ?pn scratch ?b | grep ?i hcart | wc ?l? will give you the nr
hcart tapes in scratch pool.
Cheers,
Hampus Lind
Rikspolisstyrelsen
National Police Board
Tel dir: +46 (0)8 - 401 99 43
Tel mob: +46 (0)70 - 217 92 66
E-mail: hampus.lind at rps.police.se
-----Ursprungligt meddelande-----
Fr?n: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] F?r Covington,
Garrett
Skickat: den 23 maj 2006 17:27
Till: 'veritas-bu at mailman.eng.auburn.edu'
?mne: [Veritas-bu] count of scratch tapes
I run Solaris9 - NBU 5.1mp4
Is there a good way to output the number or tapes within a pool or
robot,
ie: to count the number of SCRATCH tapes within a robot?
Thanks,
Garrett Covington
The TriZetto Group, Inc.
Garrett.Covington at TriZetto.com
p: 3032046695 at vtext.com
w: 303-323-6886
c: 303-204-6695
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060523/
141be82d/attachment.html
------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
End of Veritas-bu Digest, Vol 1, Issue 5257
*******************************************
|
