Networker

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

2005-06-09 19:57:59
Subject: Re: [Networker] Problem recovering SQL data across a firewall
From: jee <jee AT ERESMAS DOT NET>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 10 Jun 2005 00:45:13 +0100
 Your problem has to do with the firewall and the "session timeout".

 The keepalive setting is for the "connection timeout". The default for the 
session timeout is usually 2 hours (aka 7200000 milliseconds). This is a 
classic default for Check Point, etc.
 But you cannot change the firewall settings (I reckon)

 I know that the solaris tweak is to modify the parameter (at the OS level)
tcp_keepalive_time to something (obviously) greater  than
 the default 2h ( ==  7200000 milliseconds )
 You use ndd in solaris. I don't have a clue of the command  in windows. I am 
not a windows person.

hint: do a search in google with
 +session +timeout +firewall +7200 +windows -linux




On Friday 03 June 2005 4:10, Stanley Horwitz wrote:
> 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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=