Networker

Re: [Networker] Problem recovering SQL data across a firewall

2005-06-03 13:16:09
Subject: Re: [Networker] Problem recovering SQL data across a firewall
From: Teresa Biehler <tpbsys AT RIT DOT EDU>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 3 Jun 2005 13:15:31 -0400
This sounds a lot like a timeout issue.  We've seen this in backups, but
not (yet) in recovers.  The backup will run for about 2 hours and then
fail.  So, for smaller backups, there is no problem, but larger backups
fail.  

Are there any connection timeout settings on your firewall?

-Teresa



-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of Stanley Horwitz
Sent: Friday, June 03, 2005 11:11 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Problem recovering SQL data across a firewall

We've run into an issue recovering  alarge (around 27GB) MS SQL database
across a firewall between a Windows 2003 box in production behind a
Check-Point firewall and a Windows 2000 server that we use just for test
purposes. Our Legato server is Power Edition on a Sun Solaris 9 box with
a Sony PetaSite and S-AIT tape drives connected to our v480 server via
fibre channel. All of our network equipment comes from Nortel.

I have a call open with Legato on this issue. As far as I know, our  
network
administrators have a call open with Nortel on this issue. So far,  
nothing more
than head scratching has taken place since we first discovered this  
issue a
few weeks ago.

When a colleague of mine tries to do a test recover of a 27GB SQL DB  
across
our firewall, the recover proceeds for a couple of hours. During this  
time, I believe
the SQL module is building the tables and other infrastructure to  
house the
recovered data on the target server. After that phase of the recover  
is done,
it just dies with a connection error in the target client's daemon  
log and in the
NetWorker server's daemon.log. We see no other errors.

When the same equipment is used to recover a large set of non-SQL files
across the same firewall, the recover succeeds. When my colleague  
attempts
to recover small SQL databases in the same conditions, those recovers  
also
succeed. The kicker is that when we can recover the same large SQL  
database
if we do the recover to a target server that resides in the same  
subnet where our
NetWorker sever resides.

If anyone has any thoughts on where we should look to resolve this  
issue, or
where our network administrators should look, I would be grateful to  
hear from
you. Fortunately, we are doing this only for DR testing purposes, but  
we do need
to get this to work in case a real DR takes place.

--
Note: To sign off this list, send a "signoff networker" command via
email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=