NT Client Failure (aborted due to inactivity)

[mantab]

Hello All,

I am running NetWorker 6.1.2 on a Solaris box and I am backing up an Intel based system running Windows 2000. The partition that I am backing up contains 256 gb (D:\). The FULL backup runs just fine, however, when I then try to run an incremental, it times out with the error below. I am thinking that it is timing out scanning the file system for files that have changed to perform the incremental. Can anybody assist with explaining why this is failing? Could this be a none limitation or bug with the amount data or files?

Thanks!

Mantab

* reddog:\ 1 retry attempted
* reddog:\ 03/28/04 23:36:10 nsrexec: Attempting a kill on remote save
* reddog:\ aborted due to inactivity

 

[605]

This means that a save set has been started and has not received data for 30 minutes (the default timeout). A retry failed. This will make NetWorker think that there is something wrong and it will stop it.

Usually this is a "network related" problem, most likely due to bad name resolution.

There is no limitation, and i do not know about a bug.
You may increase the timeout value in the savegroup resource but i do not know, whether this will improve the scenario. Look at your network setup first.

 

[mantab888]

Thanks very much for the feedback. It turns out that increasing the timeout value from 30 to 60 minutes did the trick! Thanks for your response and I am all set now.

Mantab

 

[605]

Well, as i said, that may do the trick but i doubt that you have not solved the origin for that problem. I admit that this is much harder to do.

 

[mantab]

Thanks 605,

There is 256 gb of data on this particular partition, so that's why the timeout value was causing problems I think. I backup over 300 Unix/NT/Linux clients and this is the only one having problems. So, I don't think that it is network related. Thanks for your help!

Mike

 

[605]

The size itself should not matter. It may be the due to the number of files as you indicated previously.

Can you give us an idea or even better, a breakdown, how many files are involved in how many directories?

 

[mantab]

* reddog:C:\ save: C:\Documents and Settings\All Users.WINNT\Application Data\Microsoft\Network\Downloader\qmgr0.dat: cannot open (The process cannot access the file because it is being used by another process.)
* reddog:C:\ save: C:\Documents and Settings\All Users.WINNT\Application Data\Microsoft\Network\Downloader\qmgr1.dat: cannot open (The process cannot access the file because it is being used by another process.)
* reddog:C:\ save: C:\WINNT\system32\Perflib_Perfdata_478.dat: cannot open (The process cannot access the file because it is being used by another process.)
reddog: C:\ level=full, 1719 MB 00:11:46 20174 files
reddog: D:\ level=full, 265 GB 22:25:20 1721615 files
reddog: SYSTEM STATE:\ level=full, 14 MB 00:01:34 17 files
* reddog:SYSTEM DB:\ Removable Storage Database - rsmow: Exported the RSM database.
reddog: SYSTEM DB:\ level=full, 112 KB 00:01:08 8 files
reddog: SYSTEM FILES:\ level=full, 243 MB 00:02:36 1937 files
icebat.bmc.com: index:reddog level=full, 6981 MB 00:15:04 302 files

 

[ulsj]

Hi

I have seen this on both unix and NT system the time it takes for the OS to get the file list of all changed file during a inc backup is longer than the default timeout in networker.

/Ulf

 

[605]

BTW - why on Windows 2000 clients, don't you use the MS Change Journal. This should reduce the 'check for incrementals' dramatically.

 

[DavinaTreiber]

The solution of increasing the inactivity timeout is absolutely correct in this scenario. It is typical of large filesystems running incremental backups, particularly if not much data has changed since the last backup and also if there are a large number of files. It takes a while for the client to walk the filesystem, and it is quite likely that it could run for 30 minutes without finding a changed file, and this could cause a timeout. I would suggest that even 60 minutes might not be enough in some cases.

 

[605]

With your inputs i performed extensive tests over the weekend on a file system up to 4.000.000 files where i added 100 files later (before the incremental backup). I could not verify any problems (with change journal or without it). I am really concerned why you have this problem.

 

[mantab]

Hello 605,

Since changing the inactivity timeout from the 30 minute (default) to 60 minutes I haven't experienced any more problems. Here are the statistics as only 1 gb to 3 gb of data typically changes on an incremental basis:

Saturday, March 31st
reddog: D:\ level=full, 226 GB 19:48:22 1718502 files
Sunday, April 1st
reddog: D:\ level=incr, 1791 MB 01:29:10 2054 files
Monday, April 2nd
reddog: D:\ level=incr, 999 MB 01:26:21 606 files
Tuesday, April 3rd
reddog: D:\ level=incr, 2470 MB 01:33:38 2159 files
Wednesday, April 4th
reddog: D:\ level=incr, 1343 MB 01:25:54 1935 files
Thursday, April 5th
reddog: D:\ level=incr, 1697 MB 01:09:18 1680 files
Friday, April 6th
reddog: D:\ level=incr, 2322 MB 01:11:10 1899 files
Saturday, April 7th
reddog: D:\ level=full, 189 GB 18:51:19 1716703 files
Sunday, April 8th
reddog: D:\ level=incr, 3718 MB 01:22:19 573 files
Monday, April 9th
reddog: D:\ level=incr, 3930 MB 01:21:44 2017 files