Backup fails on SYS: volume using Arcserve v9.01
Duke
I hope someone can shed some light on another very frustrating
Arcserve problem:
Current situation:
Backup host server : Windows 2000 with Brightstor Arcserve v9.01
for Windows
Backup client server: Novell Netware 6 (SP3) IP only. Arcserve Agent
for Netware v9.01
Since a few days we are no longer able to backup the SYS: volume on
the client. The second volume (VOL1:) can still be backed
up without any problems.
After about 10 minutes the backup job for SYS: times out with an error
on the host: "E8535 Failed to receive data from the client agent".
Latest TSA's are loaded on the client.
An NSS /poolverify on SYS: does not reveal any problems, neither does
dsrepair.
Also tried "smdr new", but no luck there either.
Netware client logfile:
Jan-22 15:13:10 Job request from W2RTM39 @ 10.117.195.95 (NT Server)
Jan-22 15:13:10 Comment: test nwrtm60
Jan-22 15:13:13 Connected with TSA NWRTM60.NetWare File System
Jan-22 15:13:13 LONG UNIX files will be processed using SMS Engine
Jan-22 15:13:13 Backup NWRTM60/SYS:\ to 1/22/04 3:12 PM sequence 1
session 1
Jan-22 15:13:14 Connected with TSA NWRTM60.NetWare File System
Jan-22 15:13:15 Approximately 71 file(s) 2,115 KB will be processed
Jan-22 15:13:17 Connected with TSA NWRTM60.NetWare File System
Jan-22 15:25:02 0 files 8 KB written to 1/22/04 3:12 PM @ 0 KB/min
Jan-22 15:25:02 E3149 Failed to end BrightStor ARCserve Database
session, 1
Jan-22 15:25:05 Job completed.
Any help would be appreciated!
Regards, Duke
Marcel Cox
> Backup client server: Novell Netware 6 (SP3) IP only
>
Do you have the latest TCPIP update installed on your server?
http://support.novell.com/cgi-bin/search/searchtid.cgi?/2967016.htm
Also, does the client agent have any log? If yes, does it report any
error?
--
Marcel Cox
http://support.novell.com/forums/
Duke
Yes, after the problems started (about 2 weeks ago) I installed the
tcp607k patch (null version). No improvement...
Worth mentioning is that the same host server (win2000) backs up
several other
Netware servers (all via nwagent). No problems there whatsoever.
> Also, does the client agent have any log? If yes, does it report any
> error?
The log in my previous message IS from the client agent on the problem
server.
As you can see, there is no specific message stating why things go
wrong. The TSA does connect to the file system. I even see the
scanning process during the
file estimate. It just stops dead right after the estimate finishes.
Then the backup times out after 10 minutes. It just makes no sense,
because the VOL1
backup works perfectly, it's a single backup job!
This is the log on the host server:
[01/08/2004-10:27:42 Connected with client agent at NWRTM60
(0.117.195.40 ) User = <username deleted>)
[01/08/2004-10:27:44 No estimate on backups
[01/08/2004-10:27:45 Source Directory: SYS:
[01/08/2004-10:27:45 Backup Session 1 on Media 1/08/04 10:27 AM
[01/08/2004-10:27:46 Connected with TSA NWRTM60.NetWare File System
[01/08/2004-10:27:46 Process all files via SMS
[01/08/2004-10:27:46 DOS MAC LONG UNIX files will be processed using
SMS Engine
[01/08/2004-10:27:46 Backup NWRTM60/SYS: to 1/08/04 10:27 AM sequence
1 session
[01/08/2004-10:27:47 Connected with TSA NWRTM60.NetWare File System
[01/08/2004-10:37:48 E8535 Failed to receive data from the client
agent. (ADDRESS=10.117.195.40 (NWRTM60 ( 10.117.195.40 )), EC=10060,
COMMAND=0)
[01/08/2004-10:37:48 ** Summary for NWRTM60 ( 10.117.195.40 ) **
[01/08/2004-10:37:48 0 Session(s).
[01/08/2004-10:37:48 Elapsed Time: 36065h 37m 48s
[01/08/2004-10:37:48 Average Throughput: 0 KB/min
[01/08/2004-10:37:49 Media Remaining Capacity : 100.224 MB
[01/08/2004-10:37:49 Media Compression Ratio : 4.73
[01/08/2004-10:37:49 *** Backup Summary for Job ID 243 ***
[01/08/2004-10:37:49 Device Group........................... GROUP0
[01/08/2004-10:37:49 Media Pool............................. N/A
[01/08/2004-10:37:49 Media Name............................. 1/08/04
10:27 AM
[01/08/2004-10:37:49 Media ID............................... 2BDE
[01/08/2004-10:37:49 Total number of sessions............... 0
[01/08/2004-10:37:49 Serial No [Seq 1]...................... N/A
[01/08/2004-10:37:49 Total Nodes to be backed up............ 1
[01/08/2004-10:37:49 -- Complete and Incomplete status...... 0
[01/08/2004-10:37:49 -- Failed and Canceled status.......... 1
[01/08/2004-10:37:49 Total Volumes to be backed up.......... 0
[01/08/2004-10:37:49 -- Complete and Incomplete status...... 0
[01/08/2004-10:37:49 -- Failed and Canceled status.......... 0
[01/08/2004-10:37:49 Total Directories backed up............ 0
[01/08/2004-10:37:49 Total Files backed up.................. 0
[01/08/2004-10:37:49 Missed Nodes/Volumes:
[01/08/2004-10:37:49 NWRTM60 ( 10.117.195.40 )
[01/08/2004-10:37:49 Backup Operation Failed.
I read somewhere (think it was the CA site) a recommendation about
using the encrypted IP stack when backing up through the Netware
client agent. I don't see a point in this, and haven't tried it yet.
Would it be worth giving it a try??
Thanks again for any input,
Duke
Marcel Cox
> I read somewhere (think it was the CA site) a recommendation about
> using the encrypted IP stack when backing up through the Netware
> client agent. I don't see a point in this, and haven't tried it yet.
> Would it be worth giving it a try??
That might be pure luck that for a certain version of TCPIP, the
encrypted version has lsightly different timing that causes it to
behave differently.
Generally, the different versions of TCPIP are all based on the same
source code and just conditionally compiled for different encryption
levels.
What you might try to do is disable estimate. I remember some time in
the past where estimate took too long and caused TSA connections to
timeout. Disabling estimate would avoid that issue.
--
Marcel Cox (using XanaNews 1.16.1.3)
Duke
> What you might try to do is disable estimate. I remember some time in
> the past where estimate took too long and caused TSA connections to
> timeout. Disabling estimate would avoid that issue.
Tried that already :-( As a matter of fact I always disable estimates
because I consider it a waste of time. But either way it doesn't work.
There must be an explanation why SYS: fails and VOL1: backups go fine.
Can it have anything to do with "server specific information" or even
the "_Netware" directory? These are the only differences between these
volumes.
Regards, Duke
Marcel Cox
is a winsock error indicating a connection timeout. This actually means
that the TCP connection used for the backup is somehow dropped.
I don't know if you have already done so, but if not, you might
consider applying one of the post SP3 TCPIP updates.
Duke
> is a winsock error indicating a connection timeout. This actually means
> that the TCP connection used for the backup is somehow dropped.
> I don't know if you have already done so, but if not, you might
> consider applying one of the post SP3 TCPIP updates.
I saw that the tcp607l update has just been released. I don't expect
much of it but will give it a try nonetheless.
Duke