Veritas netbackup

[Brian@MCC]

Is anyone using this successfully? We can't seem to get it to work on the backup server side. The service is running but on the mail server but the backup server can't connect.

Netbackup 6.5

Edit: Going to "top" you don't see the service as running. Port scans show no port available to connect at 13722 and 13724 which is what it should be connecting to. Backup server side says simply "can't connect".

[dwmtractor]

I suppose these are obvious questions, but obvious often gets overlooked in my house. . .

Have you verified that you can ping/telnet/whatever to your mail server from the machine that's running Veritas backup? Are they on the same subnet or different ones (e.g. mailserver in DMZ)? Have you checked for open ports?

This document from Symantec discusses port requirements for Veritas Backup Exec and it appears to me that it's not trivial. Very good chance that one or more of the required ports are blocked or misrouted.

Dan

[jholder]

This bug also might be useful:
Bug 11423 - disaster recovery through server to server sync (beta)

[Brian@MCC]

Is there a config file within zimbra where you modify what ports are open or closed?
During the install we are required to make sure that the linux firewall is open, so I'm wondering if there is something in zimbra what we need to modify.

And yes, you can ping all day and it is not on a DMZ.

[dwmtractor]

Is there a config file within zimbra where you modify what ports are open or closed?
During the install we are required to make sure that the linux firewall is open, so I'm wondering if there is something in zimbra what we need to modify.

And yes, you can ping all day and it is not on a DMZ.

No, Zimbra doesn't control open or closed ports at all. That'll only be done either on an external firewall/router, or on the Linux firewall on the box itself.

I'm going out on a limb here because I haven't actually used BackupExec's netbackup feature (I ftp backup files to my backup box and then use BackupExec just to back the ftp archives to removable media). Is BE, perhaps, installed on a machine with Windows Firewall (XP or Vista) enabled? Does it perhaps block access to things that aren't in your Windows domain? I'm not sure what protocols BE net uses for authentication/security. . .

[Brian@MCC]

One thing to mention that I've just discovered, I can't browse our windows domain from within the zimbra server. I'm not familiar with how that's done (never worked with it before, I've just always had it work). Is there anything I'm doing wrong here?

Edit: Let me rephrase that, I can see the servers on the windows network, however when I try to mount a share I get an error "the folder contents could not be displayed" do not have the permissions necessary.

[dwmtractor]

One thing to mention that I've just discovered, I can't browse our windows domain from within the zimbra server. I'm not familiar with how that's done (never worked with it before, I've just always had it work). Is there anything I'm doing wrong here?

Edit: Let me rephrase that, I can see the servers on the windows network, however when I try to mount a share I get an error "the folder contents could not be displayed" do not have the permissions necessary.

To browse a Windows domain from a Linux box requires Samba, which I have never used myself, though there are plenty of folks on this forum who have. Linux machines cannot, by default, read Windows shares. Frankly, for security purposes (since your mail server is open at least partly to the public) it's a good idea to keep that barrier intact, I should think.

Actually now that I think of it, what do you mean when you say you can see the servers? Are you just able to resolve their ips from their names (which would be just DNS doing its jobs) or can you see, but not mount, the shares? If the latter you must already have installed Samba? But then permissions aren't right. . .If this is the case, and you're running an Active Directory server (as I'm guessing) did you get the chance to put in a user id and password for the share? Your Linux box is (probably) not part of your AD domain, so the userid would have to be user@domain (the active directory domain) to get it to authenticate. . .

The backup exec daemon for your Linux mail server should be capable of overcoming this issue though. Veritas/Symantec certainly understand the ins and outs of Linux and Windows environments.

This is a scattering of thoughts I know; hopefully one of them can jog something for you. . .

[imarks001]

Can you post the results of "netstat -tulnp" and "iptables -nL" from your server? This should show the ports that are listening and if iptables is allowing the connections.

[Brian@MCC]

Can you post the results of "netstat -tulnp" and "iptables -nL" from your server? This should show the ports that are listening and if iptables is allowing the connections.

netstat -tulnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:20000 0.0.0.0:* LISTEN 3802/perl
tcp 0 0 0.0.0.0:901 0.0.0.0:* LISTEN 3531/xinetd
tcp 0 0 10.1.1.84:389 0.0.0.0:* LISTEN 4178/slapd
tcp 0 0 0.0.0.0:997 0.0.0.0:* LISTEN 3359/rpc.statd
tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 862/amavisd (ch3-av
tcp 0 0 0.0.0.0:5801 0.0.0.0:* LISTEN 9011/Xvnc
tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 6235/master
tcp 0 0 127.0.0.1:7306 0.0.0.0:* LISTEN 5001/mysqld
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 9504/smbd
tcp 0 0 127.0.0.1:7307 0.0.0.0:* LISTEN 4570/mysqld
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 9011/Xvnc
tcp 0 0 0.0.0.0:3310 0.0.0.0:* LISTEN 6091/clamd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 3339/portmap
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 3892/perl
tcp 0 0 0.0.0.0:6001 0.0.0.0:* LISTEN 9011/Xvnc
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 6235/master
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 3478/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 6235/master
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 9504/smbd
tcp 0 0 :::993 :::* LISTEN 5794/java
tcp 0 0 :::7780 :::* LISTEN 6092/httpd
tcp 0 0 :::7047 :::* LISTEN 4671/kvoop
tcp 0 0 :::110 :::* LISTEN 5794/java
tcp 0 0 :::143 :::* LISTEN 5794/java
tcp 0 0 :::80 :::* LISTEN 5794/java
tcp 0 0 :::6001 :::* LISTEN 9011/Xvnc
tcp 0 0 :::7025 :::* LISTEN 5794/java
tcp 0 0 :::22 :::* LISTEN 3516/sshd
tcp 0 0 :::7035 :::* LISTEN 5794/java
tcp 0 0 :::7071 :::* LISTEN 5794/java
udp 0 0 10.1.1.84:137 0.0.0.0:* 9509/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 9509/nmbd
udp 0 0 10.1.1.84:138 0.0.0.0:* 9509/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 9509/nmbd
udp 0 0 0.0.0.0:10000 0.0.0.0:* 3892/perl
udp 0 0 0.0.0.0:20000 0.0.0.0:* 3802/perl
udp 0 0 0.0.0.0:991 0.0.0.0:* 3359/rpc.statd
udp 0 0 0.0.0.0:994 0.0.0.0:* 3359/rpc.statd
udp 0 0 0.0.0.0:111 0.0.0.0:* 3339/portmap
udp 0 0 0.0.0.0:631 0.0.0.0:* 3478/cupsd
udp 0 0 10.1.1.84:123 0.0.0.0:* 3549/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 3549/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 3549/ntpd
udp 0 0 :::123 :::* 3549/ntpd






iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_IN:'

Chain FORWARD (policy ACCEPT)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_OUT:'
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_IN:'

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 7 prefix `BANDWIDTH_OUT:'

[imarks001]

It doesn't look like netbackup has binded in xinetd. Have you tried to restart xinetd? I think the related files are /etc/xinetd.d/bpjava-msvc and bpcd. Are those set to to disabled = no?