This is an odd behavior and I'm not sure if I have enough information, but figured I'd post anyway.

 

I'm using Retrospect 7.6 as my backup software and have for years. Since establishing my unRAID server I have attempted to backup to it several times using Retrospect and each attempt results in the unRAID server becoming completely unresponsive after roughly 30 minutes. The attached monitor won't even display anything, so I can't grab the syslog. I did attach the one from today after the lock and rebooting.

 

My first thought was that it was HW related and was occurring after a load was on it for a while. So, I tried the built in Winblows backup to see if it behaved the same way. Well, it took longer but worked. Now, that doesn't necessarily rule out a HW issue, but is odd at best. Looking at the load and mem use on unRAID it appeard to be about the same between the two backup softwares.

 

All other operations that I have been using unRAID for like simplying copying digital media like movies and musc have all worked flawlessly.

 

I only recently stood the server up and installed three new WD 750 GB Green drives. At this point I have no reason to think there is anything wrong with them. The machine is a P4 2.8 Ghz with 1GB RAM. The machine has always ran well, so I don't know of any issues with it at this point.

 

I'm going to try a few more operations with different software just to continue to stress the machine to see if I can make it happen again, but right now it just seems to be Retrospect.

 

So, I'm just kind of fishing to see if anyone else has run across this kind of behavior.

 

Thanx,

How is Retrospect accessing shares on the server?  That is, is the target unRAID share a disk share or a user share?  Is it using Windows Networking (SMB) or NFS, or something else?  Can you make it lock up "at will"?

I  have Retrospect accessing the share via a user share (ex., \\unRAID\Backup). I'm using the default protocol of SMB. Not sure that I would say I could do it at will, but I can definitely make it happen simply by trying the backup routine. I say I can't make it happen at will simply because I can't say when it will happen during the routine, but it has happened eventually each time I have tried it.

 

Thanx,

I  have Retrospect accessing the share via a user share (ex., \\unRAID\Backup). I'm using the default protocol of SMB. Not sure that I would say I could do it at will, but I can definitely make it happen simply by trying the backup routine. I say I can't make it happen at will simply because I can't say when it will happen during the routine, but it has happened eventually each time I have tried it.

 

Thanx,

 

As a test, can you try using a direct disk share, for example, \\unRAID\disk1\Backup ?

I'm probably going to jinx myslef by saying this, but so far so good. It's been running about an hour now and that is certainly the longest it has gone yet. Is there really any difference between a user created share and the default created diskX shares? I appreciate the assistance!

 

Thanx,

 

Is there really any difference between a user created share and the default created diskX shares?

 

Apparently 

 

Which version from this page could I download to try and reproduce the problem?

 

 

Actually, you'll find the version I'm using here. The exact title of it is "Retrospect 7.6.123 for Windows Installer". I'm not sure that it will allow you to try without a key however. The funny thing is the way I got it was because I was a part of a class action suit against Western Digital several years ago and this sotware was distributed as part of the settlement. I have been using it since. Try downloading it and let me know if it will let you run it or not. Also, if you get that far, you will need to run the updater within the app and get a driver update. The app takes care of it from there.

 

Thanx,

vern- Is it possible that any of the path lengths of files you are trying to back up exceeds 260 characters in length?  For example, maybe trying to back up this source file:

 

c:\a very long directory name\another very long name\maybe another long directory name\long file name.doc

 

to this target file:

 

\\tower\Backup\a very long directory name\another very long name\maybe another long directory name\long file name.doc

 

I want to know if any of those target paths could be getting close to or exceeding 260 characters.

 

(Note: if there are any unicode directory/name components, these lengths should be doubled.  For example, if the total path/file name of a file you are backing up is say, 200 characters, but many of the components are non-english, then it's possible the total length seen by server for that path/file could exceed 260.)

I ran a powershell script against all the path lengths and the longest is 244. Not sure about the unicode directory/name components. My system is setup for english so I don't believe I have any of those animals.

 

On a side note - I let the backup run through the night after I had gone to bed and it failed. It was a different error though. So, I tried the MS Backup again and it worked fine. I'm running Win7 and they have dramatically improved the backup system, so I may just stick with it. Don't get me wrong, I'm not diminishing the effort you have already put forth and I will continue to test things if you like for me to. In fact, as we metioned earlier, if the download won't allow you to run it as a "trial", I think we can arrange for you to borrow my license so you can run the issue to ground, if you like.

 

I stand by to assist, just let me know...

 

Thanx!

Path(s) close to 244 characters is definitely a problem.  There is a bug in user share maximum paths which I found trying to figure out why long unicode paths aren't processed correctly.  The bug is that there's a path buffer declared 260 characters long instead of using the linux PATH_MAX value of 4096.  I will be releasing another beta to fix this problem.

 

But in the test you ran overnight, this was directly to a disk share, correct?  What was the "different error"?  Do you have the system log from last nights run?

Yes, I was writing to the disk1 share last night and yes, I still have the log, its attached. The error I received in Retrospect was "Can't create session, error -1100 (invalid handle)". It looks like it may have happened right when it was changing volumes. I was backing up drive D:\ and E:\. From the file count it looks like it got all the files from the D:\ drive and then choked when shifting to the E:\ drive, but the log doesn't clearly state this, I'm surmising to some degree here.

 

Thanx,

So I got my final retail version of Windows 7 Home Premium and it doesn't support backing up to a network share. So, I decided to look around for another option for backup software. I found Second Copy and it has all the features I was looking for. I cranked it up and it caused unRAID to crash hard on the first file it was trying to copy to unRAID. I tried this several times and each time unRAID crashed hard. The symptoms were very similar to what I experienced earlier in this thread regarding Retrospect. The way second copy operates by default is to copy the file with a temporary name and then rename it on the other end. I noticed by the size of the first file and just monitoring the copy that it was very near the end of the file size when it crashed, which is when it would be performing the rename operation. Second Copy provides a switch to turn this behavior off and just do a straight copy without a rename operation. It hasn't finished yet, but it is certainly running now. I bring this up as you may want to have a look at it because you can easily recreate the behavior and it may provide some clues as to what's going on with Retrospect or anything that performs similar functions.

Now that I have loaded b8 I decided to try using Retrospect again. I'm happy to report that it worked fine with no problems! That fix for the path lengths appears to have done the trick.

 

Thanx!