Symantec Connect - Backup and Recovery

Veritas NetBackup Enterprise Server v5.1 Win2k3 64bit crack keygen

Veritas NetBackup Enterprise Server v5.1 Win2k3 64bit crack keygen

PTA ProtecTIER Enterprise Edition V software. Disaster recovery with ProtecTIER OST and Symantec NetBackup. I want to backup just 1 MS SQL database on my server (out of 13 dbs). as Veritas already include this functionality for free with NetBackup - of course. Red Hat Enterprise Linux/CentOS 4.x with a minimum of glibc Intel Pentium, Itanium, x64 over" from one server to another, which includes stopping.

watch the video

How To Install Veritas NetBackup 8.1.2 Master Server On Windows Server 2008

Veritas NetBackup Enterprise Server v5.1 Win2k3 64bit crack keygen - that would

[Veritas-bu] Linux, libraries and NBU

ThreadSpellacy, Sean

Good day Folks Having some issues with visibility of libraries robots and tape drives on a Redhat Media server. Not being a native 'nix admin I could use a hand. Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 5), Elsmp 4x HP MSL Libraries with 2x E NSRs and 4x LTO4 a piece Under r2 x64 Windows master (MSCS cluster) Robot control host, emm, catalog Shared storage option Along with 3x r2 x64 media servers (these see all devices) So on the RH: All the devices are visible when cat is run against /proc/scsi/scsi Also if I review the HBA hosts at the emulex HBAcmd all devices are visible. If I service netbackup stop and run hp_ltt (library tape tools) I see one library vs 4, I see 7 NSRs vs 8, and 12 drives vs Having the netbackup service and running tpautoconf from the local linux shows the same thing. Running Device discovery from the NBU console shows the same thing also. Tpautoconf -report_disc Shows I have some missing paths that are my robots and a couple of new drives but I am not sure what to make of this as all serial numbers seem to show true to what is existing in the libs. (see below body) I feel like I am on the cusp of fixing this but I am missing some syntax or bit on knowledge for cleaning this up. Looking at tpconfig also but the switch combos there look potentially hostile, though the menu drive looks more friendly. Your input would be appreciated as to recommended method to proceed in sorting this out. Thanks in advance Regards SSS Sean Spellacy Senior Technical Analyst, IMIT, Backup and AntiVirus Vancouver Island Health Authority storycall.us@storycall.us storycall.us

[Veritas-bu] Linux backup issue

ThreadSaran Brar

Hello Folks, Below is my netbackup environment: Master - Solaris 10 , Netbackup Media - Solaris 10, Netbackup Client - Suse Linux , Netbackup Backup for the client is completing with status code 0 but in the detailed status its showing below warnings Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /share is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /net is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /var is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /sys is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /boot is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /dev is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /opt is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /proc is on file system type PROC. Skipping. Since we upgraded from to , all unix backups are showing these warnings but are completing with status code 0. I googled for the error but not able to find a suitable answer for it. Can anyone please explain why is that so? Thanks in Advance, Saran ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux backup issue

ThreadLightner, Jeff

The messages seem to indicate you have deselected Cross Mount Points in the storycall.us you checked that? It is saying it didn't back up these items as they are on separate mount points. If you do df -h on the Linux host it should show you what mounts exist. We actually had an issue here recently on where we found something had caused that to be deselected in several of our policies. We think it was due to an attempt to manually edit the policies from command line a few months back. At the time that happened it caused other issues as well. Apparently there is a checksum NBU stores internally for what is in the policies so it didn't like that manual modification. Also FYI: We typically add /net, /sys and /proc to our exclude lists for Linux. /net is a shortcut to NFS mounts so unless you intend to back them up via /net probably good to exclude that. /proc and /sys aren't actual disk filesystems so can't be backed up - attempts to do so typically result in a status 1 rather than status 0 on your backup. From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Saran Brar Sent: Thursday, March 24, PM To: veritas-bu@storycall.us Subject: [Veritas-bu] Linux backup issue Hello Folks, Below is my netbackup environment: Master - Solaris 10 , Netbackup Media - Solaris 10, Netbackup Client - Suse Linux , Netbackup Backup for the client is completing with status code 0 but in the detailed status its showing below warnings Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /share is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /net is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /var is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /sys is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /boot is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /dev is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /opt is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /proc is on file system type PROC. Skipping. Since we upgraded from to , all unix backups are showing these warnings but are completing with status code 0. I googled for the error but not able to find a suitable answer for it. Can anyone please explain why is that so? Thanks in Advance, Saran Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- 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@storycall.us storycall.us

