Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Backups Aborting due to inactivity

Status
Not open for further replies.

sgoldie2

Technical User
Nov 6, 2003
10
US
Hi all,

I've recently been getting the following errors when trying to complete a full backup of the following savesets:


--- Unsuccessful Save Sets ---

* ddtwo:M:\ 1 retry attempted
* ddtwo:M:\ 09/11/05 20:44:01 nsrexec: Attempting a kill on remote save
* ddtwo:M:\ aborted due to inactivity

* rrtwo:O:\ 1 retry attempted
* rrtwo:O:\ 09/11/05 20:44:03 nsrexec: Attempting a kill on remote save
* rrtwo:O:\ aborted due to inactivity

* ukntap04:N:\ 1 retry attempted
* ukntap04:N:\ 09/11/05 20:44:03 nsrexec: Attempting a kill on remote save
* ukntap04:N:\ aborted due to inactivity


I can manage to get an incremental backup, but each time I run a full, I get the output above.
For info,Neworker 7.1, Solaris 8.

Thanks for any help anyone can offer.

 
Inactivity timeouts are generally due to
- busy networks and/or
- bad name resolution (just takes to long)
- busy clients

Increasing the client retries MAY overcome this specific problem but it will not really solve it.


If you have never succeedeed in running a full, then NW will override the schedule as it can not refer to a full and start with this level. This is obvious.
 
Thanks for your prompt reply.

I run a full backup of those savesets once a week, and incrementals in between. The fulls where working and nothing has changed, it's only stopped working in the past two weeks. There has been no changes to the network or legato therefore I don't think changing the time out would make much difference. I just can't understand why this would suddenly start with nothing else changing.
 
I agree with 605, the problem most likely network related. I would take a look at the duplex setting of the network cards on the affected clients. Make sure thier speed is set to full duplex and not auto sence/auto detection. Check the ports in any switches too, and make sure they are set to a fixed speed. Also, are you backing up the affected clients through a firewall? If so, check the timeout in the firewall, this is a very common cause for backup problems.

Cheers!
Maverick
 
Thanks.

I've increased the client retries and have set the backup to a full for tonight. The backups are not through a firewall, but I'll have a look at the duplex settings also.
 
Also ...

If there are shed loads of files, eg. log files in a filesystem this can cause issues as legato has to "walk" the fs before it actually does anything, 1000 's of files will cause similar issues.

My first guess, though, as the guys above would be network related.

You could try a FTP between the two boxes, say a 20MB file and see how long it takes.

Martin
 
sgoldie2

If you are running Solaris try this command:

#netstat -I ethx (or the nic card used for the backup). See the there packet being dropped.

I would also test connectivity using the following commands:

If you are using DNS for name resolution
#nslookup nwserver
#nslookup ipnwserver
#nslookup nwclient
#nslookup ipnwclient

If you are using hosts files, check them first.
Make sure that all aliases that are under the NWAdmin/Client are also stated in the hosts file of both the client and the NW server.
Use ping to test connectivity.

Hope this helps.

Regards

LegatoTech
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top