sjacobs

Still have not figured out how to get this to work for more than one backup without having to recycle the client. FWIW I see an error in the event log on the server side "Proactive polling timed out on client xxx ..." which is the client that is having this issue. When I display the client status this is what I get: Server "xxxxxxxx" Version 11.0.0.107 reserved by BACKUP for Workstation Backups back up according to normal schedule currently on readonly is off exclude is on 3 connections, 1 authenticated

I installed version 11.0.0.107 of the 64 bit client on on CentOS V7 recently. Each time I do a successful backup (using proactive from a Windows Pro V11.5 install) - the client stays reserved and the client status shows 1 connection still. This prevents the proactive backup from being able to run the next scheduled backup as the client remains "in use". The backup in each case ends normally and is successful. I can work around the problem by manually stopping and then starting the Linux client. That will allow the next backup to run to completion - but again the client will remain in use - so obviously this is not a viable workaround. I could put a cron in place to do the stop/start on a daily basis - but that seems like a total kludge and should be unnecessary. Any ideas on what might be preventing the connection from being properly closed with this client? This is my only Linux client - all other clients are Win clients - and do not exhibit this same issue. So I am sure it must be something peculiar to the Linux environment on this machine... Do I need to adjust/tune some TCP options on the Linux side perhaps?

I have just recently installed V10 and for one of my clients - it is indeed taking about 1/2 the time that it used to for roughly the same amount of data. The other client that I have backed up thus far with V10 shows also a similar amount. Both of these are remote clients - I run the the backups from a separate Windows box and use remote clients for all of the computers that I need to back up. So I am never doing any local backup. One new thing that I like a lot is the additional detail being reported in the log during the snapshot phase. Nice to be able to see a finer grained reporting on progress in that step.

Also - did you update your clients as well as server - or just server?

Yes - I certainly could do that - at this point - I have moved it over to my NAS machine - so I was able to uninstall it from this client machine and remove all of that data. Like you I already have this client ignoring files like Lightroom previews which I also have installed on this machine. If I had decided to leave Plex on this machine I would certainly have done as you described - simple enough. I am sure that had I not included all of my pics in what Plex was serving up it would not have been anywhere near the problem...thanks for the suggestion - hopefully others will benefit from this thread if they happen to have Plex installed on a Retrospect client box.

Found the answer - it turns out that it was caused by the Plex media server - but not because of any scanning activity that it was doing - but rather due to the large # of thumbnails that it created to serve up all of my digital photo albums. This created a large # of files and degraded the performance of the snapshot creation by over 4 hours. After I uninstalled Plex server and removed the (stored under AppData) data created by this app - the snapshot creation time went from 5 hrs to 27 minutes.

I just checked and the AV software already had in its settings to ignore 4 processes - RetroISA.exe, retroisarun.exe, retroclient.exe, and Retrospect Client.exe. So I would think that would cover things from an AV perspective right?

Sorry been tied up on other things - but I am still experiencing this problem. I will check into the settings of the AV software - I am using the one built into Windows 8.1. At this point I am running Retrospect Pro 9.5.2.103 on the backup machine and I am running 9.5.0 (139) client level on my Windows machine that is getting backed up. I just switched my C: drive out for a 1TB SSD - but so far no significant improvement - snapshot is taking several hours so far - still not done. Previous drive setup was a RAID 0 redundant disk array using Intel controller and 10,000 RPM WD Velociraptor drives. So don't think we are looking at a hardware issue here.

Good suggestion - when I checked for errors in the Windows event logs - I found only messages reporting that the drive was healthy: "Volume C: (\Device\HarddiskVolume4) is healthy. No action is needed." I will force a chkdsk as you suggest - but I doubt very seriously that is the problem. I would not have thought that the Plex server would be the cause of this either - it is idle most of the time on my machine - when I look at its event logs - they are pretty sparse. It does a scan of my NAS shared folder where my movies are store every so often - but I have not made any updates to even cause it to do any real work during those scans. And those scans complete in minutes. I do have a large photo collection - which I had Plex scan - so perhaps that has caused it? By large - I mean I have approximately 75,000 images that it would have scanned. I actually have over 150,000 raw files - but only 75,000 have been exported as jpegs to show on TV's etc - which I had Plex scan to be able to show them. If that is a possibility - I could try removing the photos out of the Plex library - which theoretically would cause it to remove that data that it created when it indexed them.

As a further note to the above - the D: drive does not show this problem - snapshot creation for it remains very reasonable and consistent with the times before 7/1.

I have been backing up my main Windows 8 workstation for a long time with Retrospect - and up until 7/1 - that entire backup of both the C and D drives on this machine was taking about an hour - give or take - and the snapshot creation for the C: drive was taking no more than about 30 mins or so. Since the 7/2 backup - this has started taking upwards of 7-8 hours - with the majority of the time being spent creating the snapshot for the C: drive backup. Up until yesterday I was running 8.5 - so I thought I would try upgrading to 9.0 to see if that would have any effect - and it did not. I see the same behavior under 9.0.1. The Retrospect client level is 8.1.0. That has not changed and was installed back in June of 2013. I don't believe I have made any changes in the settings for this backup script or the backup set either. So - obviously something must have changed on my machine to cause this. The only thing I can think of is that something I installed on my system on 7/1 has caused this issue. The items that were installed on 7/1 include: - update to Adobe Air - Comcast Usage Meter App (was a reinstall - this app had been on before when the backups were running fine - so I believe I can discount this one) - Plex Media Server Of the ones above - the only one that I can think would have a chance of causing this would be the Plex server. There were no Windows system updates installed - so that isn't playing into this. There have been no hardware changes on this system either. Any ideas on what might be causing this slowdown? Other things I should look at?

Yes - I understand what you are talking about - I thought I would do the scrub first. Then I will do a fsck to make sure at that level there are no issues. Thanks for the link on the error codes - will bookmark that for future reference as I always have to go on a search mission to find it on the support site.

OK - good idea - I have kicked off a "scrub" of that entire volume on the Synology - so hopefully if there is an issue it will be found and fixed with this. For whatever reason I could not find this error message number in the list of the error messages on the support site - so I wasn't sure exactly what this number meant. Certainly makes sense given your explanation. But I think someone should get this one added to the list wherever that is maintained so that others will know what it means without having to resort to posting a question.

OK - I have not exactly found a root cause - but since I had run out of anything else to try - I rebooted the Synology NAS device (having already rebooted the backup machine which did not seem to help). For whatever reason that seemed to fix it. One thing about this area vs the others that is a little different - it is an encrypted share. So perhaps there was something flaky there with the access. Still doesn't make sense why that would allow for over 50% of that area to be scanned ok before hitting that error. I should also mention that if I used Windows Explorer from that same backup machine - I had no problem causing Windows to scan the area for example in the Properties dialog to determine the total # of files and filesize. I also had no issues access this area from other machines. Very strange. BTW - I am running Retrospect Profession V8.5.0 (136) in case that may be playing into this.

I have a number of volumes defined on various shared folders on my Synology NAS device that I have scripts that run weekly and duplicate those over to some external USB drives. That had been working just fine until recently across all of them. Now - I am suddenly getting this error on only one of them. I tried rebooting the machine that is running the Retrospect Pro backup but that didn't fix anything. It does not seem to be related to the # of files - because other volumes on this same NAS can be scanned just fine with much larger #'s of files - both in number and total size to be backed up. I wish there was some way to see where exactly it is getting tripped up in its scan... Anyone have any idea what might cause this issue?