Re: [Veritas-bu] Linux backup issue

ThreadChapman, Scott

I get all those same warnings on redhat hosts whether I've got cross mount points selected or not I'm using ALL_LOCAL_DRIVES so it does appear to be backing stuff up, as I do have data in /boot and one or two others it's complaining about Scott Chapman Senior Technical Specialist Storage and Database Administration ICBC - Victoria Ph: Cell: From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Lightner, Jeff Sent: Thursday, March 24, AM To: veritas-bu@storycall.us Subject: Re: [Veritas-bu] Linux backup issue The messages seem to indicate you have deselected Cross Mount Points in the storycall.us you checked that? It is saying it didn't back up these items as they are on separate mount points. If you do df -h on the Linux host it should show you what mounts exist. We actually had an issue here recently on where we found something had caused that to be deselected in several of our policies. We think it was due to an attempt to manually edit the policies from command line a few months back. At the time that happened it caused other issues as well. Apparently there is a checksum NBU stores internally for what is in the policies so it didn't like that manual modification. Also FYI: We typically add /net, /sys and /proc to our exclude lists for Linux. /net is a shortcut to NFS mounts so unless you intend to back them up via /net probably good to exclude that. /proc and /sys aren't actual disk filesystems so can't be backed up - attempts to do so typically result in a status 1 rather than status 0 on your backup. From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Saran Brar Sent: Thursday, March 24, PM To: veritas-bu@storycall.us Subject: [Veritas-bu] Linux backup issue Hello Folks, Below is my netbackup environment: Master - Solaris 10 , Netbackup Media - Solaris 10, Netbackup Client - Suse Linux , Netbackup Backup for the client is completing with status code 0 but in the detailed status its showing below warnings Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /share is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /net is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /var is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /sys is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /boot is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /dev is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /opt is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /proc is on file system type PROC. Skipping. Since we upgraded from to , all unix backups are showing these warnings but are completing with status code 0. I googled for the error but not able to find a suitable answer for it. Can anyone please explain why is that so? Thanks in Advance, Saran Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- 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. -- This email and any attachments are intended only for the named recipient and may contain confidential and/or privileged material. Any unauthorized copying, dissemination or other use by a person other than the named recipient of this communication is prohibited. If you received this in error or are not named as a recipient, please notify the sender and destroy all copies of this email immediately. ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux backup issue

ThreadLightner, Jeff

We don't use ALL_LOCAL_DRIVES on our Unix and Linux systems. We specify / (root filesystem) for our OS backups then use exclude lists to leave out the things we don't want. Usually our databases and applications have their own policies starting at their mount points OR aren't backed up because they are test/dev and our policy is to refresh them from Production backups if they have issues. It may be the reason you're seeing the messages is that ALL_LOCAL_DRIVES is essentially being seen as all mount points by NBU so it first backs up / and gives the error from / perspective then moves on to /boot then /var etc That is it may be NBU behind the scenes is doing: / backup - complains about all submounts not part of / itself /boot backup /var backup You might test that theory by create a small submount of one of the others e.g. /var/test then see if you get complaint about /var/test not being part of /var (as opposed to not being part of /). From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Chapman, Scott Sent: Thursday, March 24, PM To: Lightner, Jeff; 'veritas-bu@storycall.us' Subject: Re: [Veritas-bu] Linux backup issue I get all those same warnings on redhat hosts whether I've got cross mount points selected or not I'm using ALL_LOCAL_DRIVES so it does appear to be backing stuff up, as I do have data in /boot and one or two others it's complaining about Scott Chapman Senior Technical Specialist Storage and Database Administration ICBC - Victoria Ph: Cell: From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Lightner, Jeff Sent: Thursday, March 24, AM To: veritas-bu@storycall.us Subject: Re: [Veritas-bu] Linux backup issue The messages seem to indicate you have deselected Cross Mount Points in the storycall.us you checked that? It is saying it didn't back up these items as they are on separate mount points. If you do df -h on the Linux host it should show you what mounts exist. We actually had an issue here recently on where we found something had caused that to be deselected in several of our policies. We think it was due to an attempt to manually edit the policies from command line a few months back. At the time that happened it caused other issues as well. Apparently there is a checksum NBU stores internally for what is in the policies so it didn't like that manual modification. Also FYI: We typically add /net, /sys and /proc to our exclude lists for Linux. /net is a shortcut to NFS mounts so unless you intend to back them up via /net probably good to exclude that. /proc and /sys aren't actual disk filesystems so can't be backed up - attempts to do so typically result in a status 1 rather than status 0 on your backup. From: veritas-bu-boun@storycall.us [mailto:veritas-bu-boun@storycall.us] On Behalf Of Saran Brar Sent: Thursday, March 24, PM To: veritas-bu@storycall.us Subject: [Veritas-bu] Linux backup issue Hello Folks, Below is my netbackup environment: Master - Solaris 10 , Netbackup Media - Solaris 10, Netbackup Client - Suse Linux , Netbackup Backup for the client is completing with status code 0 but in the detailed status its showing below warnings Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /share is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /net is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /var is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /sys is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /boot is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /dev is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /opt is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /proc is on file system type PROC. Skipping. Since we upgraded from to , all unix backups are showing these warnings but are completing with status code 0. I googled for the error but not able to find a suitable answer for it. Can anyone please explain why is that so? Thanks in Advance, Saran Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail

