Jump to content

haggis999

Members
  • Posts

    203
  • Joined

  • Last visited

Everything posted by haggis999

  1. No, I didn't realise that was necessary. However, I have now restarted the computer and set up a one-off backup job to run in a couple of minutes. While watching Task Manager, I could see the Retrospect process starting at the specified time, but after waiting for longer than this job was expected to take, I had still received no automated email message to confirm its status. I then launched Retrospect manually, which had the effect of triggering the start of the one-off job I had created. In other words, the only automated action had been to start the Retrospect process. My scheduled job had been ignored. We seem to be making a degree of progress, but the final goal has not yet been achieved
  2. I removed retrospect.exe from my Start-Up folder and then changed my Retrospect preferences to select "Always run Retrospect as the specified user", using my normal Windows login credentials. I also stopped the Retrospect process that was currently listed on Task Manager (as a result of my previous Start-Up setting). Unfortunately, it has not fixed the problem. My next automated backup script was due to start 10 mins ago, but nothing happened. The fact that this overdue backup commenced as soon as I started Retrospect manually proves that the Launcher service never worked. I don't think it even tried to work, as no error message has been logged.
  3. My preferences are also set to 'Run Retrospect as the logged-in user'. I don't think I had a shortcut in the Startup folder back when the Launcher service used to work. It was only added as a result of a suggestion from David Hertzberg, one of the resident gurus on this forum, though I'm struggling to find the thread where that got mentioned (I think it was in April 2018). I first raised this topic via the following thread in October 2017, http://forums.retrospect.com/topic/154427-error-1017-insufficient-permissions/, but it never generated a solution. On re-reading that old thread, I see that the problem actually first arose under Windows 10. It always worked under Windows 7.
  4. If I remember correctly, I was still using Windows 7 when the autolaunch facility of Retrospect stopped working. It was certainly quite a long time ago. I'm now on Windows 10, and running a later version of Retrospect, but nothing has changed. To get around the problem, I have been manually starting Retrospect 12.6.1 every morning. When I mentioned this in a thread on another topic earlier this year, I was advised to leave Retrospect running all the time I am using my PC. It's possible that such a shortcut was always there, but I can now confirm that my Startup folder contains a shortcut to Retrospect.exe. Sadly, this has made no difference. The first automated script of the day still generates the following email notification. From Retrospect: Script "MyPicsDuplicateToNAS" failed during automatic execution, error -1017 (insufficient permissions). Please launch Retrospect and check the log for details. The log simply repeats the same information. If Retrospect is already running in the foreground at the time this script is activated, the script runs to completion without any errors. I've no idea why there should be a permissions issue in one situation but not the other. That's not the only irritation. When I view the Dashboard after getting that error message, I am told that "Retrospect is currently running in the background. Click Launch Retrospect to stop any running executions and launch Retrospect", but clicking Launch Retrospect has no effect other than to display the message "Waiting for Retrospect to exit". The only way I can get the full version of Retrospect to run is to kill the first of two Retrospect processes listed in Windows Task Manager. It's all a bit of a mess . Any guidance would be much appreciated.
  5. Tech support told me that the bug remained unsolved as they had never previously been able to replicate it. However, it looks like they are planning to make another attempt.
  6. Retrospect tech support has now added the details of my problem to the following open bug. They didn't say how long it had been open, but I was told that they plan to run some tests using a Synology NAS. At present, they seem to think that the problem might be limited to the use of Synology devices, though your experience with Buffalo LinkStations suggests otherwise. Bug 5994 - Retrospect incorrectly matching unchanged files as changed when copying from NAS.
  7. Despite my lack of a support contract, Retrospect tech support acknowledged my bug report and requested a copy of my Operations_log.utx file. Time will tell if it generates any useful feedback or a software update.
  8. Thanks, David. I have now submitted a Support Case. However, I am not optimistic about a solution. Before finalising this support case, I made another check of the Retrospect Knowledge Base and found the following entry. It looks like this duplication bug has been present for over 6 years! ---------------------------------------------------------- Issues duplicating to NAS devices Resources One solution is to use the Backup option in Retrospect instead of Duplicate: When Retrospect performs a Backup the files are kept in a special way that only Retrospect can read and that way the files stay identical to the source even on the NAS device solving the issue of recopy files that all ready in the destination. Last Update: February 13, 2012
  9. Thanks for that clear and concise explanation. I ran my other duplication script from scratch overnight. That was another four and a half hours of spinning the disks on my PC and on my primary NAS. In total, it has taken 13 hours to keep Retrospect happy by regenerating existing files on my NAS. I'd rather not have to repeat this exercise the next time I make a significant change to my NAS, so later today I plan to find a way of reporting this bug to Retrospect. The process for doing this is not obvious on their website, so my first attempt will be to use their support contact page, but I don't know if this will work in the absence of any support contract.
  10. Thanks for taking the time to run that test. It's useful to know that I am not the only one struggling to make Retrospect accept a destination change for a duplication script. Having to delete and recopy all files on the destination for a duplication script, or having to rebuild the catalogues for a backup script just because the destination has changed is really not acceptable. To my eyes, this behaviour is a software bug that deserves to be squashed. Perhaps it is the change of UUID, as you speculated earlier, but if that is the issue then Retrospect should simply provide a way to accept such a change. My primary reason for backing up digital images using a duplication script instead of a backup script is that I have no need to retain different versions of each image and I want to retain the original file format. I checked my other batch of images this morning, before going out for the day, and it did indeed suffer from the same issues as before. That will be another few hours I have to spend wearing out my disk drives for no good reason. Just out of interest, what does the option of an archive script bring to the party? The User Guide does not make it very clear how this differs from a duplication script.
  11. I went ahead and regenerated my duplication script for these digital images. The copies have now been completed and it has made a start on comparing the copies with the originals. It looks like the total job will take well over 8 hours. I'd forgotten how long this could take! There is another batch of images that were backed up via another Retrospect duplication script. I haven't tested that one yet, but I hope it doesn't suffer the same issues as the first, as I'd prefer to avoid all this wear and tear on my hard disks.
  12. The only user account I have ever created on my NAS boxes is the admin account, so I don't think that my problem can be associated with Owner or Group settings. I am guessing that this also means that there cannot be an issue with file permissions. Is that correct? However, I am getting close to giving up on trying to cure this problem. It may be easier to just let the duplication script recreate the backup copy from scratch using the Replace Entire Volume setting (which I now realise is the setting that best fits my needs, and which was the setting I must have used in the past).
  13. There was no direct replacement for the Backup and Replication package. Several other Synology solutions exist for replicating files in their native format, which I have been checking out over the past couple of weeks. My chosen option is called Shared Folder Sync. Once upon a time, I looked after a Unix server for a few months and ran a variety of tasks via the command line. However, that was over 20 years ago and I have little memory of the details. I can't remember ever using SSH, but I'm willing to give it a go.
  14. Correction. I have just found out how to display Owner and Group on the NAS. Everything seems to have Owner = admin and Group = users. On my PC, Windows File Explorer shows my image files with Owner = Dell_T7500/David, while Group is blank. As far as I am aware, these differences between the PC and NAS have always been present.
  15. The writers of the User Guide could do a much better job of explaining those duplication options. A check on my earlier copies of the User Guide show that the wording has remained unchanged since version 8. I don't recognise the term Owner:Group and have failed to see anything with a similar name in the properties of files stored on my Synology kit. The files were copied on a daily basis from the primary NAS to the backup NAS using an old Synology package called Backup and Replication. This is no longer provided by Synology, but my installation continued to work until the primary NAS crashed earlier this month.
  16. On checking the User Guide, I see that the duplication options are defined as follows. Replace Entire Volume replaces the entire contents of the destination volume with the selected files and folders from the source volume. Identical files already present on the destination are not duplicated. Replace Corresponding Files copies the selected files and folders to the destination volume. When Retrospect finds a file that exists on both the source and destination, the destination file is always overwritten. Retrospect leaves files untouched if they are identical to files marked for duplication or if the file names and locations do not match those marked. Replace if Source is Newer copies the selected files and folders to the destination volume. When Retrospect finds a file that exists on both the source and destination, the destination file is overwritten only if the source file is newer. Retrospect leaves files untouched if they are identical to files marked for duplication or if the file names and locations do not match those marked. Duplicate Missing Files Only, copies only the selected files and folders that don’t already exist on the destination volume. Other files and folders on the destination are left untouched. I still find the wording of Replace Entire Volume rather contradictory.
  17. I don't quite follow what you are saying there. How can "unchanged files are skipped" coexist with "replace entire volume"? I used one of the methods available on Synology NAS devices. First, I opened up File Station on the destination NAS (this is the Synology equivalent of Windows File Explorer). Within File Station, I mounted a remote folder, which gave me a view of the files I wished to copy from the source NAS. I was then able to run a simple copy operation to a local folder on the destination NAS. Around 3 hours later, all my digital images had been restored to my rebuilt NAS.
  18. Unfortunately, when I returned to using the Replace if Source is Newer setting for my duplication script, it still wants to delete lots of existing files from the destination. All the deleted files checked so far have later time stamps than the source versions. What might be going on here?
  19. The job has now completed without any errors. The log is shown below. As mentioned in my last post, it seems to have copied both batches of previously deleted files, despite me having reinstated the first batch of around 153GB. It also suggests that something different was done with the second batch of 9.7GB, which was not manually reinstated. However, I don't quite understand why it would copy files that then failed the comparison test, so maybe my interpretation is not quite correct. I now plan to try again with the Replace if Source is Newer setting, just to see if it still wants to delete any of the files. + Duplicate using MyPicsDuplicateToNAS at 22/03/2018 16:05 To volume My Pictures - DUPLICATE NAS1 on Photos on Bonzonas... - 22/03/2018 16:05:01: Copying My Pictures on MyData1 (G:) 22/03/2018 16:13:34: Copying: 52,950 files (165.6 GB) and 0 hard links 22/03/2018 17:18:23: Creating folders 22/03/2018 17:18:26: Finished creating 19,437 folders 22/03/2018 17:18:26: Comparing My Pictures - DUPLICATE NAS1 on Photos on Bonzonas 22/03/2018 17:18:26: Comparing: 1,197 files (9.7 GB) 22/03/2018 17:26:02: Execution completed successfully Completed: 1197 files, 9.7 GB Performance: 2215.0 MB/minute (2309.4 copy, 1301.4 compare) Duration: 01:21:01 (00:00:01 idle/loading/preparing)
  20. This time, the duplication script is NOT doing any deletions. It appears to be reinstating all the previously deleted files (even those that I had reinstated manually from the recycle bin on the NAS).
  21. After reinstating the files that were previously deleted in error on my NAS, I restarted my Retrospect duplication script with the Replace if Source is Newer setting. All seemed well at the beginning, as all the source files were scanned and then all the existing files on the destination were scanned. However, it then started once again to try and delete files from the NAS, except that I could see no evidence of such deletions. I kept on pausing the script and checking the NAS, but nothing was transferred to the Synology recycle bin and the size of the Photos folder never reduced (despite several refreshes of the file listing). This went on for at least 5 minutes until I chose to stop the script. After stopping the script, I checked the NAS again and found that over 9GB of files had indeed been deleted. The process had obviously been inhibiting any update of the NAS file listing until it stopped. I am now trying again using the Duplicate Missing Files Only option.
  22. I think you might have highlighted my real problem! As I mentioned in my OP, the digital images have been moved to a new folder on my NAS. I therefore had to modify the destination in my duplicate script. The last time I modified or created a duplicate script was some years ago, so my skills are a little rusty. I didn't notice the Replace Entire Volume setting when I defined the new destination. Grrrrrrrr. I have now changed this setting to Replace if Source is Newer and will give it try after transferring the previously deleted files from the Synology recyle bin. All my recent traumas with backup hardware and software have been thoroughly documented to reduce the chances of me making the same stupid mistakes again.
  23. Recopying all my digital images to the NAS when they already exist there is a real pain. Is there no way to trick Retrospect into accepting the new UUID?
  24. Interesting. The next time I hit a backup set member relocation problem I will check if a fast catalog rebuild using the session files would be sufficient to fix it.
×
×
  • Create New...