Re: [Veritas-bu] Snapshot Client problem on NBU 6.5.1
Hello Marianne Would like to how it goes, we're looking at buying the enterprise client for some of our oracle servers Regards Michael 2008/1/16, Marianne Van Den Berg <[EMAIL PROTECTED]>: > > > > > > A colleague pointed me in the right direction - it helps if one reads ALL > the relevant manuals! (I was only reading Snapshot Client manual) > > > > The answer was in the NBU for Oracle manual: > > > > Traditional 'backup' statement in script gets replaced with 'backup proxy'. > > > > Will test 1st thing tomorrow morning… > > > > > > Marianne > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Marianne Van Den Berg > Sent: 16 January 2008 16:38 > To: VERITAS-BU@mailman.eng.auburn.edu > Subject: [Veritas-bu] Snapshot Client problem on NBU 6.5.1 > > > > > Hi > > Anybody out there using new disk array snapshot method in 6.5? > > We're using HP EVA snapshots with offhost backup (media server is Alt > client). > > Normal file system backups work fine - snapshot takes place, data is > offloaded to media server. > > Oracle rman policy runs successful, BUT the snapshot DOESN'T take place - > data is backed up from the client across the network to the media server - > NO ERRORS! > > > Any idea why snapshot doesn't take place and backup is done over the > network? > > Attributes of Oracle policy (file system policy is the same, only difference > is Policy Type and Backup Selection): > > Policy Name: ora-snap > Options: 0x0 > template: FALSE > c_unused1: ? > Names: (none) > Policy Type: Oracle (4) > Active:yes > Effective date:01/14/2008 19:30:00 > Block Incremental: no > Mult. Data Stream: no > Perform Snapshot Backup: yes > Snapshot Method: HP_EVA_Snapshot > Snapshot Method Arguments: max_snapshots=1 > Perform Offhost Backup:yes > Backup Copy: 0 > Use Data Mover:no > Data Mover Type: 2 > Use Alternate Client: yes > Alternate Client Name: dbs3 > Use Virtual Machine: no > Enable Instant Recovery: no > Policy Priority: 1 > Max Jobs/Policy: 4 > Disaster Recovery: 0 > Collect BMR Info: no > Keyword: (none specified) > Data Classification: - > Residence is Storage Lifecycle Policy:no > Client Encrypt:no > Checkpoint:no > Residence: dbs3-hcart-robot-tld-0 > > > > Regards > > Marianne > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] 3rd party scheduling
I'm afraid I'll have to disagree with my esteemed colleague from water.com. ;) I believe the question is whether you are prioritizing ease of control or full utilization of resources. 3rd party schedulers (TPS) give the former and completely dismiss the latter. I have seen several large shops use TPS, and they generally have great reporting and control over how and when their backups run -- and they have CRAP for throughput. One very large client, for example, averages 1.5 MB/s on their LTO-2 tape drives. Another averages about 5 MB/s. (And in case you DON'T know, the farther your throughput is from the advertised rate of the drive in question, the more that drive will fail.) If you want to fully leverage your hardware, there is no way you can get anywhere near as close as NBU can with it's auto-start of the next job as soon as the last job is completed when there's a tape drive that's supposed to have 5 jobs running on it and it now only has 4. As to CPU utilization, the only way you can get CLOSE is to have backups kicked off in advance (queued) so that NBU does its job and assigns it to the next available drive. --- BUT --- When you run bpbackup -i on the command line, a queued job takes up CPU resources. With the NBU scheduler, you can have THOUSANDS of jobs in the queue waiting for the right time and not a single one takes up any resources. So back to my point. IF leveraging resources is the priority, then you deal with the weird hoops that NBU makes you jump through in order to handle pre-post processing. (I've even done multi-host-dependent scripting in NBU. It's certainly harder, but totally possible.) But in the end, your backups run MUCH faster and your tape drives and disk systems are much more leveraged. --- W. Curtis Preston Backup Blog @ www.backupcentral.com VP Data Protection, GlassHouse Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Lightner Sent: Wednesday, January 16, 2008 10:18 AM To: A Darren Dunham; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] 3rd party scheduling I agree it takes a fair amount of work and planning. However, I disagree that it wasn't worth the effort. In the places where we did it I much preferred the TWS setup to using NBU scheduling and/or cron for those jobs that had to be client initiated. The logging it did was a very good tool for determining where in the process things broke down and kept me from troubleshooting things that weren't the underlying issue. Also it saved CPU/memory because if the first job didn't work it didn't try to kick off the other jobs at all (they would fail because of the first job's failure if they had kicked off). Finally, since it was an overall schedule once we'd resolved the issue with the job that failed we could resume the schedule at the point of failure instead of having to manually deal with different steps. (I have to do this manual stuff at my present job because we rely on cron jobs instead.) As to signaling it is very easy within scripts to set exit status/return value (at least in UNIX/Linux) and use non-zero status as a "failure" of the job to prevent the schedule from proceeding to the next job. One thing to be sure you do within such scripts used for jobs is to be sure you set an overall exit status rather than take the one for the last command executed within the script. e.g. If you had a script that did something like initiate a BCV establish, monitor until done then split then at the end you did something like "echo Job Completed" the final exit status for the job would be 0 so long as the echo worked even if the BCV establish or split had failed. You have to get the status for each of these and add it to a return value variable (say $RETVAL) then at the end of the script put in a statement like "exit $RETVAL) so it would no the overall job had failed rather than rely on the exit status of that last command. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A Darren Dunham Sent: Wednesday, January 16, 2008 12:53 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] 3rd party scheduling On Wed, Jan 16, 2008 at 10:35:46AM -0600, Stump, Bob A wrote: > I have seen a trend to stop using NetBackup for starting and monitoring > backups. The move has been to doing all command line backups from a 3rd > party scheduler as part of a true enterprise scheduling, monitoring and > management implementation. NetBackup is simply one of many products that > are controlled by the enterprise 3rd party sheduler/monitor. What are > the drawbacks to moving in this direction? You still require a significant configuration setup in Netbackup (pools, policies, etc.), so you will end up with configuration information in two places. That can complicate maintenance. Most sites don't use them, so you may find it harder to find someone with experience doing this, or have increased training
Re: [Veritas-bu] Snapshot Client problem on NBU 6.5.1
A colleague pointed me in the right direction - it helps if one reads ALL the relevant manuals! (I was only reading Snapshot Client manual) The answer was in the NBU for Oracle manual: Traditional 'backup' statement in script gets replaced with 'backup proxy'. Will test 1st thing tomorrow morning... Marianne From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marianne Van Den Berg Sent: 16 January 2008 16:38 To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] Snapshot Client problem on NBU 6.5.1 Hi Anybody out there using new disk array snapshot method in 6.5? We're using HP EVA snapshots with offhost backup (media server is Alt client). Normal file system backups work fine - snapshot takes place, data is offloaded to media server. Oracle rman policy runs successful, BUT the snapshot DOESN'T take place - data is backed up from the client across the network to the media server - NO ERRORS! Any idea why snapshot doesn't take place and backup is done over the network? Attributes of Oracle policy (file system policy is the same, only difference is Policy Type and Backup Selection): Policy Name: ora-snap Options: 0x0 template: FALSE c_unused1: ? Names: (none) Policy Type: Oracle (4) Active:yes Effective date:01/14/2008 19:30:00 Block Incremental: no Mult. Data Stream: no Perform Snapshot Backup: yes Snapshot Method: HP_EVA_Snapshot Snapshot Method Arguments: max_snapshots=1 Perform Offhost Backup:yes Backup Copy: 0 Use Data Mover:no Data Mover Type: 2 Use Alternate Client: yes Alternate Client Name: dbs3 Use Virtual Machine: no Enable Instant Recovery: no Policy Priority: 1 Max Jobs/Policy: 4 Disaster Recovery: 0 Collect BMR Info: no Keyword: (none specified) Data Classification: - Residence is Storage Lifecycle Policy:no Client Encrypt:no Checkpoint:no Residence: dbs3-hcart-robot-tld-0 Regards Marianne ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] LTO3 tape drive Performance testing tools
try using windows "NT Backup" program or use Linux or cygwin for tar or dd. Good luck though, I have tried various things from drivers to buffer settings on Windows and can't get higher than ~25MB/sec, even when doing a BCV backup up to CDL. I think it maybe its the x86 hardware (no such problems on Solaris and AIX)? I did a dual boot with Windows and Linux and a standalone LTO3 drive and I got the same (~20MB/sec) performance on both. Jared M. Seaton Recovery Administrator Mylan Inc. 304-554-5926 304-685-1389 (Cell) "Ed Scheef" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/16/2008 02:37 PM To veritas-bu@mailman.eng.auburn.edu cc Subject [Veritas-bu] LTO3 tape drive Performance testing tools Folks, We have recently installed LTO3 tape drives in an L1400 tape library (for netbackup use). Tape drives are driven by Windows 2003 servers. Using Netbackup, we are not getting the throughput expected. We're getting 8-25mb/sec where we should be seeing 60-80mb/sec. Is there a utility or a method available which we could use to test direct write performance from Windows 2003 OS level directly to the LTO3 tapes drives, keeping Netbackup out of the picture ?? This would help tell the tale if Netbackup is the bottleneck or whether it is something else. Responses are appreciated. Thanks Much, Ed Scheef TECO Energy, Inc. - Tampa___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu == CONFIDENTIALITY NOTICE: This e-mail message and all attachments transmitted with it may contain legally privileged, proprietary and/or confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution, duplication or other use of this message and/or its attachments is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and its attachments. Thank you. == ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] LTO3 tape drive Performance testing tools
Download cygwin and use tar or dd. :-) Steve On Jan 16, 2008 3:31 PM, Ed Scheef <[EMAIL PROTECTED]> wrote: > Folks, > > We have recently installed LTO3 tape drives in an L1400 tape > library (for netbackup use). Tape drives are driven by > Windows 2003 servers. > > Using Netbackup, we are not getting the throughput expected. > We're getting 8-25mb/sec where we should be seeing 60-80mb/sec. > > *Is there a utility or a method available which we could use to * > * test direct write** performance** from Windows 2003 OS level * > * directly to the LTO3 tapes drives,** keeping **Netbackup out of* > * the** picture ??* This would help tell the tale if Netbackup is > the bottleneck or whether it is something else. > > > Responses are appreciated. > > > Thanks Much, > Ed Scheef > TECO Energy, Inc. - Tampa > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Veritas-bu Digest, Vol 21, Issue 22-Autonegotiate
intended solely for the use of the person(s) to which it is addressed. If > you are not an intended recipient, or the employee or agent responsible > for delivery of this Email to the intended recipient(s), you are hereby > notified that any dissemination, distribution or copying of this Email is > strictly prohibited. If you have received this message in error, please > immediately notify the sender and permanently delete this Email and any > copies. PHI policies expressly prohibit employees from making defamatory > or offensive statements and infringing any copyright or any other legal > right by Email communication. PHI will not accept any liability in respect > of such communications. ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > -- next part -- > An HTML attachment was scrubbed... > URL: > http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20080116/79dcdea6/attachment.htm > > -- > > Message: 2 > Date: Wed, 16 Jan 2008 09:08:33 -0500 > From: "Paul Keating" <[EMAIL PROTECTED]> > Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status =40: > network connect > To: > Message-ID: > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="utf-8" > > If you're using GigE, you want auto/auto. > > There are apparantly some card/drivers that still work better with > 100Mb/s links fixed speed/duplex. > > In any case both sides (switch/host) must be set the sameeither both > auto, or both fixed. > if you have one side fixed and one side auto, you will end up with the > auto side going to half duplex, which obviously doesn't not communicate > well with the other side being fixed at full duplex. > > Paul > > > Fellows, Auto negotiate works by sending a very fast signal to the connecting switch. If the switch does not respond to the signal (when not set to Auto)(which can not usually be seen in packet analyzers like wireshark, only very high end analyzers) then the sending switch drops down to 10 half. If the connecting switch is set to 100 full there will be no talking between the switches. The easy rule of thumb is either set both switches to auto, or set both connecting ports to be the same speed and duplex. Auto negotiate usually works best to obtain the fastest communication. Yours, Rob ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] LTO3 tape drive Performance testing tools
Folks, We have recently installed LTO3 tape drives in an L1400 tape library (for netbackup use). Tape drives are driven by Windows 2003 servers. Using Netbackup, we are not getting the throughput expected. We're getting 8-25mb/sec where we should be seeing 60-80mb/sec. Is there a utility or a method available which we could use to test direct write performance from Windows 2003 OS level directly to the LTO3 tapes drives, keeping Netbackup out of the picture ?? This would help tell the tale if Netbackup is the bottleneck or whether it is something else. Responses are appreciated. Thanks Much, Ed Scheef TECO Energy, Inc. - Tampa ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] 3rd party scheduling
I would see potential issues occuring if the group that controls the scheduling is separate from the group that maintains the backups in that you may eventually not receive good monitoring or feedback of when backups start, end, or fail. For large enterprises, it may make sense to have a centralized scheduling, but in the past I have experienced situations where it was troublesome to manage between different groups. If the environment is more of a operations center and the different groups are closely bound and communicate well with each other, then a centralized scheduling system may be the way to go. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stump, Bob A Sent: Wednesday, January 16, 2008 10:36 AM To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] 3rd party scheduling I have seen a trend to stop using NetBackup for starting and monitoring backups. The move has been to doing all command line backups from a 3rd party scheduler as part of a true enterprise scheduling, monitoring and management implementation. NetBackup is simply one of many products that are controlled by the enterprise 3rd party sheduler/monitor. What are the drawbacks to moving in this direction? What are some of the enterprise scheduling and monitoring/management 3rd party solutions have you recently seen? Autosys? Stonebranch? __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Veritas-bu Digest, Vol 21, Issue 19 Mac issue with 10.5
[EMAIL PROTECTED] wrote: > 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. Re: NBU overwriting data on Tape (Randy Samora) >2. Re: NBU overwriting data on Tape (Paul Keating) > > > -- > > Message: 1 > Date: Tue, 15 Jan 2008 10:02:13 -0600 > From: "Randy Samora" <[EMAIL PROTECTED]> > Subject: Re: [Veritas-bu] NBU overwriting data on Tape > To: <[EMAIL PROTECTED]>, > Message-ID: > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="us-ascii" > > Without an inventory being run, NetBackup wouldn't know the tape was > there so it shouldn't overwrite it. If you are putting a "full tape" in > the library, I'm assuming the tape is being used for a restore? If so, > write protecting the tape seems to be the easiest solution. The only > other reason I can think of to put a full tape back into the library is > so that you can reuse it in which case you want NBU to overwrite it. Or > maybe I'm missing something. > > Thanks, > Randy > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, January 15, 2008 9:33 AM > To: veritas-bu@mailman.eng.auburn.edu > Subject: [Veritas-bu] NBU overwriting data on Tape > > Hi > We are planning to move from TSM to NBU. We heard draw back that NBU can > accidently overwrite data on tape if tape library inventory is not run > after putting full tape in library. > If that is true, how can we avoide ? > Your help is very much appreciated. > > THX > > > > > On Mon, 14 Jan 2008 12:00:08 -0600, > [EMAIL PROTECTED] said: > >> 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. which clients datas on which tape (POUSSARD, Gilles (APX >> > SYNSTAR)) > >>2. Re: Oracle RMAN backup using Netbackup (Murtuja Khokhar) >>3. Re: which clients datas on which tape (Michael Graff Andersen) >>4. Backing up Leopard clients (Don Klebba) >>5. Re: Backing up Leopard clients >> > ([EMAIL PROTECTED]) > >> -- >> >> Message: 1 >> Date: Mon, 14 Jan 2008 10:33:33 +0100 >> From: "POUSSARD, Gilles \(APX SYNSTAR\)" <[EMAIL PROTECTED]> >> Subject: [Veritas-bu] which clients datas on which tape >> To: >> Message-ID: >> >> > <[EMAIL PROTECTED]> > >> >> Content-Type: text/plain;charset="iso-8859-1" >> >> Hello, >> >> Did someone wrote a script to check which clients are on which >> > tape. > >> For example, I would know for client A, where his datas are >> > located with which retentions > >> Thanks for your help. >> >> Gilles. >> >> >> >> >> This e-mail is intended only for the above addressee. It may contain >> privileged information. >> If you are not the addressee you must not copy, distribute, disclose >> > or > >> use any of the information in it. >> If you have received it in error please delete it and immediately >> > notify > >> the sender. >> Security Notice: all e-mail, sent to or from this address, may be >> accessed by someone other than the recipient, for system management >> > and > >> security reasons. This access is controlled under Regulation of >> > security > >> reasons. >> This access is controlled under Regulation of Investigatory Powers Act >> 2000, Lawful Business Practises. >> >> >> >> >> >> -- >> >> Message: 2 >> Date: Mon, 14 Jan 2008 01:42:14 -0800 (PST) >> From: Murtuja Khokhar <[EMAIL PROTECTED]> >> Subject: Re: [Veritas-bu] Oracle RMAN backup using Netbackup >> To: [EMAIL PROTECTED], Veritas-bu@mailman.eng.auburn.edu >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> All, >> >> Thank you very much.My problem is got resolved by to actions >> >> >> link Oracle with NetBackup for Oracle >> I have specified SBT_TAPE >> >> [EMAIL PROTECTED] wrote: >> >> Eve
Re: [Veritas-bu] 3rd party scheduling
I agree it takes a fair amount of work and planning. However, I disagree that it wasn't worth the effort. In the places where we did it I much preferred the TWS setup to using NBU scheduling and/or cron for those jobs that had to be client initiated. The logging it did was a very good tool for determining where in the process things broke down and kept me from troubleshooting things that weren't the underlying issue. Also it saved CPU/memory because if the first job didn't work it didn't try to kick off the other jobs at all (they would fail because of the first job's failure if they had kicked off). Finally, since it was an overall schedule once we'd resolved the issue with the job that failed we could resume the schedule at the point of failure instead of having to manually deal with different steps. (I have to do this manual stuff at my present job because we rely on cron jobs instead.) As to signaling it is very easy within scripts to set exit status/return value (at least in UNIX/Linux) and use non-zero status as a "failure" of the job to prevent the schedule from proceeding to the next job. One thing to be sure you do within such scripts used for jobs is to be sure you set an overall exit status rather than take the one for the last command executed within the script. e.g. If you had a script that did something like initiate a BCV establish, monitor until done then split then at the end you did something like "echo Job Completed" the final exit status for the job would be 0 so long as the echo worked even if the BCV establish or split had failed. You have to get the status for each of these and add it to a return value variable (say $RETVAL) then at the end of the script put in a statement like "exit $RETVAL) so it would no the overall job had failed rather than rely on the exit status of that last command. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A Darren Dunham Sent: Wednesday, January 16, 2008 12:53 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] 3rd party scheduling On Wed, Jan 16, 2008 at 10:35:46AM -0600, Stump, Bob A wrote: > I have seen a trend to stop using NetBackup for starting and monitoring > backups. The move has been to doing all command line backups from a 3rd > party scheduler as part of a true enterprise scheduling, monitoring and > management implementation. NetBackup is simply one of many products that > are controlled by the enterprise 3rd party sheduler/monitor. What are > the drawbacks to moving in this direction? You still require a significant configuration setup in Netbackup (pools, policies, etc.), so you will end up with configuration information in two places. That can complicate maintenance. Most sites don't use them, so you may find it harder to find someone with experience doing this, or have increased training costs when you hire someone. I'm not sure that the ways that the scheduler can launch jobs is completely available to other tools (although maybe it is, since I haven't investigated this much). Firing off a user backup is pretty simple, but I'm not sure how I'd do the equivalent for an existing schedule. The NB scheduler takes into account various local status information like previous successful/unsuccessful runs, current streams on a client/STU, etc. You would have to gather and incorporate all of that information into the remote scheduler, or you'd have to ignore it. Depending on your setups, ignoring it can lead to problems. I've been through this once (but that was with Networker, not NetBackup). There was a lot of hope that the scheduler could handle a lot of off-host processing (disk copies and mounts/unmounts) between machines and coordinate them properly. It took a long time to build because the folks setting up the scheduler didn't have much expertise with backups. And I was limited in the ways I could signal Networker from the scheduler. It also meant that whenever we had a problem, I had to work on the backup issue and the folks that ran the scheduler and try to make them understand the dependency chain that the process was expecting. I think it can still be a good idea in some situations, but it was a lot more work than anyone expected. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the conte
Re: [Veritas-bu] 3rd party scheduling
On Wed, Jan 16, 2008 at 10:35:46AM -0600, Stump, Bob A wrote: > I have seen a trend to stop using NetBackup for starting and monitoring > backups. The move has been to doing all command line backups from a 3rd > party scheduler as part of a true enterprise scheduling, monitoring and > management implementation. NetBackup is simply one of many products that > are controlled by the enterprise 3rd party sheduler/monitor. What are > the drawbacks to moving in this direction? You still require a significant configuration setup in Netbackup (pools, policies, etc.), so you will end up with configuration information in two places. That can complicate maintenance. Most sites don't use them, so you may find it harder to find someone with experience doing this, or have increased training costs when you hire someone. I'm not sure that the ways that the scheduler can launch jobs is completely available to other tools (although maybe it is, since I haven't investigated this much). Firing off a user backup is pretty simple, but I'm not sure how I'd do the equivalent for an existing schedule. The NB scheduler takes into account various local status information like previous successful/unsuccessful runs, current streams on a client/STU, etc. You would have to gather and incorporate all of that information into the remote scheduler, or you'd have to ignore it. Depending on your setups, ignoring it can lead to problems. I've been through this once (but that was with Networker, not NetBackup). There was a lot of hope that the scheduler could handle a lot of off-host processing (disk copies and mounts/unmounts) between machines and coordinate them properly. It took a long time to build because the folks setting up the scheduler didn't have much expertise with backups. And I was limited in the ways I could signal Networker from the scheduler. It also meant that whenever we had a problem, I had to work on the backup issue and the folks that ran the scheduler and try to make them understand the dependency chain that the process was expecting. I think it can still be a good idea in some situations, but it was a lot more work than anyone expected. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] 3rd party scheduling
I used Tidal Scheduler at a previous company to kick off all the backup jobs. It worked great, except for the part where if your Tidal instance goes down, is being upgraded, has bugs, etc, suddenly you're not running any more backup jobs. =) Just something to be aware of with 3rd party schedulers. - John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Lightner Sent: Wednesday, January 16, 2008 9:16 AM To: Stump, Bob A; VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] 3rd party scheduling I've worked at a couple of places that used Tivoli Workload Scheduler (nee Maestro) for batch scheduling for the entire environment. In such environments we would always use that tool rather than NBU's scheduler. I also worked one place that use $U ($Universe) but didn't play much with that scheduler myself since backups were someone else's bailiwick. The benefits to such scheduling tools is typically: 1) You can make the backup job dependent on other tasks completing. 2) You can make the cross platform schedule dependencies. 3) The tool itself gives you logs for how the jobs/schedules were run so you aren't just limited to the part NBU knew. A couple of ways the above has come into play: BCV of Production is done on the Production host by one job. Then the BCV is split and the copy is imported and mounted on a different server. Then the backup of the filesystem is done with no DB running. If the BCV job doesn't complete the backup job doesn't attempt to run so you focus on the real issue (BCV failure) rather than red herring issue (backup failure). SAP/Oracle backups that need to be initiated by the client. Such scheduling tools can be used to insure the DB mode is changed to hot standby as one job then a second job is done to kick off the backup and third job is done to change the DB mode back. Also you can have other jobs on application servers to stop the applications for cold DB backups and restart the applications for hot DB backups. For places that do batch processing (like monthly bill processing) it becomes even more sophisticated because you can insure the job that was doing the current day's bill processing completes BEFORE the DB is stopped. I've seen some fairly major scripts for monitoring TWS at one job but its intent wasn't really to monitor backups but rather overall schedule/job processing of which the backups were just a subset. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stump, Bob A Sent: Wednesday, January 16, 2008 11:36 AM To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] 3rd party scheduling I have seen a trend to stop using NetBackup for starting and monitoring backups. The move has been to doing all command line backups from a 3rd party scheduler as part of a true enterprise scheduling, monitoring and management implementation. NetBackup is simply one of many products that are controlled by the enterprise 3rd party sheduler/monitor. What are the drawbacks to moving in this direction? What are some of the enterprise scheduling and monitoring/management 3rd party solutions have you recently seen? Autosys? Stonebranch? __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] 3rd party scheduling
I've worked at a couple of places that used Tivoli Workload Scheduler (nee Maestro) for batch scheduling for the entire environment. In such environments we would always use that tool rather than NBU's scheduler. I also worked one place that use $U ($Universe) but didn't play much with that scheduler myself since backups were someone else's bailiwick. The benefits to such scheduling tools is typically: 1) You can make the backup job dependent on other tasks completing. 2) You can make the cross platform schedule dependencies. 3) The tool itself gives you logs for how the jobs/schedules were run so you aren't just limited to the part NBU knew. A couple of ways the above has come into play: BCV of Production is done on the Production host by one job. Then the BCV is split and the copy is imported and mounted on a different server. Then the backup of the filesystem is done with no DB running. If the BCV job doesn't complete the backup job doesn't attempt to run so you focus on the real issue (BCV failure) rather than red herring issue (backup failure). SAP/Oracle backups that need to be initiated by the client. Such scheduling tools can be used to insure the DB mode is changed to hot standby as one job then a second job is done to kick off the backup and third job is done to change the DB mode back. Also you can have other jobs on application servers to stop the applications for cold DB backups and restart the applications for hot DB backups. For places that do batch processing (like monthly bill processing) it becomes even more sophisticated because you can insure the job that was doing the current day's bill processing completes BEFORE the DB is stopped. I've seen some fairly major scripts for monitoring TWS at one job but its intent wasn't really to monitor backups but rather overall schedule/job processing of which the backups were just a subset. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stump, Bob A Sent: Wednesday, January 16, 2008 11:36 AM To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] 3rd party scheduling I have seen a trend to stop using NetBackup for starting and monitoring backups. The move has been to doing all command line backups from a 3rd party scheduler as part of a true enterprise scheduling, monitoring and management implementation. NetBackup is simply one of many products that are controlled by the enterprise 3rd party sheduler/monitor. What are the drawbacks to moving in this direction? What are some of the enterprise scheduling and monitoring/management 3rd party solutions have you recently seen? Autosys? Stonebranch? __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] 3rd party scheduling
I have seen a trend to stop using NetBackup for starting and monitoring backups. The move has been to doing all command line backups from a 3rd party scheduler as part of a true enterprise scheduling, monitoring and management implementation. NetBackup is simply one of many products that are controlled by the enterprise 3rd party sheduler/monitor. What are the drawbacks to moving in this direction? What are some of the enterprise scheduling and monitoring/management 3rd party solutions have you recently seen? Autosys? Stonebranch? __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] ExaGrid D2D w/ NBU 5x or 6.5
They've been pitching to us in competition with Data Domain. They do their de-duplication post-write, instead of Data Domain's inline de-dupe, so they claim great speed improvements over Data Domain all day. If your budget doesn't warrant a Data Domain and your backup window is really crunched, you may want to look at them, at least to get Data Domain to bring down prices. - Hadrian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roemmele, Scott Sent: Friday, January 11, 2008 4:09 AM To: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] ExaGrid D2D w/ NBU 5x or 6.5 NBU'ers: Has anyone even heard of ExaGrid? >From the lack of response to my initial question, I assume no one is using >them. Thanks, Scott Roemmele On 1/4/08 10:41 AM, "Roemmele, Scott" <[EMAIL PROTECTED]> wrote: Anybody out there using D2D from ExaGrid along with NBU? How has your experience been? Speed to Backup/Restore? Using Replication between sites? What kind of compression are you seeing? Any info regarding their management & scalability? Any information would be greatly appreciated. Thanks, Scott ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exitstatus=40: network connect
I haven't seen any GigE NICs that allow for anything other than autonegotiate. But then again we aren't using that many of them. This thread started with the common advice regarding 100MB that IT be hard set to 100/Full on both the Server and the Switch. GigE is a completely different animal. There is definitely a performance benefit to setting 100/Full on the 100MB NICs. We've seen that time and time again in our environment (mostly UNIX/Linux). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating Sent: Wednesday, January 16, 2008 10:21 AM To: VERITAS-BU@mailman.eng.auburn.edu Cc: Daniel Otto Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exitstatus=40: network connect resend due to oversize bounce. -- -Original Message- From: Paul Keating Sent: January 16, 2008 10:19 AM To: VERITAS-BU@mailman.eng.auburn.edu Cc: 'Daniel Otto' Subject: RE: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status=40: network connect I'm interested in why your advice differs from that of the IEEE 802.3ab spec. Unless I'm interpreting this doc incorrectly http://standards.ieee.org/reading/ieee/interp/IEEE802.3af-2003interp-6.p df "Selecting 1000BASE-T mode of operation still requires that Auto-Negotiation be used. This can be accomplished by continuing to use Auto-Negotiation while limiting the advertising to 1000BASE-T capabilities." -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Otto Sent: January 16, 2008 9:44 AM To: Abhishek Dhingra1; [EMAIL PROTECTED] Cc: VERITAS-BU@mailman.eng.auburn.edu; [EMAIL PROTECTED] Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status=40: network connect The speed is usually set to either 100 meg or 1000 meg (gigabit) in today's networks. Again hard code both the speed and duplex mode for each switch port and NIC to make sure both connections are set to the same. DO NOT hard code only one side of the connection be it either just the NIC or switch port. This results in a duplex miss-match in most all cases. If duplex mode of these settings is mismatched, then no or very little data can be transmitted and servers or client PCs will fail when they try to send data through the network. Flow control can hard coded also but if left to auto negotiate and if it doesn't link up correctly you should see a lot of input errors on either the NIC or switch port. Finally you may have to tune the NIC to the OS particularly with GIG NICs being they have a higher demand on OS resources. You should engage your system vendor for how to best tune the OS to the NICs. Dan Otto CCIE #2279 La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status=40: network connect
resend due to oversize bounce. -- -Original Message- From: Paul Keating Sent: January 16, 2008 10:19 AM To: VERITAS-BU@mailman.eng.auburn.edu Cc: 'Daniel Otto' Subject: RE: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status=40: network connect I'm interested in why your advice differs from that of the IEEE 802.3ab spec. Unless I'm interpreting this doc incorrectly http://standards.ieee.org/reading/ieee/interp/IEEE802.3af-2003interp-6.p df "Selecting 1000BASE-T mode of operation still requires that Auto-Negotiation be used. This can be accomplished by continuing to use Auto-Negotiation while limiting the advertising to 1000BASE-T capabilities." -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Otto Sent: January 16, 2008 9:44 AM To: Abhishek Dhingra1; [EMAIL PROTECTED] Cc: VERITAS-BU@mailman.eng.auburn.edu; [EMAIL PROTECTED] Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status=40: network connect The speed is usually set to either 100 meg or 1000 meg (gigabit) in today's networks. Again hard code both the speed and duplex mode for each switch port and NIC to make sure both connections are set to the same. DO NOT hard code only one side of the connection be it either just the NIC or switch port. This results in a duplex miss-match in most all cases. If duplex mode of these settings is mismatched, then no or very little data can be transmitted and servers or client PCs will fail when they try to send data through the network. Flow control can hard coded also but if left to auto negotiate and if it doesn't link up correctly you should see a lot of input errors on either the NIC or switch port. Finally you may have to tune the NIC to the OS particularly with GIG NICs being they have a higher demand on OS resources. You should engage your system vendor for how to best tune the OS to the NICs. Dan Otto CCIE #2279 La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status =40: network connect
Warning- Auto negotiation rant ahead.- Auto negotiation was meant for the virtual office where you do not know what type of Nic is being used by the end user. But in environments where you typically know what type of NIC is being used you should hard code the both the NIC and switch ports. A typical 100 meg NIC using auto will get you about ~160 meg of measured bandwidth. If you hard code the links you should be up in the 180-190 range. Same for gig links. Auto negotiation with gig links will get you ~400-600 meg but when you hard code where possible it should be up in the 800-900 range. Pass this on to your management- Speed and duplex mode settings Some vendor features like switch port speed and duplex mode auto-negotiation can by themselves cause intermittent network problems. Most switch vendors support the auto-negotiate feature that is supposed to allow the switch to determine the port settings based on what is optimum for the NIC card. Auto-negotiation issues may result from non-conforming implementation, hardware incapability, or software defects. When NICs or vendor switches do not conform exactly to the IEEE specification 802.3u (100baseT, 802.3z (1000Base-X), 802.3ab (1000Base-T) and GBIC, problems may result. Hardware incompatibility and other issues may also exist as a result of vendor-specific advanced features, such as auto-polarity or cabling integrity, that are not described in the IEEE 802.3u/802.3z/ 802.3ab specifications for 100/1000 Mbps auto-negotiation. Generally, if both the NIC and the switch adhere to the IEEE 802.3u/ 802.3z/ 802.3ab auto-negotiation specifications and all additional features are disabled, auto-negotiation should properly negotiate speed and duplex and no operational issues should exist. However, this rarely works as the vendor claims, and in order to achieve maximum throughput it is best to hard code these settings on the switch port and the NIC card. Note: Some gigabit NIC drivers such as those from Broadcom do not allow for hard coding the speed to 1000meg therefore in this case you are left with using auto-negotiation to get the NIC to run at gig speeds. The speed is usually set to either 100 meg or 1000 meg (gigabit) in today's networks. Again hard code both the speed and duplex mode for each switch port and NIC to make sure both connections are set to the same. DO NOT hard code only one side of the connection be it either just the NIC or switch port. This results in a duplex miss-match in most all cases. If duplex mode of these settings is mismatched, then no or very little data can be transmitted and servers or client PCs will fail when they try to send data through the network. Flow control can hard coded also but if left to auto negotiate and if it doesn't link up correctly you should see a lot of input errors on either the NIC or switch port. Finally you may have to tune the NIC to the OS particularly with GIG NICs being they have a higher demand on OS resources. You should engage your system vendor for how to best tune the OS to the NICs. Dan Otto CCIE #2279 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhishek Dhingra1 Sent: Wednesday, January 16, 2008 8:05 AM To: [EMAIL PROTECTED] Cc: VERITAS-BU@mailman.eng.auburn.edu; [EMAIL PROTECTED] Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status =40: network connect Can you help in getting the document which states that NIC and switch setting should be 100 Mbps/1Gbps full duplex not auto negaotiate, i am running the enivironment in which we have 1 Gbps LAN, NIC and Switch is auto negotiate and most of the backup runs good, but few backups has very less speed. I am unable to prove the auto negotiable thing to my management. Abhishek Dhingra IBM Global Services, Delhi, Email : [EMAIL PROTECTED] Mobile : +91-9818675370 [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/16/2008 07:12 PM To VERITAS-BU@mailman.eng.auburn.edu cc VERITAS-BU@mailman.eng.auburn.edu, [EMAIL PROTECTED] Subject Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: networkconnect We have found this in most cases to be related to NIC settings being our of sync. Or related to firewall performance if the backup is coming through a firewall. For 100MB both NIC and switch should be 100FDX no auto negotiate. There are some regristry hacks to deal with the firewall issue. =i Carl Stehman IT Distributed Services Team Pepco Holdings, Inc. 202-331-6619 Pager 301-765-2703 [EMAIL PROTECTED] dgrabs03 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/16/2008 08:28 AM Please respond to VERITAS-BU@mailman.eng.auburn.edu To VERITAS-BU@mailman.eng.auburn.edu cc Subject [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect Hello there! As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual information I see is 04:27:
[Veritas-bu] Snapshot Client problem on NBU 6.5.1
Hi Anybody out there using new disk array snapshot method in 6.5? We're using HP EVA snapshots with offhost backup (media server is Alt client). Normal file system backups work fine - snapshot takes place, data is offloaded to media server. Oracle rman policy runs successful, BUT the snapshot DOESN'T take place - data is backed up from the client across the network to the media server - NO ERRORS! Any idea why snapshot doesn't take place and backup is done over the network? Attributes of Oracle policy (file system policy is the same, only difference is Policy Type and Backup Selection): Policy Name: ora-snap Options: 0x0 template: FALSE c_unused1: ? Names: (none) Policy Type: Oracle (4) Active:yes Effective date:01/14/2008 19:30:00 Block Incremental: no Mult. Data Stream: no Perform Snapshot Backup: yes Snapshot Method: HP_EVA_Snapshot Snapshot Method Arguments: max_snapshots=1 Perform Offhost Backup:yes Backup Copy: 0 Use Data Mover:no Data Mover Type: 2 Use Alternate Client: yes Alternate Client Name: dbs3 Use Virtual Machine: no Enable Instant Recovery: no Policy Priority: 1 Max Jobs/Policy: 4 Disaster Recovery: 0 Collect BMR Info: no Keyword: (none specified) Data Classification: - Residence is Storage Lifecycle Policy:no Client Encrypt:no Checkpoint:no Residence: dbs3-hcart-robot-tld-0 Regards Marianne ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Yes, i am running Auto-negotiate at both end, and getting the speed of 300
KB/s.
Abhishek Dhingra
IBM Global Services, Delhi,
Email : [EMAIL PROTECTED]
Mobile : +91-9818675370
[EMAIL PROTECTED]
01/16/2008 07:46 PM
To
Abhishek Dhingra1/India/[EMAIL PROTECTED]
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40:
network connect
If the system you are having trouble with has GigE on both ends, and you
are autoneg, your problem is most likely
something else. The 100 Mbps full does not apply.
What speeds are you getting on the slow systems?
=
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
Abhishek Dhingra1 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 09:08 AM
To
[EMAIL PROTECTED]
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status =40:
networkconnect
Can you help in getting the document which states that NIC and switch
setting should be 100 Mbps/1Gbps full duplex not auto negaotiate, i am
running the enivironment in which we have 1 Gbps LAN, NIC and Switch is
auto negotiate and most of the backup runs good, but few backups has very
less speed.
I am unable to prove the auto negotiable thing to my management.
Abhishek Dhingra
IBM Global Services, Delhi,
Email : [EMAIL PROTECTED]
Mobile : +91-9818675370
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
01/16/2008 07:12 PM
To
VERITAS-BU@mailman.eng.auburn.edu
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network
connect
We have found this in most cases to be related to NIC settings being our
of sync.
Or related to firewall performance if the backup is coming through a
firewall.
For 100MB both NIC and switch should be 100FDX no auto negotiate.
There are some regristry hacks to deal with the firewall issue.
=i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
dgrabs03 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 08:28 AM
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
To
VERITAS-BU@mailman.eng.auburn.edu
cc
Subject
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Hello there!
As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual
information I see is
04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40:
network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection
broken
I performed all the name resolution process from nslookup up to the
Netbackup tools "bpclntcmd" all are successful and able to communicate to
both client and the server/media. But the message above frequently appears
on the logs.
Is this a heavy network load issue?
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible
for delivery of this Email to the intended recipient(s), you are hereby
notified that any dissemination, distribution or copying of this Email is
strictly prohibited. If you have received this message in error, please
immediately notify the sender and permanently delete this Email and any
copies. PHI policies expressly prohibit employees from making defamatory
or offensive statements and infringing any copyright or any other legal
right by Email communication. PHI will not accept any liability in respect
of such communications. ___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI")
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
If the system you are having trouble with has GigE on both ends, and you
are autoneg, your problem is most likely
something else. The 100 Mbps full does not apply.
What speeds are you getting on the slow systems?
=
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
Abhishek Dhingra1 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 09:08 AM
To
[EMAIL PROTECTED]
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40:
network connect
Can you help in getting the document which states that NIC and switch
setting should be 100 Mbps/1Gbps full duplex not auto negaotiate, i am
running the enivironment in which we have 1 Gbps LAN, NIC and Switch is
auto negotiate and most of the backup runs good, but few backups has very
less speed.
I am unable to prove the auto negotiable thing to my management.
Abhishek Dhingra
IBM Global Services, Delhi,
Email : [EMAIL PROTECTED]
Mobile : +91-9818675370
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
01/16/2008 07:12 PM
To
VERITAS-BU@mailman.eng.auburn.edu
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network
connect
We have found this in most cases to be related to NIC settings being our
of sync.
Or related to firewall performance if the backup is coming through a
firewall.
For 100MB both NIC and switch should be 100FDX no auto negotiate.
There are some regristry hacks to deal with the firewall issue.
=i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
dgrabs03 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 08:28 AM
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
To
VERITAS-BU@mailman.eng.auburn.edu
cc
Subject
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Hello there!
As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual
information I see is
04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40:
network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection
broken
I performed all the name resolution process from nslookup up to the
Netbackup tools "bpclntcmd" all are successful and able to communicate to
both client and the server/media. But the message above frequently appears
on the logs.
Is this a heavy network load issue?
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible
for delivery of this Email to the intended recipient(s), you are hereby
notified that any dissemination, distribution or copying of this Email is
strictly prohibited. If you have received this message in error, please
immediately notify the sender and permanently delete this Email and any
copies. PHI policies expressly prohibit employees from making defamatory
or offensive statements and infringing any copyright or any other legal
right by Email communication. PHI will not accept any liability in respect
of such communications. ___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and permanently delete this Email and
[Veritas-bu] BackupExec questions
Hello I have just upgraded our BackupExec system to 11D from 11D, after I have some issues: Remote install to one client keeps saying that the is already a connection Another keeps giving Authentication failed on connection even though I can log in with the user the service is running as. This exchange 2007 server was the reason for our upgrade. The third seem to have a problem with the pre/post jobs after the upgrade Any ideas/suggestion will be appreicated Regards Michael ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status =40: network connect
If you're using GigE, you want auto/auto.
There are apparantly some card/drivers that still work better with
100Mb/s links fixed speed/duplex.
In any case both sides (switch/host) must be set the sameeither both
auto, or both fixed.
if you have one side fixed and one side auto, you will end up with the
auto side going to half duplex, which obviously doesn't not communicate
well with the other side being fixed at full duplex.
Paul
--
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Abhishek
Dhingra1
Sent: January 16, 2008 9:05 AM
To: [EMAIL PROTECTED]
Cc: VERITAS-BU@mailman.eng.auburn.edu;
[EMAIL PROTECTED]
Subject: Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status
=40: network connect
Can you help in getting the document which states that NIC and
switch setting should be 100 Mbps/1Gbps full duplex not auto negaotiate,
i am running the enivironment in which we have 1 Gbps LAN, NIC and
Switch is auto negotiate and most of the backup runs good, but few
backups has very less speed.
I am unable to prove the auto negotiable thing to my management.
Abhishek Dhingra
IBM Global Services, Delhi,
Email : [EMAIL PROTECTED]
Mobile : +91-9818675370
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
01/16/2008 07:12 PM
To
VERITAS-BU@mailman.eng.auburn.edu
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40:
networkconnect
We have found this in most cases to be related to NIC settings
being our of sync.
Or related to firewall performance if the backup is coming
through a firewall.
For 100MB both NIC and switch should be 100FDX no auto
negotiate.
There are some regristry hacks to deal with the firewall issue.
=i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
dgrabs03 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 08:28 AM
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
To
VERITAS-BU@mailman.eng.auburn.edu
cc
Subject
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network
connect
Hello there!
As I read the /usr/openv/netbackup/logs/bpbkar/log.. The
usual information I see is
04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status
= 40: network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network
connection broken
I performed all the name resolution process from nslookup up to
the Netbackup tools "bpclntcmd" all are successful and able to
communicate to both client and the server/media. But the message above
frequently appears on the logs.
Is this a heavy network load issue?
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information
that is proprietary, legally privileged, confidential and/or subject to
copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI").
This Email is intended solely for the use of the person(s) to which it
is addressed. If you are not an intended recipient, or the employee or
agent responsible for delivery of this Email to the intended
recipient(s), you are hereby notified that any dissemination,
distribution or copying of this Email is strictly prohibited. If you
have received this message in error, please immediately notify the
sender and permanently delete this Email and any copies. PHI policies
expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by
Email communication. PHI will not accept any liability in respect of
such communications. ___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
La version française suit le texte a
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Can you help in getting the document which states that NIC and switch
setting should be 100 Mbps/1Gbps full duplex not auto negaotiate, i am
running the enivironment in which we have 1 Gbps LAN, NIC and Switch is
auto negotiate and most of the backup runs good, but few backups has very
less speed.
I am unable to prove the auto negotiable thing to my management.
Abhishek Dhingra
IBM Global Services, Delhi,
Email : [EMAIL PROTECTED]
Mobile : +91-9818675370
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
01/16/2008 07:12 PM
To
VERITAS-BU@mailman.eng.auburn.edu
cc
VERITAS-BU@mailman.eng.auburn.edu,
[EMAIL PROTECTED]
Subject
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network
connect
We have found this in most cases to be related to NIC settings being our
of sync.
Or related to firewall performance if the backup is coming through a
firewall.
For 100MB both NIC and switch should be 100FDX no auto negotiate.
There are some regristry hacks to deal with the firewall issue.
=i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
dgrabs03 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 08:28 AM
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
To
VERITAS-BU@mailman.eng.auburn.edu
cc
Subject
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Hello there!
As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual
information I see is
04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40:
network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection
broken
I performed all the name resolution process from nslookup up to the
Netbackup tools "bpclntcmd" all are successful and able to communicate to
both client and the server/media. But the message above frequently appears
on the logs.
Is this a heavy network load issue?
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible
for delivery of this Email to the intended recipient(s), you are hereby
notified that any dissemination, distribution or copying of this Email is
strictly prohibited. If you have received this message in error, please
immediately notify the sender and permanently delete this Email and any
copies. PHI policies expressly prohibit employees from making defamatory
or offensive statements and infringing any copyright or any other legal
right by Email communication. PHI will not accept any liability in respect
of such communications. ___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
We have found this in most cases to be related to NIC settings being our
of sync.
Or related to firewall performance if the backup is coming through a
firewall.
For 100MB both NIC and switch should be 100FDX no auto negotiate.
There are some regristry hacks to deal with the firewall issue.
=i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
[EMAIL PROTECTED]
dgrabs03 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/16/2008 08:28 AM
Please respond to
VERITAS-BU@mailman.eng.auburn.edu
To
VERITAS-BU@mailman.eng.auburn.edu
cc
Subject
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Hello there!
As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual
information I see is
04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40:
network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection
broken
I performed all the name resolution process from nslookup up to the
Netbackup tools "bpclntcmd" all are successful and able to communicate to
both client and the server/media. But the message above frequently appears
on the logs.
Is this a heavy network load issue?
+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is
intended solely for the use of the person(s) to which it is addressed. If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies. PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication. PHI will not accept any liability in respect of such
communications.
___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network connect
Hello there! As I read the /usr/openv/netbackup/logs/bpbkar/log.. The usual information I see is 04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE 04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40: network connection broken 04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection broken I performed all the name resolution process from nslookup up to the Netbackup tools "bpclntcmd" all are successful and able to communicate to both client and the server/media. But the message above frequently appears on the logs. Is this a heavy network load issue? +-- |This was sent by [EMAIL PROTECTED] via Backup Central. |Forward SPAM to [EMAIL PROTECTED] +-- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