Re: [Veritas-bu] Linux backup issue

ThreadSaran Brar

Thanks for the replies. We have setup following entries in the backup selection without cross mount points selected. / /boot /opt /var I double checked in the backup image and it seems it is skipping some files which I am not sure of. By using exclude lists we will not backup at all which we do not want. Please help how to get it done. Thanks, Saran On Thu, Mar 24, at PM, Lightner, Jeff jlight@storycall.uste: We don’t use ALL_LOCAL_DRIVES on our Unix and Linux systems. We specify / (root filesystem) for our OS backups then use exclude lists to leave out the things we don’t want. Usually our databases and applications have their own policies starting at their mount points OR aren’t backed up because they are test/dev and our policy is to refresh them from Production backups if they have issues. It may be the reason you’re seeing the messages is that “ALL_LOCAL_DRIVES” is essentially being seen as “all mount points” by NBU so it first backs up / and gives the error from / perspective then moves on to /boot then /var etc… That is it may be NBU behind the scenes is doing: / backup – complains about all submounts not part of / itself /boot backup /var backup You might test that theory by create a small submount of one of the others e.g. /var/test then see if you get complaint about /var/test not being part of /var (as opposed to not being part of /). -- *From:* veritas-bu-boun@storycall.us [mailto: veritas-bu-boun@storycall.us] *On Behalf Of *Chapman, Scott *Sent:* Thursday, March 24, PM *To:* Lightner, Jeff; 'veritas-bu@storycall.us' *Subject:* Re: [Veritas-bu] Linux backup issue I get all those same warnings on redhat hosts whether I’ve got cross mount points selected or not… I’m using ALL_LOCAL_DRIVES so it does appear to be backing stuff up, as I do have data in /boot and one or two others it’s complaining about… *Scott Chapman* Senior Technical Specialist Storage and Database Administration ICBC - Victoria Ph: Cell: *From:* veritas-bu-boun@storycall.us [mailto: veritas-bu-boun@storycall.us] *On Behalf Of *Lightner, Jeff *Sent:* Thursday, March 24, AM *To:* veritas-bu@storycall.us *Subject:* Re: [Veritas-bu] Linux backup issue The messages seem to indicate you have deselected “Cross Mount Points” in the storycall.us you checked that? It is saying it didn’t back up these items as they are on separate mount points. If you do “df –h” on the Linux host it should show you what mounts exist. We actually had an issue here recently on where we found something had caused that to be deselected in several of our policies. We think it was due to an attempt to manually edit the policies from command line a few months back. At the time that happened it caused other issues as well. Apparently there is a checksum NBU stores internally for what is in the policies so it didn’t like that manual modification. Also FYI: We typically add /net, /sys and /proc to our exclude lists for Linux. /net is a shortcut to NFS mounts so unless you intend to back them up via /net probably good to exclude that. /proc and /sys aren’t actual disk filesystems so can’t be backed up – attempts to do so typically result in a status 1 rather than status 0 on your backup. -- *From:* veritas-bu-boun@storycall.us [mailto: veritas-bu-boun@storycall.us] *On Behalf Of *Saran Brar *Sent:* Thursday, March 24, PM *To:* veritas-bu@storycall.us *Subject:* [Veritas-bu] Linux backup issue Hello Folks, Below is my netbackup environment: Master - Solaris 10 , Netbackup Media - Solaris 10, Netbackup Client - Suse Linux , Netbackup Backup for the client is completing with status code 0 but in the detailed status its showing below warnings Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /share is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /net is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /var is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /sys is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /boot is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /dev is in a different file system from /. Skipping. Mar 24, AM - Info bpbrm (pid=) from client whplmoscyc1: TRV - /opt is in a different file system from

