NBU 7 and SQL backups
We have been backing up our SQL boxes through a backup file, but we now would like to start migrating them to direct DB backup to same the SAN space. We are running into a problem when running the job. Here are the particulars
Master server: OS- 2003 Enterprise Server, NBU 7.0.1
Media server: OS - same, NBU7.0.1
Client: Windows 2008 Server x64, NBU 7, SQL 2008
Now, as I said, we have been doing a file backup on this client. The client is in our DMZ. The regular ports are open (13724, 13782, 1556 etc) but we are getting a connection error when look at the dbclient log file. I have included at least part of the file, what the admin sent me anyway. We looked the error up and something was mentioned about having to open port 13720 as well. Is this correct?
Comments
SAN
R U backing up through the SAN?
those ports R opened to the ethernet isn't it?
If U go to the console, Netbackup Management, Host Properties, Clients,
if You click the hosts, is that OK? Can Netbackup connect into the hosts?
Claudio Veronezi Mendes
EMC TA - Pre Sales at Compwire
Londrina - Pr - Brazil
I don't know if
I don't know if the problem is the Firewall but
https://www-secure.symantec.com/connect/articles/s...
I hope it works.
Claudio Veronezi Mendes
EMC TA - Pre Sales at Compwire
Londrina - Pr - Brazil
Connection to bprd on master
Connection to bprd on master is made via vnetd (13724). No need to open 13720.
See port usage guide (still valid for version 7): http://www.symantec.com/docs/TECH46070
p. 14:
Client --- vnetd/13724 ---> master server
- Makes backup, restore, and miscellaneous
requests to bprd.
Ensure you have bprd log on master server. Run 'bpclntcmd -pn' on client.
Check bprd log on master if request is received from client and resolved to correct hostname.
Also verify telnet from client to vnetd on master.
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows.
Handy NBU links
I was hoping to get a reply
I was hoping to get a reply from you Marianne. This is the weird thing, we have been backing this server for a while now. I can connect via host properties, I can back it up and I can telnet from master to client. I can't telnet from client to master via 13724 or 13782 and bpclntcmd -pn won't find the master. How can this be possible?
smwoodcrafts
Involve firewall admins...
Are connections initiated by the client allowed by the firewall rules?
We have often seen similar problems at some of our customers. We have in each instance asked the firewall admins to monitor comms between the client and the master. In each instance it boiled down to filrewall rules or NAT'ing taking place. The firewall admins ended up solving each of these problems.
Please do the following test on master:
bpclntcmd -hn <client>
On client:
bpclntcmd -self
If different IP's are displayed, it means that NAT'ing is done. When the client initiates the comms, it will use it's actual IP address (not the NAT'ed IP that the master knows). The firewall admins need to tell you if this IP address is passed through as-is or NAT'ed to something else.
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows.
Handy NBU links
Ok there's something very
Ok there's something very important that I left out. This, as well as most of our SQL servers is clustered. We backup the clustered name and use the SQL cluster IP. When we ask the network team to open ports on the firewall, we only open them for hte SQL cluster IP, not the physical names (IPs) of the clusterd servers. When we connect, we connect through the clustered IP. If something is initiated from the client would it use the physical Name/IP?
I ran bpclntcmd as requested. Here are the results:
Master server: (Cluster name) (SQL Cluster IP)
Client: returned (physical name) and listed IP addresses, (Physical IP), (SQL Cluster IP) and (Windows Cluster IP)
Now, looking at this, my guess is, as I asked above, when we backup something up, the request comes from our backup server over the SQL Cluster IP, so the connection is established. If something is initiated through the client, it appears to go through the physical IP which is still blocked on the firewall.
Would that be correct? If so, I'll have to get that IP opened as well.
Any thoughts?
If you add SQLHOST
If you add SQLHOST <virtual-name> to the backup script, it should use the cluster IP for the outgoing connection.
Sample script in NBU for SQL manual:
OPERATION BACKUP
DATABASE "ACCOUNTING"
SQLHOST "VIRTSQL"
NBSERVER "THOR"
BROWSECLIENT "VIRTSQL"
MAXTRANSFERSIZE 0
BLOCKSIZE 7
ENDOPER TRUE
Increase client's logging level (3 should be fine). IP address used for outgoing connection should be listed in dbclient log.
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows.
Handy NBU links
As I saw the text file and found..........
Hi,
As I was looking to the text files..and I guess the client have the version 7.0
There is some connection related issue....
Try to update the client to 7.0.1 as your master server is 7.0.1.
May solve your problem, as most of the connection issue comes from miss-match of version.
Thanks.
Remember, Kowledge & Wisdom always makes a person success.
Mrinal Sarkar
Howrah, India
Can you check the dbclient
Can you check the dbclient log file once again and get us lines startnig with <16>,<32>,<8>
Thanks, Karthikeyan Sundaram.
Check with this script......
Check with this script....... i have done backup using this script
##Sample script
OPERATION BACKUP
DATABASE $ALL
SQLHOST "dlptestserver"
NBSERVER "pc3"
MAXTRANSFERSIZE 6
BLOCKSIZE 7
ENDOPER TRUE
Thanks for the suggestions.
Thanks for the suggestions. This has been put on hold because of the holidays. I can't move forward until the firewall people are on vacation. I will go through the log file and post the lines asked about.
sneeky
good Will backing-up
Would you like to reply?
Login or Register to post your comment.