Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by eppinizer

  1. Forgot to mention, when upgrading back to version 16 (if you decided to run the test I mentioned) just uninstall and reinstall v16, and restore your renamed C:\ProgramData\Retrospect folder back to it's original name replacing the temporary folder created during the install of the older version.
  2. Hi Tman, In terms of settings that effect performance in general, compression and encryption are the big ones. Also I would suggest rather than accessing the computers via SMB (correct me if I misunderstood what you meant by "I'm using an \\computer\drive "), you install the Retrospect client. At the very least test the difference to see if that is part of it. Is the performance slow when the local machine (that retrospect is installed on) is backing up and the remote machines, or just the remote machines? Was the performance consistently slow, or was it getting stuck in certain spots? Keep in mind that when backing up remotely, all data must travel from your remote destination, to the Retrospect server for processing, and then back out to the Synology. If you would like to rule out the newer version being the problem you can do so by installing an older version of Retrospect and running a backup to the same destination volume as you are currently. It would just take a bit of time to redo a test configuration, but at least you would feel confident it isn't the version difference, but something else in the environment. You can preserve your current configuration by making a copy of C:\ProgramData\Retrospect Then uninstall version 16 and re-install the version of Retrospect that you were not having problems with in the past from the archives . https://www.retrospect.com/support/archived While the older versions didn't support windows 10, you can install it and for basic file copies this test should be valid. If you don't have a license for the older version, support@retrospect.com can get you a trial. Once you have your key, Rename your current C:\ProgramData\Retrospect directory, Install the old version, enter the license key, and then setup a quick test backup. Create a new backup set, you can delete it (and the catalog) afterwards. Run the test backup and compare speeds. If the backup is much faster, take a screenshot of your settings and when you revert/upgrade back to version 16, you can doublecheck that they are the same. Before you draw any conclusions, make sure you run the same exact test backup on version 16 so that the source data during the backups remains consistent, otherwise the test isn't valuable. Good luck. -Jeff
  3. Hi All, Earlier in the forum post I mentioned we may be able to create a test build for version 12 users that contains a workaround for this issue. Unfortunately the engineering team found that porting the changes back to version 12 was a non-trivial task. They have to focus on the latest release. I would instead suggest trialing version v15.1 to see if the changes help in your environment, www.retrospect.com/try and if they do, consider upgrading to the latest version. -Jeff
  4. Hi x509, Unfortunately we don't release public patches for non-current versions. We can put together a test build for version 12 and distribute it via support webtickets. If you don't have a ticket already, please submit one. You can reference this thread/post and it will get to me. It might take a few days to generate the build, and again its more of a stopgap while we continue the investigation than it is a fix.
  5. Hi All, Just another quick update. We are still investigating these errors, most of which appear to be tied to One Drive, but it seems not necessarily always tied to One Drive. The results from the internal investigation indicates that the problem is a bug introduced by Microsoft. Just to give a simplified overview, when using VSS we aren't ever actually backing up your files, we backup Shadowcopies of your files. In the case where we run into problems, after we access the bundle of Shadowcopies that Microsoft is preparing for us (after using standard VSS calls), we encounter write access violations. So VSS prepares everything, gives us this blob of data, and then says we aren't allowed to access it. What's also strange is we aren't actually writing during the scan, we are just reading the data. We confirmed that this isn't just bad error mapping on our part, we are actually receiving write access violations. We are implementing some changes that will be a part of the next release (v15.1) which should allow the backups to continue beyond this error. This is currently scheduled for release later this week. We will continue to work with Microsoft to address the issue further, whether that means changes on our end, or a patch on their end. We really appreciate the feedback from this forum thread, as well as the all of the information submitted to us via web tickets. Thanks, -jeff
  6. Hi x509, This will depend on the results of the investigation. If it looks like something is broken we'll submit a bug report. In fact, depending on what is broken we may have to submit a bug report in order to get it fixed. Cheers, -Jeff
  7. Hi All, Thanks so much for all of your input. We have reproduced the issue in house, we are investigating an appropriate fix, indeed it does appear to be due to a change in Microsoft's One Drive. I'll keep you all updated on our progress. -Jeff
  8. Hi Scillonian, thanks for asking. Within Retrospect i'm seeing our generic -3050 error Can't use Open File Backup option for Local Disk (C:), error -3050 (VSS reported an error) So not much of use there, since the -3050 error can cover so many issues. In terms of actual VSS errors (events) I'm seeing both Event ID 22, VSS, level: Error. Details: Volume Shadow Copy Service error: A critical component required by the Volume Shadow Copy service is not registered. This might happened if an error occurred during Windows setup or during installation of a Shadow Copy provider. The error returned from CoCreateInstance on class with CLSID {e579ab5f-1cc4-44b4-bed9-de0991ff0623} and Name IVssCoordinatorEx2 is [0x80040154, Class not registered Event ID 8193, VSS, level: Error. Details: Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr = 0x80040154, Class not registered. No errors reported by "vssadmin list writers", everything is in a reportedly stable state. I haven't gone too deep yet, but the suggested fixes I found in my preliminary searches based off of these errors haven't helped. I'll take a crack at it tomorrow. Thanks.
  9. Hi Scillonian, You mentioned earlier that in your testing "some security settings related to Windows services are not being carried forward correctly." Can you elaborate on this? Any security settings in particular that you are noticing? I realize others are seeing the problem with a fresh install, but it still might point us into the right direction since at the moment none of our machines are producing the error. On another note, I updated my personal machine up to build 1803 and instead of encountering the -1103 error, I'm seeing an entirely different VSS error. Yay Microsoft!
  10. Hofstede, Can you elaborate on these partitions that you removed? Were they all partitions on the disk that your System C: volume resided on? If partition scheme has something to do with the error it would go a long way to help us reproduce the issue.
  11. Hi All, Thought I would chime in here since there seems to be a good amount of info going back and forth. First, if you haven't yet, anyone who is seeing this issue please create a support ticket (https://www.retrospect.com/en/support/contact) with the following information: -CPU model -32/64bit OS? -Whether or not your system is a UEFI based system. -Whether or not your system has a "system reserved" partition or not -Whether or not your system is a VM -Which Antivirus is in use, if any -If you try installing the Retrospect application itself (instead of the client) do you encounter the same 1103 error during scan? -Please send us a screenshot of your Disk Management window. We have a few Win 10 systems in our test environment, we've updated them all to build 1803 and haven't encountered the issue. This tells us there are some prerequisites that need to be met in order to encounter the problem. Understanding the similarities between the systems that are seeing it versus the ones that aren't should help us reproduce the issue. hevanw, I see you have a case opened. This is pretty important information, thanks for reporting it. Could you please respond to the case with the requested information above? Mbennett, While I can't guarantee you won't see the error again, the 1103 error that you were seeing was occurring when saving the catalog, which is quite a bit different than when the error is encountered during a scan. One is a permissions error when when writing to a disk, the other appears to be an error accessing VSS for our scan. So unless you are seeing the scanning error immediately following the update to 1803, you should be all set. Lucky_Phil, This is interesting. Do you have instant scan enabled? The only difference that I can think of between a scheduled versus a manual backup would be that Instant scan is not used during a manual "immediate" backup/duplicate. I guess its possible that the options could be different as well. What about if you just head to the Run menu and select your script, then kick it off from there? You've gotta love Windows updates... Thanks all, -Jeff
  12. Hello, I've spent a bit of time this morning attempting to reproduce this issue but I've been unable. I created a rule to only backup files last modified before 5/12/2016, and when I check the preview none of my recently modified files are selected, and all of the older files are. I found this to be true with both Backup and Copy assistants. Is it possible that you are selecting the rule, and clicking "browse" rather than clicking all the way through the assistant until the final screen (Copy Summary) and then clicking the "Preview..." button found on the bottom right of the window?
  13. Hi Lennart, From this information I have a feeling that the issue was a conflict between the client and the 9x engine running at the same time. We noticed an increase in the amount of problems caused by running both engine and client on the same machine right around when we released version 12. It wouldn't be to surprising if having an even older version of the engine could occasionally cause unusual behavior such as this. The crash was clearly related to enumerating your NIC list, and there having engine+client installed will have an effect in this area. Keep an eye on the client moving forward and let us know if you continue to see the behavior.
  14. Hi Lennart, Is it just this one client that you notice the behavior with? Have you noticed any recent errors or interrupted backups of the client? It looks like we crashed when we attempted to enumerate your network interfaces.. Do you have any Proxy/VPNs that you use infrequently? Any interesting network configuration, or virtual interfaces? If you check your retroclient logs in /var/log, are there any interesting entries around the time of the crash? (2016-06-08 21:41:26)
  15. Your active backups depend on your current grooming settings. If you have grooming disabled then your active backups will be the most recent backup of each source. If you have grooming enabled, we will keep the number of snapshots (backups) in the catalog necessary to carry out your grooming policy. For example, if you have "Groom to keep this number of backups" set to 3, we will keep 3 copies of your recent backups in your catalog, and consider them active. While I admit this is a bit confusing, and I actually had to test the behavior to be certain, the user's guide is indeed correct. Copy backup scripts will only copy active backups, meaning that with this drop-down option selected, we will copy all of your active backups. I'll preemptively agree with you that this is misleading, and have already logged a bug to correct the wording here.
  16. Funny, I was just going to make a similar post. Glad we got this resolved for you.
  17. Hi nstoll, I'm sorry to see that you are experiencing these issues. Can you please provide a bit more information? Which version of Retrospect/Retrospect Client are you using? Which Win7 service pack? You mention that it works properly on a few machines, but not others. Are the machines that are waking up properly running Windows 7? Are they on the same network as the machines that are not waking properly? Are these proactive backups? Thanks, -jeff
  18. Hi ggirao, Can you be a bit more specific about the restore you performed? I would suggest installing a fresh installation of windows 7 onto the new disk you want to restore to, boot from that disk, install the client and then execute a live restore with the new disk's system as the destination. I imagine the source of your problem is the system reserved partition that is not being restored properly through the live restore. If you install a fresh copy of windows 7 before restoring the system reserved disk should already be created by the windows installer.
  19. Hah! That's what I was hoping for too. Unfortunately there are also several hyperlinks, tech documents, .chm files, and sneaky graphics that we need to manually find. However we have made some good headway already.
  20. ( I can safely say that we are still interested in user feedback. © Due to the "speed bump" we experienced last week, there has indeed been a bit of a delay on beta release. However, as stated by Robin here http://forums.dantz.com/showpost.php?post/138727/ we are hoping to release it very soon. Also, on the topic of the thread, expect to see some much better client performance.
  21. I have to give my thanks as well, this is quite a helpful tool. Thanks, -Jeff
  22. Thanks bfish, I have tried to recreate your issue, but so far I have been unsuccessful. I have upgraded from 7.6 express to 7.7.208x64, performed backups with both versions with no unexpected problems. Was your Vista operating system also 64bit? Or, are you using the same backup set created with 32bit 7.6 express with 64bit 7.7? drmpf123, Your first problem may be related to the issue bfish and JTB1965 are having. I am working on trying to find some reproducible steps to simulate the issue. Your second issue... I am under the assumption that you are talking about the Emergency Recovery disk. If you are trying to restore a backup of windows 7 that was generated with 7.6, you will not be able to perform a emergency recovery system restore. Retrospect 7.6 did not include windows 7 compatibility. The backup data must be generated with 7.7 for successful emergency recovery restore, or else it will lack necessary partitioning information used during the emergency recovery restoration process. This only holds true for emergency recovery restores of Windows 7 and Windows Server 2008-R2, normal restores should be OK. However, if you install a windows 7 "dummy" and perform a live restore much like you would with 7.6, the backup should complete successfully. After backing up with 7.7, you shouldn't have this problem.
  23. Hello bfish, Thanks for the response. I will definitely attempt to reproduce the issue. Just out of curiosity, does this issue occur when backing up to a different drive, or only the IOMEGA? Thanks again -Jeff
  24. Hello bfish, How far into the backup does the hang occur? Are there any asserts or errors in the log? How severe is is the "hang"? Do your mouse and keyboard freeze, or does everything just become unresponsive to clicks? Finally, what version of win7x64 are you using(i.e Ultimate,Professional,Home)? Thanks, -Jeff
  25. Hi Pete, Developers have suggested that this issue could be caused by using dynamic disks as a backup destination. If you are using a RAID, you ought to attempt a backup to a different destination as a test. The ASR failure will only affect a Disaster recovery disk restoration. Live restores should work just fine. JEtkins Your issue seems different, and from the log you posted it looks like there are a number of writer services that retrospect doesn't have permission to use. Your errors would cause restoration problems, but since you are also able to backup successfully on other occasions, the backup set should contain the data needed for a successful restore. I would still suggest that you might look into anti viruses to see if that’s what is creating these permission conflicts.
  • Create New...