[Veritas-bu] Linux catalog file system

ThreadNate Sanders

What are you all using for your catalog filesystem on linux? While ext3 claims it doesn't need defragging we see a huge performance increase when we rebuild the file system once every 6 months. So I'm curious to know if XFS or VxFS work any better and/or are supported? I think XFS was not support or may still not be. -- Nate SandersDigital Motorworks System Administrator () - This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux catalog file system

ThreadJustin Piszcz

Hi, Using ext3 here on the production systems. It depends on what your catalog looks like and how many simultaenous backup/restores you are doing at any one time. For some catalogs with 1M+ files I'd suggest ext3, ext4 at some point. XFS (while it is being worked on) typically does not bode well with many files. Could you use BRTFS / ReiserFS / etc? Yes, but for mission-critical systems (master servers) IMO it is best to use what the majority of the population use so you do not run into a weird error that causes problems down the line. That is currently ext3, at least with RHEL3-RHEL5. I used to use XFS for personal use for a long time, it worked great, but it was always slow when deleting lots of small files or working with a lot of files. In addition, over the years there were some data loss issue with one kernel and I got bitten a couple of times. I think XFS is great if you are needing a high-performance FS for large files, EXT4 as well. But I would think you would want the most stable/tried and true filesystem that the most people use/etc you would want to use ext3. Justin. On Wed, 15 Sep , Nate Sanders wrote: What are you all using for your catalog filesystem on linux? While ext3 claims it doesn't need defragging we see a huge performance increase when we rebuild the file system once every 6 months. So I'm curious to know if XFS or VxFS work any better and/or are supported? I think XFS was not support or may still not be. -- Nate SandersDigital Motorworks System Administrator () - This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux catalog file system

ThreadNate Sanders

catalog is 65GB and only 47k inodes. Not large by any means. Single master/media server. I may try the dir_index option on ext3 to see if that gives us any longer term performance increase. On 09/15/ AM, Justin Piszcz wrote: Hi, Using ext3 here on the production systems. It depends on what your catalog looks like and how many simultaenous backup/restores you are doing at any one time. For some catalogs with 1M+ files I'd suggest ext3, ext4 at some point. XFS (while it is being worked on) typically does not bode well with many files. Could you use BRTFS / ReiserFS / etc? Yes, but for mission-critical systems (master servers) IMO it is best to use what the majority of the population use so you do not run into a weird error that causes problems down the line. That is currently ext3, at least with RHEL3-RHEL5. I used to use XFS for personal use for a long time, it worked great, but it was always slow when deleting lots of small files or working with a lot of files. In addition, over the years there were some data loss issue with one kernel and I got bitten a couple of times. I think XFS is great if you are needing a high-performance FS for large files, EXT4 as well. But I would think you would want the most stable/tried and true filesystem that the most people use/etc you would want to use ext3. Justin. On Wed, 15 Sep , Nate Sanders wrote: What are you all using for your catalog filesystem on linux? While ext3 claims it doesn't need defragging we see a huge performance increase when we rebuild the file system once every 6 months. So I'm curious to know if XFS or VxFS work any better and/or are supported? I think XFS was not support or may still not be. -- Nate SandersDigital Motorworks System Administrator () - This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us . -- Nate SandersDigital Motorworks System Administrator () - This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

[Veritas-bu] Linux Client files Access ( Netbackup Entrpr.)

Threadk asalam

