Ramon88

What interface does your library use? SAS or LVD SCSI? And which tape format, LTO-2, 3 or 4? Not all possible combinations seem to be supported. See: http://www.retrospect.com/supportupdates/technical/retrospect/search/?q=124T

You need to re-add the client to the pool in Retrospect. A cloned disk/system is not 100% the same as the original and Retrospect 'sees' this as different. So just 'forget' the client and re-add as if it were new in Retrospect.

Robin, in that case, shouldn't this be corrected?

Maybe this post can help you?

Luc, As for item 2 (MD5), you might help Robin most when pasting the errors from the log. Item 3... well, it might be the NAS (even if it's Iomega/EMC) isn't 100% compatible with SMB. Retrospect seems to be very picky about this. Did this work correctly with 7.6.123? Item 4, as a workaround, use message rules in your e-mail client. I agree with what you want, but as it is I rather have too much info instead of too little. Personally I rather have EMC engineers work on other things.

If you stop the SQL services this shouldn't be a problem. It's just most people using MS SQL (professionally) have to run it 24/7. Stopping the services just isn't an option. But if that's not your usage profile you can use that as an advantage.

Can you test the same backup bypassing the need for your tape device. For example do a test backup to a Disk based backup set. This way you can see if the problem is related to your tape drive. Did you also try a brand new tape?

*L* Robin Mayoff IS Senior Manager Technical Support at EMC. :teeth: ...But you could also just have referred to Robin's post above knowing this is the case... If not, it would be quite funny.

You can have MS SQL create a backup scheme itself and backup those files with Retrospect.

Another forum user seems to have the same problem...

It depends a bit. Some defrag tools can dig deep into the system and it's not always known if they are 100% reliable in every working condition. Grooming in the past didn't always work when they introduced it. But nowadays I find it very reliable (7.6.123). I can't really imagine not having it anymore! However, to remove disk defragmentation from the equation, would it be a real problem to remove that software from your setup? It's a real nasty problem to troubleshoot...

Hmm, nasty... I presume, by your remark, you have some disk defrag tool running? It might be the culprit. Can't you switch it off and try again? Maybe start with a new backup set? For Retrospect storage I personally think defragmentation is not really needed.

No' date=' I don't believe that this is the way it works. Retrospect server never logs in to the client or the client's volumes. Instead, the client runs with elevated privileges on the client computer so that it can access everything, and chats back and forth with Retrospect server over the Retrospect port 497 channel to do the backup, restores, etc. The credentials you supply when setting up the client are used to establish the channel between the client and the server (so that spoofing attacks can't happen).[/quote'] Actually I didn't mean it to sound like Retrospect logs into a Windows user account. I should have said Retrospect logs into the Retro Client using the credentials you provide when setting up the Retro Client. In other words, what I was trying to suggest is that Windows credentials of the server are of no consequence for the Windows credentials of the client. As long as Retrospect (server) can log into the Retro Client with those specific Retrospect credentials it should work. If it doesn't, you could conclude there might be a problem with the Windows credentials the Retro Client is running under.

Actually we run Retrospect (7.6.123) as its own user (called "Retrospect" and this is part of the Admins group) on a 2008 R2 server. So far this works well for us. I don't think there is any user ID relation between the client and the server part of Retrospect that should mess things up. Retrospect (server) logs in with the credentials you provide when setting up the client. So if there is a credential problem, the best place to look at is the client itself imho. Just a thought... Is it possible to disable the Open File license and test again? Just to see if it is related to the problem.

I'll wait a couple of days to see if other problems surface. After that we probably will try to upgrade one of our less essential systems and give it a spin. I really hope those -519 errors with Windows 7 clients are a thing of the past.

Seriously, do you mean backup scheduling is broken too?

I understand what you say Robin, however this is not our situation. We still work with 7.6.123 because so far we are convinced that version is more stable compared to the 7.7 release version and maybe even 7.7.208. The only real problem we have is when backing up Windows 7 clients. This we need to see resolved but we really do not want new problems introduced. That is the situation we, and I think a lot of others, are contemplating.

There are now two users with the Open File backup option that have that "locked range conflict" problem... One uses Multi Server, the other Professional. Might be a bug...

Somebody in the Professional section has the same problem... What you two have in common is the Open File backup option. But it's not determined yet if this is the culprit.

I presume you tested with the 7.7.208 update? Same errors? What can you tell us about the part not concerning Exchange? In other words, how does the basic program work for you?

Could it be the Retro Client is running under the wrong credentials for the file/folder you try to backup? It kind of looks like there are two problems now, as you get two different error messages.

Robin, is there some list of known issues you guys are working on? This would help to make a sound judgement on if we need to upgrade at this time or not yet.

Not me... we're in the same boat as you.

Ahwell, I reread the first post and finally saw "open file backup"... I think I need some more coffee still... So quiting Outlook didn't help... Did you try logging out? Even better, restart the client and do not log in. Try the backup again and see if that helps. Not meant as a fix, but as a workaround.

Uhmmm... I didn't have my coffee yet but isn't this an obvious problem? :yawn: You always get a locked range conflict when Outlook is running. Log out the user of the client and try the backup then. It shouldn't generate a locked range conflict then. This is due to the fact the pst is in use (an open file if you will) when Outlook is running and Retrospect can't backup an open file (without a special add-on). So it isn't an unexpected problem and if you have logged out the user you are trying to backup, the problem shouldn't happen.