Jump to content
haggis999

Why is my duplication script trying to erase all my files just because I have moved the destination?

Recommended Posts

23 hours ago, haggis999 said:

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?

That would be correct for your setup.

My NAS is setup for multiple users with restrictions on which users can access which shares so maintaining the Owner, Group and Permissions on files and folders becomes necessary.

23 hours ago, haggis999 said:

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).

I ran a test duplication using Replace Entire Volume with two old Buffalo LinkStation as the destinations and it would appear to be expected behaviour from Retrospect to delete and recopy everything when the destination physically changes. (Duplicate to 'A'; Copy from 'A' to 'B'; Duplicate to 'B')

It was having a few of these incidents myself with my camera raw digital images that convinced me to use backup instead of duplicate.

11 hours ago, haggis999 said:

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.

If this one has had the same change of destination I suspect it will have the same issues.

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, Scillonian said:

I ran a test duplication using Replace Entire Volume with two old Buffalo LinkStation as the destinations and it would appear to be expected behaviour from Retrospect to delete and recopy everything when the destination physically changes. (Duplicate to 'A'; Copy from 'A' to 'B'; Duplicate to 'B')

It was having a few of these incidents myself with my camera raw digital images that convinced me to use backup instead of duplicate.

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.

7 hours ago, Scillonian said:

If this one has had the same change of destination I suspect it will have the same issues.

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.

 

Share this post


Link to post
Share on other sites
13 hours ago, haggis999 said:

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.

In short an Archive script is a Backup script but with the additional option to delete the copied files from the Source once they have been copied to the Destination and verified.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Scillonian said:

In short an Archive script is a Backup script but with the additional option to delete the copied files from the Source once they have been copied to the Destination and verified.

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.

Share this post


Link to post
Share on other sites

haggis999,

Here's the link to my post on submitting a Support Case for a bug.  If you don't have ASM, which I also don't have, you won't get personalized help in coping with your bug—but at least Retrospect Tech Support will be made aware it exists.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
On 25/03/2018 at 11:22 AM, Scillonian said:

I ran a test duplication using Replace Entire Volume with two old Buffalo LinkStation as the destinations and it would appear to be expected behaviour from Retrospect to delete and recopy everything when the destination physically changes. (Duplicate to 'A'; Copy from 'A' to 'B'; Duplicate to 'B')

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.

Share this post


Link to post
Share on other sites
6 hours ago, haggis999 said:

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.

     

As to how long bug #5994 has been open, a browser search for #59 in the Release Notes reveals that bug #5956 was fixed in the September 2016 release of Retrospect Windows 11.5—and they were already fixing bugs in the #60xx series by then.  I wouldn't hold my breath waiting.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×