Dear Sirs, How can i brows or Access Clients files from the Netbackup Master server, its ony listed Server Files and Database only, i installed Client application in all Clients, after the client installation i can able to see all clients are connected to the Master Server, but cant able to list all clients Files or database in the Backup Files (Directory Structure) all clients are Enterprise Linux x86_64 (Oracle Linux ) Netbakup installed in Rhel 4. update 5 (x86_64) Redhat Your earliest reply is highly appreciated Thank you Salam +-- -WindowsMaster It was drives 1 and 2 that were gone. However, Windows sees them fine. Checked fiber cabling on the Linux box. Fine. Checked and actually reconfigured it's zone on the switch. Looked in dmesg logs. There, I find that there are suddenly scsi reservation conflicts. Log snippet: st: Version , bufsize , max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0 Attached scsi tape st1 at scsi1, channel 0, id 1, lun 0 Attached scsi tape st2 at scsi2, channel 0, id 0, lun 0 usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st1: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 st1:can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, st1:defs for wr: 1, no block limits: 0, partitions: 0, s2 log: 0 st1:sysv: 0 nowait: 0 st1: Default block size set to 0 bytes. st1: Density default set to 0 st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). As you can see, st1 is functional. The other two fail to present to the server. So far, we've not found a solution, and I'm not sure that either software or the tape library vendor would help. Suggestions? Thanks, Jason Jason Brooks Computer Systems Engineer IITS - Longwood University voice - () fax - () mailto:[EMAIL PROTECTED] Do the drives have tapes stuck in them? ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us smime.p7s Description: S/MIME cryptographic signature ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

[Veritas-bu] Linux vs Solaris

ThreadTharindu Rukshan Bamunuarachchi

Dear All, Thankx everybody for the compatibility info. We are going to use NetBackup Server for Linux x But Out NetBackup Clients are running on Solaris x (Around 40 machines) Can NetBackup Solaris client connect to NetBackup Linux server ? Pls help, Thankx Tharindu On 3/29/07, Marianne Van Den Berg [EMAIL PROTECTED] wrote: Have a look at the Compatibility Guide: storycall.us Regards Marianne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tharindu Rukshan Bamunuarachchi Sent: 28 March To: veritas-bu@storycall.us Subject: [Veritas-bu] NetBackup Server for Solaris x86 Dear All, Can someone (from Veritas) confirm availability of following product? Veritas NetBackup Master Server for Solaris x86 (Not for SPARC; for x86) Thankx Tharindu -- Tharindu Rukshan Bamunuarachchi all fabrications are subject to decay ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us -- Tharindu Rukshan Bamunuarachchi all fabrications are subject to decay ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

[Veritas-bu] Linux Routing

ThreadMartin, Jonathan \(Contractor\)

I've got a client I'm trying to get working on a dedicated backend for backup and its kickin' my butt. NBU MP6 client on a Redhat linux 3 server. Here's the routing table: Destination Gateway Genmask Flags Metric RefUse Iface * U 0 00 eth0 ( public frontend) * U 0 00 eth1 ( private backend) default UG0 00 eth0 is the front end (public network) and is the back end. I can ping to/form this machine on both the front and backends. I can connect to FTP on both the front and back ends. I can telnet into bpcd from the client and other servers into the front end. I can telnet into bpcd from the client to its backend. However, when I try telnet bpcd from a master or media the connect times out. As far as I can tell routing is fine, because everything except bpcd works on the backend. Any ideas? Does the client not pickup changes to routing on the fly? I've been beating my head against the wall for a few hours here, I've got plenty of other servers with backend IPs and they all work just fine w/ my config. /sigh -Jonathan ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux Routing

ThreadPaul Keating

Is this a client or a NBU server? if it is a client, does it have SERVER = entry for the backup interface of the master/media server? If this is the client. /etc/hosts client client-bu master master-bu storycall.us SERVER=master SERVER=media SERVER=master-bu- ??? SERVER=media-bu- ??? Is the master on both the backup and non-backup LANs as well? or just the BU LAN? Paul -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Jonathan (Contractor) Sent: April 3, AM To: veritas-bu@storycall.us Subject: [Veritas-bu] Linux Routing I've got a client I'm trying to get working on a dedicated backend for backup and its kickin' my butt. NBU MP6 client on a Redhat linux 3 server. Here's the routing table: Destination Gateway Genmask Flags Metric Ref Use Iface * U 0 0 0 eth0 ( public frontend) * U 0 0 0 eth1 ( private backend) default UG0 0 0 eth0 is the front end (public network) and is the back end. I can ping to/form this machine on both the front and backends. I can connect to FTP on both the front and back ends. I can telnet into bpcd from the client and other servers into the front end. I can telnet into bpcd from the client to its backend. However, when I try telnet bpcd from a master or media the connect times out. As far as I can tell routing is fine, because everything except bpcd works on the backend. Any ideas? Does the client not pickup changes to routing on the fly? I've been beating my head against the wall for a few hours here, I've got plenty of other servers with backend IPs and they all work just fine w/ my config. /sigh -Jonathan 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@storycall.us storycall.us

