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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 11:40 AM To: veritas-bu@mailman.eng.auburn.edu Subject: Veritas-bu Digest, Vol 1, Issue 5257 Send Veritas-bu mailing list submissions to veritas-bu@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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Subject: [Veritas-bu] Exclude lists To: <veritas-bu@mailman.eng.auburn.edu> Message-ID: <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> Subject: [Veritas-bu] count of scratch tapes To: "'veritas-bu@mailman.eng.auburn.edu'" <veritas-bu@mailman.eng.auburn.edu> Message-ID: <[EMAIL PROTECTED] 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. [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> p: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: Re: [Veritas-bu] compression to disk staging unit To: Veritas-bu@mailman.eng.auburn.edu Message-ID: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Subject: Re: [Veritas-bu] count of scratch tapes To: "'Covington, Garrett'" <[EMAIL PROTECTED]>, <veritas-bu@mailman.eng.auburn.edu> Message-ID: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] -----Ursprungligt meddelande----- Fr?n: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] F?r Covington, Garrett Skickat: den 23 maj 2006 17:27 Till: 'veritas-bu@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. [EMAIL PROTECTED] p: [EMAIL PROTECTED] 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@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu End of Veritas-bu Digest, Vol 1, Issue 5257 ******************************************* _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu