Re: [Veritas-bu] Disable alternate client restores
You can do that by putting the DISALLOW_SERVER_FILE_WRITES parameter in the bp.conf file or equivalent. One thing I haven't tested is whether or not you can overwrite that parameter using the bpsetconfig command. I'm guessing not, but I haven't tried. Curtis Preston | VP Data Protection GlassHouse Technologies, Inc. T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009 [EMAIL PROTECTED] | www.glasshouse.com http://www.glasshouse.com/ Infrastructure :: Optimized From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:31 PM To: veritas-BU Subject: Re: [Veritas-bu] Disable alternate client restores Actually, you can prevent the Master from writing to a particular client: Of course, that doesn't actually address the issue I have...which I don't think has a solution outside of removing the client in question from NBU. But I had to ask :) Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company GTN 446.0592 or 330.796.0592 Ed Wilts [EMAIL PROTECTED] 07/30/2008 08:22 PM To [EMAIL PROTECTED] cc veritas-BU VERITAS-BU@mailman.eng.auburn.edu Subject Re: [Veritas-bu] Disable alternate client restores On Wed, Jul 30, 2008 at 5:38 PM, [EMAIL PROTECTED] wrote: Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. If you are the admin on the master, you can do whatever you want. You can't prevent the master from writing to a particular client of that master. There really isn't such a thing as clientA's data - it's just data that's cataloged for a specific client but by no means is it owned by a particular client. The master could restore it to any client, including itself. It could read it without using NetBackup. Don't annoy the backup admin :-) .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE [EMAIL PROTECTED] This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. image001.gif___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Disable alternate client restores
You can't overwrite it, you have to log on to each server and change it back if you want. Although it has been awhile, I think that the parameter only allows client initiated restores. But I could be wrong. Regards, Patrick Whelan VERITAS Certified NetBackup Support Engineer for UNIX. VERITAS Certified NetBackup Support Engineer for Windows. [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Preston Sent: 31 July 2008 07:42 To: [EMAIL PROTECTED]; veritas-BU Subject: Re: [Veritas-bu] Disable alternate client restores You can do that by putting the DISALLOW_SERVER_FILE_WRITES parameter in the bp.conf file or equivalent. One thing I haven't tested is whether or not you can overwrite that parameter using the bpsetconfig command. I'm guessing not, but I haven't tried. Curtis Preston | VP Data Protection GlassHouse Technologies, Inc. T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009 [EMAIL PROTECTED] | www.glasshouse.com http://www.glasshouse.com/ Infrastructure :: Optimized _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:31 PM To: veritas-BU Subject: Re: [Veritas-bu] Disable alternate client restores Actually, you can prevent the Master from writing to a particular client: Of course, that doesn't actually address the issue I have...which I don't think has a solution outside of removing the client in question from NBU. But I had to ask :) Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company GTN 446.0592 or 330.796.0592 Ed Wilts [EMAIL PROTECTED] 07/30/2008 08:22 PM To [EMAIL PROTECTED] cc veritas-BU VERITAS-BU@mailman.eng.auburn.edu Subject Re: [Veritas-bu] Disable alternate client restores On Wed, Jul 30, 2008 at 5:38 PM, [EMAIL PROTECTED] wrote: Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. If you are the admin on the master, you can do whatever you want. You can't prevent the master from writing to a particular client of that master. There really isn't such a thing as clientA's data - it's just data that's cataloged for a specific client but by no means is it owned by a particular client. The master could restore it to any client, including itself. It could read it without using NetBackup. Don't annoy the backup admin :-) .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE [EMAIL PROTECTED] This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. image001.gif___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Disable alternate client restores
Er... all except enabling the encryption and compression on the policy, that is, but the client configuration can be set to require encryption (although not, so far as I can tell, compression, so you could end up wasting backup image space if you don't do that right on the server side). -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 8:45 AM To: '[EMAIL PROTECTED]'; veritas-BU Subject: RE: [Veritas-bu] Disable alternate client restores Enable client-side encryption (and compression) for all clients. Create a unique key on each client, and make the administrator(s) of that client responsible for maintaining their key (and a backup at least of its passphrase through ANOTHER means). Exclude the key data from backups. All of those are client-side configurations. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:38 PM To: veritas-BU Subject: [Veritas-bu] Disable alternate client restores Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. Thanks, Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Informix Backup failing with Error 13
Dear All, I installed a NBU 6.5.1 media server on a HP-UX box. The File System backup of this box on its own storage-unit works fine whereas the Informix backup fails with Error 13. Here is the screen of shot of the exact error. 07/31/2008 19:54:21 - started process bpbrm (pid=1068) 07/31/2008 19:54:29 - connecting 07/31/2008 19:54:36 - connected; connect time: 0:00:00 07/31/2008 19:54:43 - mounting 0148L2 07/31/2008 19:55:38 - mounted 0148L2; mount time: 0:00:55 07/31/2008 19:55:38 - positioning 0148L2 to file 1 07/31/2008 19:55:45 - positioned 0148L2; position time: 0:00:07 07/31/2008 19:55:45 - begin writing 07/31/2008 19:58:35 - Error bpbrm (pid=1762) socket read failed: errno = 52 - Stream ioctl timeout 07/31/2008 20:00:58 - end writing; write time: 0:05:13 file read failed (13) If the same Informix backup is sent through another media server, it works fine. Please advise if you faced similar problem or know the reason for this failure. Regards, Neeraj ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Disable alternate client restores
Enable client-side encryption (and compression) for all clients. Create a unique key on each client, and make the administrator(s) of that client responsible for maintaining their key (and a backup at least of its passphrase through ANOTHER means). Exclude the key data from backups. All of those are client-side configurations. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:38 PM To: veritas-BU Subject: [Veritas-bu] Disable alternate client restores Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. Thanks, Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Status 23: socket read failed _ on 6.5.2 W2K3 Master
Recently upgraded our test environment Master server from 6.0MP5 to 6.5MP2 Now receiving intermittent errors. From Job Details: Status 23: socket read failed 7/29/2008 6:07:51 PM - Info bpdbm(pid=2812) deleted 1 expired records, compressed 0, tir removed 0, deleted 0 expired copies socket read failed(23) From All Log Entries report: 7/29/2008 6:07:52 PM Media ServerXYZ ClientXYZ Error 0 General Could not build host list: database system error Nothing interesting in the .evt logs during the affected timeframe. Any ideas? Thank you, Kent Eagle [EMAIL PROTECTED] Visit our website at www.wilmingtontrust.com Investment products are not insured by the FDIC or any other governmental agency, are not deposits of or other obligations of or guaranteed by Wilmington Trust or any other bank or entity, and are subject to risks, including a possible loss of the principal amount invested. This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Disable the restore feature from all clients
Disable the restore feature from all clients our internal audit wants to disable the restore function from all the netbackup clients. all restore should ba initate from the netbackup server how can i do this ? Cortal Consors S.A. Zweigniederlassung Deutschland, Bahnhofstraße 55, D-90402 Nürnberg, HR Nürnberg B 20075, USt-IdNr. DE225900761 Sitz der Cortal Consors S.A.: 1, boulevard Haussmann, F-75318 Paris cedex 09, Registergericht: R.C.S. Paris 327 787 909 Président du Conseil d'Administration (Verwaltungsratsvorsitzender) und Directeur Général (Generaldirektor) der CortalConsors S.A.: Olivier Le Grand Leitung der Zweigniederlassung Deutschland: Martin Daut (CEO Deutschland), Olivier Le Grand, Richard Döppmann, Uwe Trittin___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Informix Backup failing with Error 13
Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It looks like you're using LTO-2 media and your robotic device is passing all 8 characters through to NetBackup (not all can be configured not to) and you don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf, but you probably want one, although addding one now may be a bit touchy, since you've already inventoried a bunch of tapes with the traily L2, and you'll need to blow the media and vol DB entries for those away and recreat them, which will definitely be a mess. (Cf, http://seer.support.veritas.com/docs/236271.htm.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:04 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Informix Backup failing with Error 13 Dear All, I installed a NBU 6.5.1 media server on a HP-UX box. The File System backup of this box on its own storage-unit works fine whereas the Informix backup fails with Error 13. Here is the screen of shot of the exact error. 07/31/2008 19:54:21 - started process bpbrm (pid=1068) 07/31/2008 19:54:29 - connecting 07/31/2008 19:54:36 - connected; connect time: 0:00:00 07/31/2008 19:54:43 - mounting 0148L2 07/31/2008 19:55:38 - mounted 0148L2; mount time: 0:00:55 07/31/2008 19:55:38 - positioning 0148L2 to file 1 07/31/2008 19:55:45 - positioned 0148L2; position time: 0:00:07 07/31/2008 19:55:45 - begin writing 07/31/2008 19:58:35 - Error bpbrm (pid=1762) socket read failed: errno = 52 - Stream ioctl timeout 07/31/2008 20:00:58 - end writing; write time: 0:05:13 file read failed (13) If the same Informix backup is sent through another media server, it works fine. Please advise if you faced similar problem or know the reason for this failure. Regards, Neeraj ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Netbackup verify at write time
When I worked at a major pharmaceutical we had a procedure to do periodic test restores and compare that to the data that should have been there. This was always fun given things that don't backup such as door files on Sun etc... FDA Validation requirements make S-OX look like a walk in the park. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of spaldam Sent: Wednesday, July 30, 2008 11:38 PM To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] Netbackup verify at write time The best thing I can say is: Make Multiple Copies. This is why I always make sure I have at least 2 copies of my next longest retention before expiring the shorter retention(S). For example: If you do weekly full backups, keep you're daily incremental backups for at least 2 weeks. In turn, if you're monthly backups have a longer retention, keep your weekly full backups for at least 2 months. Even if you verify the tape using a restore to be absolutely certain, that tape will eventually deteriorate, and could potentially get damaged. Any kind of electronic media is far from indestructible. If you truly paranoid, don't rely on your backup system as your only point of recovery. Backup systems should be first and foremost designed for disaster recovery (although if you have the funds replication works even better), and secondarily for long term legal and archival purposes, and lastly as an operational recovery mechanism. There are much better ways to insure operational recovery (i.e. versioning filesystems) if you are truly that paranoid. I'm not saying your backup system can't do all three, and do them very well, but there are other methods that work better for giving your management the warm fuzzy they are looking for. Of course if all they really want is a warm fuzzy, just find some marketing documents that say the likely hood of a problem is extremely low (there are plenty of them out there). +-- |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 -- 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] Informix Backup failing with Error 13
Dear Gabriel, Thanks for your quick reply. The funny thing is that the other media server through which it is going fine is also installed today and doesn't have any CLIENT_READ_TIMEOUT. The values are all default. Another funny thing is that the media server through which the Informix backup is going fine is giving the same error 13 for its own Informix backup. This server's Informix backup is going fine through first media server's storage-unit. So, basically I installed 3 NBU6.5.1 media servers. All of them are not able to take their own Informix backups but are able to take each other's backup. All these media servers have default CLIENT_READ_TIMEOUT and CLIENT_CONNECT_TIMEOUT. I think I will follow your advise and try to change the CLIENT_READ_TIMEOUT and try a backup. Previously, all these had NBU 4.5 media server software installed and had increased TIMEOUT values. Secondly, thanks for your observation about barcodes. Actually the bar code is 8 characters but media ID is generated using last 6 characters. I don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf. I will read the technote to understand its benefits. Regards, Neeraj From: Rosenkoetter, Gabriel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:49 PM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It looks like you're using LTO-2 media and your robotic device is passing all 8 characters through to NetBackup (not all can be configured not to) and you don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf, but you probably want one, although addding one now may be a bit touchy, since you've already inventoried a bunch of tapes with the traily L2, and you'll need to blow the media and vol DB entries for those away and recreat them, which will definitely be a mess. (Cf, http://seer.support.veritas.com/docs/236271.htm.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:04 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Informix Backup failing with Error 13 Dear All, I installed a NBU 6.5.1 media server on a HP-UX box. The File System backup of this box on its own storage-unit works fine whereas the Informix backup fails with Error 13. Here is the screen of shot of the exact error. 07/31/2008 19:54:21 - started process bpbrm (pid=1068) 07/31/2008 19:54:29 - connecting 07/31/2008 19:54:36 - connected; connect time: 0:00:00 07/31/2008 19:54:43 - mounting 0148L2 07/31/2008 19:55:38 - mounted 0148L2; mount time: 0:00:55 07/31/2008 19:55:38 - positioning 0148L2 to file 1 07/31/2008 19:55:45 - positioned 0148L2; position time: 0:00:07 07/31/2008 19:55:45 - begin writing 07/31/2008 19:58:35 - Error bpbrm (pid=1762) socket read failed: errno = 52 - Stream ioctl timeout 07/31/2008 20:00:58 - end writing; write time: 0:05:13 file read failed (13) If the same Informix backup is sent through another media server, it works fine. Please advise if you faced similar problem or know the reason for this failure. Regards, Neeraj ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] How do you report on utilization?
An update from Symantec. Apparently the current version of CCS allows you to collect from bpdbjobs and bpimagelist and choose which to use for your utilization reporting. -- Brian J. Greenberg http://briangreenberg.net ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Informix Backup failing with Error 13
Hrm... Come to think of it, even if you don't have a big honking bpstart_notify script in place, I distantly recall something about Informix and BPSTART_TIMEOUT. You might want to do a bpgetconfig | grep TIMEOUT and google all of those settings for relevancy: I always have to go dig around on which is the appropriate setting for a given timeout issue anew. It's odd that the behavior would be different between the media server running local to the client and remote: you may want to check that your SysV IPC values are tuned sufficiently (because the issue may be timing out waiting for message queue or shared memory slots to become available). My old standard, http://seer.support.veritas.com/docs/243461.htm, says that the 6.x Backup Planning and Performance Tuning Guide for [blah blah blah] includes updated version of everything that's there, so dig through your PDFs for that. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 10:13 AM To: Rosenkoetter, Gabriel; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Dear Gabriel, Thanks for your quick reply. The funny thing is that the other media server through which it is going fine is also installed today and doesn't have any CLIENT_READ_TIMEOUT. The values are all default. Another funny thing is that the media server through which the Informix backup is going fine is giving the same error 13 for its own Informix backup. This server's Informix backup is going fine through first media server's storage-unit. So, basically I installed 3 NBU6.5.1 media servers. All of them are not able to take their own Informix backups but are able to take each other's backup. All these media servers have default CLIENT_READ_TIMEOUT and CLIENT_CONNECT_TIMEOUT. I think I will follow your advise and try to change the CLIENT_READ_TIMEOUT and try a backup. Previously, all these had NBU 4.5 media server software installed and had increased TIMEOUT values. Secondly, thanks for your observation about barcodes. Actually the bar code is 8 characters but media ID is generated using last 6 characters. I don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf. I will read the technote to understand its benefits. Regards, Neeraj _ From: Rosenkoetter, Gabriel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:49 PM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It looks like you're using LTO-2 media and your robotic device is passing all 8 characters through to NetBackup (not all can be configured not to) and you don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf, but you probably want one, although addding one now may be a bit touchy, since you've already inventoried a bunch of tapes with the traily L2, and you'll need to blow the media and vol DB entries for those away and recreat them, which will definitely be a mess. (Cf, http://seer.support.veritas.com/docs/236271.htm.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:04 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Informix Backup failing with Error 13 Dear All, I installed a NBU 6.5.1 media server on a HP-UX box. The File System backup of this box on its own storage-unit works fine whereas the Informix backup fails with Error 13. Here is the screen of shot of the exact error. 07/31/2008 19:54:21 - started process bpbrm (pid=1068) 07/31/2008 19:54:29 - connecting 07/31/2008 19:54:36 - connected; connect time: 0:00:00 07/31/2008 19:54:43 - mounting 0148L2 07/31/2008 19:55:38 - mounted 0148L2; mount time: 0:00:55 07/31/2008 19:55:38 - positioning 0148L2 to file 1 07/31/2008 19:55:45 - positioned 0148L2; position time: 0:00:07 07/31/2008 19:55:45 - begin writing 07/31/2008 19:58:35 - Error bpbrm (pid=1762) socket read failed: errno = 52 - Stream ioctl timeout 07/31/2008 20:00:58 - end writing; write time: 0:05:13 file read failed (13) If the same Informix backup is sent through another media server, it works fine. Please
Re: [Veritas-bu] Informix Backup failing with Error 13
Been a long time since I've done Informix but CLIENT_READ_TIMEOUT? needs to be large 1/2 hour to 1hour. Same issues with Oracle. The time to get the database ready to start sending data can be significant. I believe the timeout values can be assocated with the User Account the backup is driven from. Look for a ~/bp.conf on the client. All user jobs (Database) look at ~/bp.conf before the netbackup/bp.conf Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 9:09 AM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Informix Backup failing with Error 13 Hrm... Come to think of it, even if you don't have a big honking bpstart_notify script in place, I distantly recall something about Informix and BPSTART_TIMEOUT. You might want to do a bpgetconfig | grep TIMEOUT and google all of those settings for relevancy: I always have to go dig around on which is the appropriate setting for a given timeout issue anew. It's odd that the behavior would be different between the media server running local to the client and remote: you may want to check that your SysV IPC values are tuned sufficiently (because the issue may be timing out waiting for message queue or shared memory slots to become available). My old standard, http://seer.support.veritas.com/docs/243461.htm, says that the 6.x Backup Planning and Performance Tuning Guide for [blah blah blah] includes updated version of everything that's there, so dig through your PDFs for that. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 10:13 AM To: Rosenkoetter, Gabriel; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Dear Gabriel, Thanks for your quick reply. The funny thing is that the other media server through which it is going fine is also installed today and doesn't have any CLIENT_READ_TIMEOUT. The values are all default. Another funny thing is that the media server through which the Informix backup is going fine is giving the same error 13 for its own Informix backup. This server's Informix backup is going fine through first media server's storage-unit. So, basically I installed 3 NBU6.5.1 media servers. All of them are not able to take their own Informix backups but are able to take each other's backup. All these media servers have default CLIENT_READ_TIMEOUT and CLIENT_CONNECT_TIMEOUT. I think I will follow your advise and try to change the CLIENT_READ_TIMEOUT and try a backup. Previously, all these had NBU 4.5 media server software installed and had increased TIMEOUT values. Secondly, thanks for your observation about barcodes. Actually the bar code is 8 characters but media ID is generated using last 6 characters. I don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf. I will read the technote to understand its benefits. Regards, Neeraj _ From: Rosenkoetter, Gabriel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:49 PM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It looks like you're using LTO-2 media and your robotic device is passing all 8 characters through to NetBackup (not all can be configured not to) and you don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf, but you probably want one, although addding one now may be a bit touchy, since you've already inventoried a bunch of tapes with the traily L2, and you'll need to blow the media and vol DB entries for those away and recreat them, which will definitely be a mess. (Cf, http://seer.support.veritas.com/docs/236271.htm.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:04 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Informix Backup failing with Error 13 Dear All, I installed a NBU 6.5.1 media server on a HP-UX box. The File System backup of this box on its own storage-unit works fine whereas the Informix backup fails with Error 13. Here is the screen of shot of the
Re: [Veritas-bu] Disable alternate client restores
Wanted to say thanks to everyone for their responses; none of them actually address our issue, but at least I can now tell the business owners it definitely can't be done. Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Removing 6.5.2 and going back to 6.5.1
Hi, I have NBU 652 on a Windows 2003 master and media server setup. Has anyone ever removed a maintenance pack and if so, what kinds of ramifications have you had? I currently only have 2 clients upgraded to 6.5.2, the rest are on 6.5.1. Also, which would I remove first, master or media? Will I have to reinstall tape drivers? Thanks for any help on this. Mike +-- |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
Re: [Veritas-bu] Removing 6.5.2 and going back to 6.5.1
I had two media server I had to uninstall Netbackup completely and reinstall when I recently went through this with rolling back 6.5.2A. The other 12 media servers and the master went fine, thank goodness. I removed master first as it seemed logical to me. I did not have to deal with tape drive drivers but I am using the OEM drivers. Regards. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mconner1201 Sent: Thursday, July 31, 2008 7:52 AM To: VERITAS-BU@mailman.eng.auburn.edu Subject: [Veritas-bu] Removing 6.5.2 and going back to 6.5.1 Hi, I have NBU 652 on a Windows 2003 master and media server setup. Has anyone ever removed a maintenance pack and if so, what kinds of ramifications have you had? I currently only have 2 clients upgraded to 6.5.2, the rest are on 6.5.1. Also, which would I remove first, master or media? Will I have to reinstall tape drivers? Thanks for any help on this. Mike +-- |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 ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Removing 6.5.2 and going back to 6.5.1
On Thu, Jul 31, 2008 at 9:51 AM, mconner1201 [EMAIL PROTECTED] wrote: Hi, I have NBU 652 on a Windows 2003 master and media server setup. Has anyone ever removed a maintenance pack and if so, what kinds of ramifications have you had? I currently only have 2 clients upgraded to 6.5.2, the rest are on 6.5.1. Also, which would I remove first, master or media? Will I have to reinstall tape drivers? You should log a call with Symantec. I'm sure that there are bits and pieces that will bite you if you're not careful. They may also have fixes for any problems you've currently got so that you don't have to be revert at all. None of us on the list really know if there are changes in the images you've saved since your upgrade that 6.5.1 doesn't know about. If there have been, there could be a chance that you may not be able to restore. Unlikely, but you don't want to guess wrong either. The master always has to be the highest version, so you'd reverse all you've done. Revert the clients, then the media servers, and lastly the master. I don't know what happens if you violate these rules - at a minimum, you won't be at a supported configuration. It might work, it might not. On the master, you've got to be concerned about the changes to the STREAMS files. The same issue that bit some people because the 6.5.2 upgrade triggered full backups on all of their clients will get you when you revert - because the STREAMS files have been renamed, reverting without renaming the files back will likely trigger full backups on all of your clients again. You could, of course, revert *everything* to where you were before you did your upgrade. The downside of that would be losing all of the backups you've done since you upgraded. LOG A CALL. This is not something you want to get wrong. .../Ed -- Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE [EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Removing 6.5.2 and going back to 6.5.1
On Thu, 31 Jul 2008, mconner1201 wrote: Hi, I have NBU 652 on a Windows 2003 master and media server setup. Has anyone ever removed a maintenance pack and if so, what kinds of ramifications have you had? I currently only have 2 clients upgraded to 6.5.2, the rest are on 6.5.1. Also, which would I remove first, master or media? Will I have to reinstall tape drivers? Thanks for any help on this. Mike +-- |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 I've done it before with 6.0x/5.x awhile ago, I suffered no ill-effects but I have not tested it with 6.5.x, as you know the master must always be the newest, so I would downgrade the media servers and clients first then the master server. Justin. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Disable the restore feature from all clients
Wow, I didn't realize Symantec had stopped shipping The Fine Manual with the product! ;^ DISALLOW_CLIENT_RESTORE sure sounds like the configuration option you're after. Check your OS-specific Adminisration guide for the details. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:28 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Disable the restore feature from all clients Disable the restore feature from all clients our internal audit wants to disable the restore function from all the netbackup clients. all restore should ba initate from the netbackup server how can i do this ? Cortal Consors S.A. Zweigniederlassung Deutschland, Bahnhofstraße 55, D-90402 Nürnberg, HR Nürnberg B 20075, USt-IdNr. DE225900761 Sitz der Cortal Consors S.A.: 1, boulevard Haussmann, F-75318 Paris cedex 09, Registergericht: R.C.S. Paris 327 787 909 Président du Conseil d'Administration (Verwaltungsratsvorsitzender) und Directeur Général (Generaldirektor) der CortalConsors S.A.: Olivier Le Grand Leitung der Zweigniederlassung Deutschland: Martin Daut (CEO Deutschland), Olivier Le Grand, Richard Döppmann, Uwe Trittin ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Informix Backup failing with Error 13
Um... CLIENT_READ_TIMEOUT is a media-server-specific setting, so it can't live in ~/bp.conf, even for user-directed backups. (The media server's bptm will still give up waiting for data from the client's bpcd before bpbkar has even spooled up to send anything.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Jim Horalek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 12:33 PM To: Rosenkoetter, Gabriel; 'Neeraj Puri (DHL MY)'; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Been a long time since I've done Informix but CLIENT_READ_TIMEOUT? needs to be large 1/2 hour to 1hour. Same issues with Oracle. The time to get the database ready to start sending data can be significant. I believe the timeout values can be assocated with the User Account the backup is driven from. Look for a ~/bp.conf on the client. All user jobs (Database) look at ~/bp.conf before the netbackup/bp.conf Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 9:09 AM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Informix Backup failing with Error 13 Hrm... Come to think of it, even if you don't have a big honking bpstart_notify script in place, I distantly recall something about Informix and BPSTART_TIMEOUT. You might want to do a bpgetconfig | grep TIMEOUT and google all of those settings for relevancy: I always have to go dig around on which is the appropriate setting for a given timeout issue anew. It's odd that the behavior would be different between the media server running local to the client and remote: you may want to check that your SysV IPC values are tuned sufficiently (because the issue may be timing out waiting for message queue or shared memory slots to become available). My old standard, http://seer.support.veritas.com/docs/243461.htm, says that the 6.x Backup Planning and Performance Tuning Guide for [blah blah blah] includes updated version of everything that's there, so dig through your PDFs for that. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 10:13 AM To: Rosenkoetter, Gabriel; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Dear Gabriel, Thanks for your quick reply. The funny thing is that the other media server through which it is going fine is also installed today and doesn't have any CLIENT_READ_TIMEOUT. The values are all default. Another funny thing is that the media server through which the Informix backup is going fine is giving the same error 13 for its own Informix backup. This server's Informix backup is going fine through first media server's storage-unit. So, basically I installed 3 NBU6.5.1 media servers. All of them are not able to take their own Informix backups but are able to take each other's backup. All these media servers have default CLIENT_READ_TIMEOUT and CLIENT_CONNECT_TIMEOUT. I think I will follow your advise and try to change the CLIENT_READ_TIMEOUT and try a backup. Previously, all these had NBU 4.5 media server software installed and had increased TIMEOUT values. Secondly, thanks for your observation about barcodes. Actually the bar code is 8 characters but media ID is generated using last 6 characters. I don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf. I will read the technote to understand its benefits. Regards, Neeraj _ From: Rosenkoetter, Gabriel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:49 PM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It
Re: [Veritas-bu] Disable alternate client restores
Wow, Gabe! While the might solve the problem, that's about the scariest most convoluted key management system I've ever heard! Too many keys to lose for my tastes. I have to say it again. Wow. I think the fumes from the coke plants in Philly have gotten to your brain, dude. ;) (For those playing at home, that's coal or petroleum coke (see http://en.wikipedia.org/wiki/Coke_(fuel)), and http://en.wikipedia.org/wiki/Petroleum_coke) not Cocaine or Coca-Cola, OK?) Curtis Preston | VP Data Protection GlassHouse Technologies, Inc. T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009 [EMAIL PROTECTED] | www.glasshouse.com http://www.glasshouse.com/ Infrastructure :: Optimized From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 5:45 AM To: [EMAIL PROTECTED]; veritas-BU Subject: Re: [Veritas-bu] Disable alternate client restores Enable client-side encryption (and compression) for all clients. Create a unique key on each client, and make the administrator(s) of that client responsible for maintaining their key (and a backup at least of its passphrase through ANOTHER means). Exclude the key data from backups. All of those are client-side configurations. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:38 PM To: veritas-BU Subject: [Veritas-bu] Disable alternate client restores Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. Thanks, Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Disable alternate client restores
Yeah, I was not, perhaps, sufficiently clear: I think that's a totally psychotic approach, but I think the requirement that the master server not be able to redirect restores to an alternate client is a totally psychotic mandate (and is bound for tears in a DR situation, even if the restriction weren't implemented by misusing encryption and adopting a broken-by-design key management system), but I did want to point out that it was technically possible to bend the product to that purpose, despite Ed's assertions otherwise. I guess I thought the absurdity of the solution spoke for itself... And, thankfully, I neither live nor work anywhere near close enough to the Platt Bridge for those fumes, but I suppose one could blame Camden. Or whatever's left in the soil in Kensington from Back in the Day, though my tomatoes don't seem to mind. (Kidding. The tomatoes are in raised beds with non-native dirt. I'm not THAT dumb... ;^) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Curtis Preston [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 3:49 PM To: Rosenkoetter, Gabriel; [EMAIL PROTECTED]; veritas-BU Subject: RE: [Veritas-bu] Disable alternate client restores Wow, Gabe! While the might solve the problem, that's about the scariest most convoluted key management system I've ever heard! Too many keys to lose for my tastes. I have to say it again. Wow. I think the fumes from the coke plants in Philly have gotten to your brain, dude. ;) (For those playing at home, that's coal or petroleum coke (see http://en.wikipedia.org/wiki/Coke_(fuel)), and http://en.wikipedia.org/wiki/Petroleum_coke) not Cocaine or Coca-Cola, OK?) Curtis Preston | VP Data Protection GlassHouse Technologies, Inc. T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009 [EMAIL PROTECTED] | www.glasshouse.com http://www.glasshouse.com/ Infrastructure :: Optimized _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 5:45 AM To: [EMAIL PROTECTED]; veritas-BU Subject: Re: [Veritas-bu] Disable alternate client restores Enable client-side encryption (and compression) for all clients. Create a unique key on each client, and make the administrator(s) of that client responsible for maintaining their key (and a backup at least of its passphrase through ANOTHER means). Exclude the key data from backups. All of those are client-side configurations. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 6:38 PM To: veritas-BU Subject: [Veritas-bu] Disable alternate client restores Running 6.5.1, have been asked if it's possible to restrict the Master server from restoring a particular client's images to alternate clients. I know we can restrict one client from restoring another client's data; I know I can prevent the Master from writing to a particular client. What I haven't been able to determine is if I can keep the Master from writing clientA's data to clientB. Thanks, Ken Zufall Technical Analyst D660C The Goodyear Tire Rubber Company This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Netbackup verify at write time
Jeff Lightner said: FDA Validation requirements make S-OX look like a walk in the park. What HE said! This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Netbackup verify at write time
-Original Message- From: [EMAIL PROTECTED] [mailto:veritas-bu-[EMAIL PROTECTED] On Behalf Of Curtis Preston Sent: Thursday, July 31, 2008 12:44 PM To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Netbackup verify at write time Jeff Lightner said: FDA Validation requirements make S-OX look like a walk in the park. What HE said! Agree wholeheartedly! Stuart, thoughts? Knut ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Bpschedreq in 6.5
Post! On Thu, 31 Jul 2008, schmaustech wrote: I wrote a Perl scriot that allows you to determine which policies and schedules will kick off on a given day. It also can display a histogram of how many jobs per hour are kicked off. Let me know if interested. +-- |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 ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Informix Backup failing with Error 13
Could be. Informix was on the Media Server. And like I said its a while ago. I just remember doing a lot of things to ~/bp.conf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 11:14 AM To: Jim Horalek; veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Informix Backup failing with Error 13 Um... CLIENT_READ_TIMEOUT is a media-server-specific setting, so it can't live in ~/bp.conf, even for user-directed backups. (The media server's bptm will still give up waiting for data from the client's bpcd before bpbkar has even spooled up to send anything.) -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Jim Horalek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 12:33 PM To: Rosenkoetter, Gabriel; 'Neeraj Puri (DHL MY)'; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Been a long time since I've done Informix but CLIENT_READ_TIMEOUT? needs to be large 1/2 hour to 1hour. Same issues with Oracle. The time to get the database ready to start sending data can be significant. I believe the timeout values can be assocated with the User Account the backup is driven from. Look for a ~/bp.conf on the client. All user jobs (Database) look at ~/bp.conf before the netbackup/bp.conf Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosenkoetter, Gabriel Sent: Thursday, July 31, 2008 9:09 AM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Informix Backup failing with Error 13 Hrm... Come to think of it, even if you don't have a big honking bpstart_notify script in place, I distantly recall something about Informix and BPSTART_TIMEOUT. You might want to do a bpgetconfig | grep TIMEOUT and google all of those settings for relevancy: I always have to go dig around on which is the appropriate setting for a given timeout issue anew. It's odd that the behavior would be different between the media server running local to the client and remote: you may want to check that your SysV IPC values are tuned sufficiently (because the issue may be timing out waiting for message queue or shared memory slots to become available). My old standard, http://seer.support.veritas.com/docs/243461.htm, says that the 6.x Backup Planning and Performance Tuning Guide for [blah blah blah] includes updated version of everything that's there, so dig through your PDFs for that. -- gabriel rosenkoetter Radian Group Inc, Unix/Linux/VMware Sysadmin / Backup Recovery [EMAIL PROTECTED], 215 231 1556 _ From: Neeraj Puri (DHL MY) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 10:13 AM To: Rosenkoetter, Gabriel; veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Dear Gabriel, Thanks for your quick reply. The funny thing is that the other media server through which it is going fine is also installed today and doesn't have any CLIENT_READ_TIMEOUT. The values are all default. Another funny thing is that the media server through which the Informix backup is going fine is giving the same error 13 for its own Informix backup. This server's Informix backup is going fine through first media server's storage-unit. So, basically I installed 3 NBU6.5.1 media servers. All of them are not able to take their own Informix backups but are able to take each other's backup. All these media servers have default CLIENT_READ_TIMEOUT and CLIENT_CONNECT_TIMEOUT. I think I will follow your advise and try to change the CLIENT_READ_TIMEOUT and try a backup. Previously, all these had NBU 4.5 media server software installed and had increased TIMEOUT values. Secondly, thanks for your observation about barcodes. Actually the bar code is 8 characters but media ID is generated using last 6 characters. I don't have a MEDIA_ID_BARCODE_CHARS setting in vm.conf. I will read the technote to understand its benefits. Regards, Neeraj _ From: Rosenkoetter, Gabriel [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:49 PM To: Neeraj Puri (DHL MY); veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Informix Backup failing with Error 13 Looks like you need to raise CLIENT_READ_TIMEOUT (and maybe, but probably not, CLIENT_CONNECT_TIMEOUT; don't try that unless only READ isn't enough) on the media server trying to write its own Informix backups. (I presume you had, long ago, raised this value on the other media server for a similar problem.) The circumstance in which you'd need to bump CONNECT_TIMEOUT too is f you've got a lengthy backup_start_notify in place (to, say, put Informix in backup mode or something like that). As an aside, that's a pretty kooky volser. It looks like you're using LTO-2 media and your
Re: [Veritas-bu] IBM Pseries backups over IVE
Just wondering if anyone has done LPAR to LPAR backups of IBM P6-series boxes across the IVE (Integrated Virtual Ethernet). We've got a bunch of P570's coming in the door and what I'm thinking is something like this: - Each LPAR should communicate to the other LPARs on the same frame via the IVE and never leave the box, this should enable very, very fast LPAR to LPAR communication. - The NBU licensing is per frame thus could make each LPAR it's own media server but managing that many media servers adds overhead on my side and making each a media would probably drive up HBA costs. - So one media per frame backing up the other LPARS on that frame as clients. - NET_BUFFER_SZ will definitely need to be tweaked, in theory we should be able to get several hundred MB/s per frame. - I believe this will work without creating any dedicated virtual backup network. Without any special configuration or required interfaces I believe it will know what is local and send traffic appropriately. Anyone ever configured Pseries backups this way? I have searched far and wide and have not been able to find any BDPs for backing up this hardware. Geoff Stafford Barclaycard US Data Protection Engineering office: mobile: Barclays www.barclaycardus.com This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] IBM Pseries backups over IVE
On Thu, Jul 31, 2008 at 05:21:55PM -0400, Stafford, Geoff wrote: Anyone ever configured Pseries backups this way? I have searched far and wide and have not been able to find any BDPs for backing up this hardware. Yes, we've done it this way on p5. You will need to tweak host files on your master server as your internal VLAN is not visible to the master, so the metadata needs to go via the external LAN address. The actually backup data is then constrained to the high speed internal VLAN. Don't forget to change the MTU on the interfaces on the internal VLAN NIC - we use 65394 which dramtically reduces hypervisor overhead due to fragmentation. Note that this won't work if you intend to route your internal VLAN externally. HTH, Dale ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