[Veritas-bu] Linux client with Logical Volume Manager

ThreadEdwin Bader

Hi, It looks like Netbackup does recognize the logical volumes as separate drives but it doesn't recognize the partitions on it as being the actual local drives. This causes for example /usr1 and every directory below to be backed up, INCLUDING /usr1/XX and /usr1/XX and /usr1/XXX, while these are also backed up because they're on a different logical volume . On top of that chance are that the root directory (/) and everything below, including ALL separate logical volumes are being backup again! I have never encountered this behavior ant thoughts or suggestions? Thanks, Edwin ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux client with Logical Volume Manager

ThreadPaul Keating

Do you have the cross mount points box checked in the policy? If you do a df on your box, each of the individual listings there should be what netbackup interprets as separate partitions. Paul -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edwin Bader Sent: March 16, AM To: veritas-bu@storycall.us Subject: [Veritas-bu] Linux client with Logical Volume Manager Hi, It looks like Netbackup does recognize the logical volumes as separate drives but it doesn't recognize the partitions on it as being the actual local drives. This causes for example /usr1 and every directory below to be backed up, INCLUDING /usr1/XX and /usr1/XX and /usr1/XXX, while these are also backed up because they're on a different logical volume . On top of that chance are that the root directory (/) and everything below, including ALL separate logical volumes are being backup again! I have never encountered this behavior ant thoughts or suggestions? Thanks, Edwin 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@storycall.us storycall.us

[Veritas-bu] Linux KEEPALIVE error

ThreadAnas Kayal ??? ???? ??????

I have just migrated a Alpha UNIX machine to RedHat Ent 4. Machine is very stable and running perfect. I have oracle running on it and I take daily backups of the DB dump files perfectly and really fast. I tried taking a full backup at the end of the week using just a / for the backup selection. It got through half the backup then I got a cant write KEEPALIVE to COMM_SOCK I checked Veritas and stated it has to do with the network connections/configs. Everything looks ok. Any suggestions? Anas ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

[Veritas-bu] Linux SCSI driver dump

ThreadJuan Pablo Almeida

Hi, In our enviroment (1 linux master ,2 linux media, 20 sdlt SCSI) we are experiencing several SCSI Dumps messages during backup windows. SCSI driver aic7xxx version Does anybody have seen this?

Re: [Veritas-bu] Linux Media Server

ThreadJuan Pablo Almeida

Hi Hasif, We are currently using 2 Linux RHASu8 Media Servers Dell PE Quad Xeon Ghz 4 GB Ram, and one Linux RHASu8 Master Server Dell PE Dual Xeon 6 GB Ram Previously we were using one Sun E Quad /Solaris 8 Master/Media Server. We are very satisfied with the results. We used the Veritas doc NBsoftwarePerformanceTuningpdf to do the planning. The problems we encountered: scsi driver aic7xxx (Adaptec AHAU/UW / AHAxx - HVD) panics at about 1 Gb/seg remote ndmp is unavaliable on NBU / Linux, only in 6.x Att, Juan Almeida Any guidance how to build a linux media server? - Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. E-mail classificado pelo Identificador de Spam Inteligente Terra. Para alterar a categoria classificada, visite storycall.us?+_u=storycall.usa_l=1,storycall.us,,Des15,Des15 Esta mensagem foi verificada pelo E-mail Protegido Terra. Scan engine: McAfee VirusScan / Atualizado em 07/02/ / Versão: / Proteja o seu e-mail Terra: storycall.us ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux Media Server

ThreadDominik . J . Pietrzykowski

