nickls Posted February 20, 2003 Report Share Posted February 20, 2003 Hi All, I seem to have found a new bug. I am running a Win2k server using retrospect single server, to backup PC and MAC clients. Since about a week ago, the script has been crashing retrospect, with this error message. I can find nothing in the FAQ about it... has anyone else had retrospect crash like this? Any way around it? I took a screenshot of the error, it is here http://wwwmaths.anu.edu.au/~langdale/retrodeath.jpg and the assert_log.utx which it appends is here http://wwwmaths.anu.edu.au/~langdale/assert_log.utx Please help, our institute is currently not being backed up, except for manually.. thanks nick langdale ____________________________ Mathematical Sciences Institute Australian National University Link to comment Share on other sites More sharing options...
nickls Posted February 20, 2003 Author Report Share Posted February 20, 2003 Oh and BTW, ive read the FAQ/readme, and the whole section on assertion errors, but mine is not listed anywhere... thanks nick Link to comment Share on other sites More sharing options...
Mayoff Posted February 20, 2003 Report Share Posted February 20, 2003 Actually we are aware of this error in several cases. It is being fixed in our next release. Known causes: Some duplicate type scripts can fail when they have a bogus destination Selecting an empty backup set for Disaster Recovery Some restores under specific configuations have seen this error Backup or Restore of HFS Standard data to HFS+ volume This error may happen under other conditions, but basically it should be fixed in our next release. A date is not yet available for our next release. Link to comment Share on other sites More sharing options...
today Posted February 21, 2003 Report Share Posted February 21, 2003 I have this exact same bug. I was getting similar crashes in 5.6, but it was clear to me you guys had absolutely no interest in fixing that version since you've changed revenue models. So I spent an additional $500 to upgrade to 6.0. Still not fixed! For a company who claims on their homepage that "the company's patented technologies provide the reliability and efficiency that small and midsize businesses depend on", it is not acceptable to say, "fixed in next release, no date available". That's not very dependable. Put the fix in for this bug and give those who have this problem an early release or patch. What the heck do you expect us to do for backup while I wait for your next release? (1) I'm not running a duplicate script - it is the so-called "proactive" script. (2) I'm not doing anything with disaster recovery. (3) I'm not doing a restore. (4) This is a PC, so I obviously am not backing or restoring to a HFS+ volume. What is the workaround? The only clue is that shortly before the crash, I got the following in my log. BTW, I got this in version 5.6 as well. - 2003-02-19 6:30:01 PM: Copying $[*!20612,,14,+3] (C:)$[3] on Demo$[4] 2003-02-19 6:30:01 PM: Connected to $[*!20780,,14,+3]Demo VPcFsNodeInfo::NetImport - elsize 4, sz -31,181 PcFsVolNodeScan::NetImport (node) - elsize 0, sz -31,181 $[*20750] Scanning incomplete, error -3102 (unknown) $[126901530011820000] This bug has been reported in the past on this forum (including the elem.cpp assert), but was never followed up on, apparently. http://forums.dantz.com/ubbthreads/showflat.php?Cat=&Board=multiserver&Number=20400&Forum=All_Forums&Words=vpcfsnodeinfo&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=20400&Search=true#Post20400]Big URL Link to comment Share on other sites More sharing options...
Mayoff Posted February 21, 2003 Report Share Posted February 21, 2003 I found a few notes about the -3102 error message. From the Knowledgebase: This error may be caused by a problem communicating with the Client computer on the network. If this problem is isolated to a specific client on the network, then it may be necessary to try testing a different ethernet card on the client computer. One customer had a "SMC easy ethernet card" that was causing the error. He replaced the card and the error want away. Does the error happen every time you back up "Demo"? If so then I woud look for problems in that PC's NIC card. In your case, you may want to update the ethernet drivers on "Demo" and maybe consider swapping out the ethernet card. If the assert error happens when accessing a specific client on the network, then a bad network packet could be contributing to the crash. Link to comment Share on other sites More sharing options...
askirkland Posted February 21, 2003 Report Share Posted February 21, 2003 You are not alone... I'm having the same and other similar problems. My current workaround is to manually backup my problem workstations... and remove them from my automatic backup schedules... pretty lame but at least I know when retrospect crashes and I can restart it... and it doesn't interfere with all my other clients’ backup schedules. I have 2 machines that get the -3102 NIC adapter error... same NICs... could both be bad or does Retrospect not support Dell integrated Intel Gigabit NICs? Link to comment Share on other sites More sharing options...
Mayoff Posted February 21, 2003 Report Share Posted February 21, 2003 >Dell integrated Intel Gigabit NICs? Retrospect should work with all stock Dell hardware, including the above ethernet cards. I am doing some added research here at Dantz to make sure this assert error is resolved based on the symptoms described in this thread. Link to comment Share on other sites More sharing options...
nickls Posted February 23, 2003 Author Report Share Posted February 23, 2003 Hi, Glad to see that something is being done. I narrowed the problem down to one particular client, with an "Intel 201 Based PCI Ethernet Adaptor". This client will ALWAYS fail on automatic (scripted) backup, and i have just discovered, will ALWAYS fail even on manual backup. (im looking at the elem.cpp-855 error right now). I'll see if i can change the netcard, but is this particular NIC an adaptor which is known to be troublesome? Also, if this error will "basically be fixed" in the next release, will there still be some NIC's which could be cause for concern? cheers nick Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.