Источник: [storycall.us]
C: +1 This was sent by jcr@storycall.us via Backup Central. -WindowsMaster It was drives 1 and 2 that were gone. However, Windows sees them fine. Checked fiber cabling on the Linux box. Fine. Checked and actually reconfigured it's zone on the switch. Looked in dmesg logs. There, I find that there are suddenly scsi reservation conflicts. Log snippet: st: Version , bufsize , max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0 Attached scsi tape st1 at scsi1, channel 0, id 1, lun 0 Attached scsi tape st2 at scsi2, channel 0, id 0, lun 0 usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st1: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 st1:can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, st1:defs for wr: 1, no block limits: 0, partitions: 0, s2 log: 0 st1:sysv: 0 nowait: 0 st1: Default block size set to 0 bytes. st1: Density default set to 0 st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). As you can see, st1 is functional. The other two fail to present to the server. So far, we've not found a solution, and I'm not sure that either software or the tape library vendor would help. Suggestions? Thanks, Jason Jason Brooks Computer Systems Engineer IITS - Longwood University voice - () fax - () mailto:[EMAIL PROTECTED] Do the drives have tapes stuck in them? ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux Media Server Tape Drive Issues

ThreadBrooks, Jason

No, they didn't. I gave in and called support. We shutdown NetBackup and the servers. Went and shut down our ADIC. Brought it back up, restarted servers and NBU. All back. While the Windows box didn't have any issues with the ADIC with regard to the tape drives, the Linux box evidently had some reservations that didn't get removed with the ADIC on the power down when power failed. I still don't know if the ADIC lost power, but I'm guessing it didn't, resulting in the problems. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Piszcz Sent: Wednesday, May 30, AM To: Brooks, Jason Cc: veritas-bu@storycall.us Subject: Re: [Veritas-bu] Linux Media Server Tape Drive Issues On Wed, 30 May , Brooks, Jason wrote: Yesterday, we had a major power outage and some servers went down ungracefully, namely our Linux Media Server. When power was restored, the Windows Master and Linux Media server came up fine. My Windows box saw the two drives for it, the Linux box only saw one of three. The tape drives are zoned as follows: SwitchDrive3-LinuxMediaServer SwitchDrive1-LinuxMedia -WindowsMaster -WindowsMaster It was drives 1 and 2 that were gone. However, Windows sees them fine. Checked fiber cabling on the Linux box. Fine. Checked and actually reconfigured it's zone on the switch. Looked in dmesg logs. There, I find that there are suddenly scsi reservation conflicts. Log snippet: st: Version , bufsize , max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0 Attached scsi tape st1 at scsi1, channel 0, id 1, lun 0 Attached scsi tape st2 at scsi2, channel 0, id 0, lun 0 usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st1: Mode 0 options: buffer writes: 0, async writes: 0, read ahead: 0 st1:can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0, st1:defs for wr: 1, no block limits: 0, partitions: 0, s2 log: 0 st1:sysv: 0 nowait: 0 st1: Default block size set to 0 bytes. st1: Density default set to 0 st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st0: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). st2: Error 18 (sugg. bt 0x0, driver bt 0x0, host bt 0x0). As you can see, st1 is functional. The other two fail to present to the server. So far, we've not found a solution, and I'm not sure that either software or the tape library vendor would help. Suggestions? Thanks, Jason Jason Brooks Computer Systems Engineer IITS - Longwood University voice - () fax - () mailto:[EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ Veritas-bu maillist - Veritas-bu@storycall.us storycall.us

Re: [Veritas-bu] Linux Media Server Tape Drive Issues

ThreadJustin Piszcz

On Wed, 30 May , Brooks, Jason wrote: Yesterday, we had a major power outage and some servers went down ungracefully, namely our Linux Media Server. When power was restored, the Windows Master and Linux Media server came up fine. My Windows box saw the two drives for it, the Linux box only saw one of three. The tape drives are zoned as follows: SwitchDrive3-LinuxMediaServer SwitchDrive1-LinuxMedia Veritas NetBackup Enterprise Server v5.1 Win2k3 64bit crack keygen

Notice: Undefined variable: z_bot in /sites/storycall.us/security/veritas-netbackup-enterprise-server-v51-win2k3-64bit-crack-keygen.php on line 99

Notice: Undefined variable: z_empty in /sites/storycall.us/security/veritas-netbackup-enterprise-server-v51-win2k3-64bit-crack-keygen.php on line 99

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *