Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by haggis999

  1. 5 minutes ago, Lennart_T said:

    Your "new" NAS might have a different software version, making the file's metadata look different. For that reason, Retrospect does not see your files on the "new" NAS as identical (in all respects) with the files on your "old" NAS.

    At least that's my theory about what happened.

    I have always updated the DSM operating system on my Synology NAS on a regular basis, but this has never interfered with past duplications. My recent change to use the Btrfs file system on the NAS still seems the most likely reason for my current problem. Perhaps the turning off all duplication of file and folder security settings that worked for Scillonian in a similar situation is not enough to overcome the problem for Btrfs.

  2. I have just noticed a recent thread called 'Duplicate always erases all files first', which has a reply from Scillonian that I thought might also apply in my case.

    When I rebuilt my NAS, I created a special Synology version of RAID called SHR and took the option to use the Btrfs file system. Given Scillonian's comments in the earlier thread, I tried turning off all duplication of file and folder security settings. However, when I tried to re-run my duplication script it still initiated a deletion operation. 

  3. I was forced to rebuild my primary Synology NAS after a recent disk crash and had to copy all the data from a backup Synology NAS. For various reasons, I then chose to reorganise the top-level shared folder structure on the primary NAS, with the result that my digital photos are now stored in a new location.

    When I tried to run my previous Retrospect 12 script to duplicate the Pictures folder on my Windows PC to the NAS (after modifying the script to use the new location), it started to delete a large number of photos from the NAS. I stopped this after it it had deleted 153GB of the images, out of a total of 470GB (the deleted photos are still in the Synology recycle bin).

    Given that the PC and NAS versions of my Pictures folder were almost, if not totally identical, such behaviour was very puzzling. Why might Retrospect be wanting to replace all the images?

    For reasons I don't really understand, there is a small difference in the time stamps for all the deleted files I have just checked, but I doubt if this has anything to do with the recent reorganisation on my NAS. For example, one of the deleted images has a time stamp of  1 Sep 2014, 15:31 on the PC and 1 Sep 2014, 15:37 on the NAS. I suspect that this has always been the case, and if so, it never previously interfered with the Retrospect duplication process.

  4. I am very happy to report that the catalogue rebuild ran without any problems this time. It also took only about 5 mins instead of 1 hour. The location of 1-Backup Set NAS1(e) is now shown correctly in Member Properties and my normal backup script has just successfully updated the backup set on my primary NAS.

    The original folder was almost certainly named correctly on my primary NAS before it crashed. My mistake several years ago was probably to have misnamed the folder on my backup NAS, so that I was replicating Backup Set NAS1(e) to a folder called Backup Set NAS1e.

    Thanks again for your sharp eyes!  :)

  5. Well, you certainly spotted an anomaly I had failed to see for myself, but it wasn't the result of a recent spelling error.

    I lost the original copy of the Retrospect backup set when my main Synology NAS died a couple of weeks ago. Retrospect backed up my Outlook folder to this NAS three times a week for several years without any problems. Any changes to this NAS were also replicated on a regular basis to my backup Synology NAS and the folder name of Backup Set NAS1e is how it appears on my backup copy of the Retrospect backup set.

    I don't know anything about session files, but I certainly didn't knowingly delete them at any stage.

    I have now renamed the folder containing 1-Backup Set NAS1(e) as Backup Set NAS1(e) and I will make another attempt to rebuild the catalogue.

    Many thanks for your help.

  6. Unfortunately, the rebuild of my other catalogue generated quite a few errors, as you can see in the attached log file. To make it easier to focus on the errors, this file has been edited to remove most of the successful verification messages. The log starts by correctly scanning  \\BONZONAS\PCBackup\Retrospect\Backup Set NAS1e\1-Backup Set NAS1(e)\ , but then goes on to try and create various records using the incorrect path of \\BONZONAS\PCBackup\Retrospect\Backup Set NAS1e\1-Backup Set NAS1(e)\Retrospect\Backup Set NAS1(e)\1-Backup Set NAS1(e). I don't understand this or any of the other errors.  

    Unlike with my first catalogue, the rebuild has not helped with changing the location of this backup set in Retrospect. I still can't set the correct location in Member Properties.


    EDIT:  In case it is relevant, Backup Set NAS1(e) is dedicated to backing up my Outlook email folder and my associated backup script uses the block level incremental backup option.

    Retrospect rebuild errors for 1-Backup Set NAS1(e) - March 2018.docx

  7. 1 minute ago, Scillonian said:

    In Member Properties for ... dialog the Location for backup data folder: should be \\BONZONAS\PCBackup\ if this Backup Set is in the same Retrospect folder as Backup Set NAS1.

    That's exactly what I tried to enter, but it triggered the previously mentioned error.

    I'm now rebuilding the second catalogue file to see if that fixes it. Other people have reported the need for a catalogue rebuild to avoid this error, so it's a little strange that you have not been affected in the same way.

  8. I've cracked one of my problems. Retrospect appears to insist that the backup set folder is located in a folder called Retrospect, but won't accept that folder being in the top level of the NAS hierarchy (what Synology calls a 'shared folder').

    I changed to the following structure and now all appears to be well with the backup set I had recatalogued.

    • \\BONZONAS\PCBackup\Retrospect\Backup Set NAS1\1-Backup Set NAS1\*.rdb

    However, I still have the same old error with another backup set, even though it now has the same new path of  \\BONZONAS\PCBackup\Retrospect\. Perhaps I also need to rebuild its catalogue before it will work.

  9. Many thanks for that suggestion, though the only difference I can see between your procedure and what I have done before is that you used the Advanced option to specify the new location (I simply typed the UNC location directly in the Member Properties box). However, I have tried your method. Sadly, it made no difference. I still get the "Cannot use the specified backup data folder" error ar Step 10 of your procedure.

    What version of Retrospect are you using? Does your method work if you try to use a new location as follows?

    \\Boxer\Retrospect\Snowball-WS [B1611]\1-Snowball-WS [B1611]\*.rdb

  10. After two and three-quarter hours, Retrospect has now completed rebuilding the catalogue and the log says that it was completed successfully. However, I am now having problems in trying to restart the previous daily backup script for this backup set. 

    The new path to my backup set is as follows,

    •  \\BONZONAS\Retrospect\Backup Set NAS1\1-Backup Set NAS1

    However, the script is trying to use the following path, which obviously fails with a  'file/directory not found' error,

    •  \\BONZONAS\Retrospect\Backup Set NAS1\1-Backup Set NAS1\Retrospect\Backup Set NAS1\1-Backup Set NAS1

    Once again , I find myself back in the Member Properties dialogue box unable to correct the location infornation. I appear to be going in circles! 

  11. The suggestion provided via your latest link is that if you change the directory structure in some way you will need to rebuild the catalogue file so that it points to the correct location. I'm not sure how that works when Retrospect appears to actively prevent you from changing the location. Until I have made that change, then surely any catalogue rebuild will simply continue to use the existing location?

    However, perhaps the rebuild process provides a different way to make the location change within Retrospect to match the change already made on my NAS.


  12. I'm aware that Retrospect has had a chequered history. However, it still provides a very powerful backup tool, despite the sluggishness in fixing bugs highlighted many years ago. More to the point, I'm not aware of any other software that does a similar job at a similar price.

    I'm used to the idea of using quotes in other forums to limit a search to the whole phrase, thus eliminating all the partial matches, but in this case I didn't get ANY match for that error message (apart from this thread) until I encapsulated it in quotes. That seems a little odd to my eyes. Why does it need the quotes to find a mention of that exact error message in the 2007 thread you mentioned earlier?

    It's some time since I looked at my issues with autolaunching Retrospect, so I can't remember if an -530 error was involved, but I'll keep your comments in mind when I find the time to look at this again.


  13. Your first link is interesting. It quotes Retrospect tech support saying that problems with relocating the backup set are on their bugfix list. That was over 11 years ago!!

    Earlier this afternoon, I searched the forum for "Cannot use the specified backup data folder", but failed to find any thread except this one I raised today. However, my search was done without encapsulating the phrase in quotes. Adding the quotes at the beginning and end makes a surprising difference to the search results.

    With regard to your second link, I never did get to the bottom of why Retrospect no longer autolaunched in a reliable manner, despite finding a way to nudge Windows 10 into rediscovering my NAS drives. Certain events, such as my recent NAS rebuilds, made Win 10 forget how to automatically discover my NAS units on the network, but mapping the drive to a drive letter was the key to jogging its memory (the drive mapping could then be deleted). Since then, I have just been starting Retrospect manually every morning.

    Many thanks for your help on this. I will try again to fix my current problem...


  14. I am currently looking at the Member Properties dialogue box for the relevant member of my backup set and simply trying to change its storage location, but I just get the message "Cannot use the specified backup data folder". I can browse to this folder from within the dialogue box, so what might be going wrong here?

    After my NAS (called BonzoNAS) died recently, it was rebuilt and had the data restored from a backup NAS. Previously, the member called 1-Backup Set NAS1 was stored in the following path and the Member Properties dialogue box successfully used a location of \\BONZONAS\Backup\.

    • Backup/Retrospect/Backup Set NAS1/

    I tried to store this member folder in a new path on the NAS as follows, but a location of \\BONZONAS\Retrospect\ doesn't work. I have tried moving 1-Backup Set NAS1 to a variety of different subfolders but I still can't find a path that is acceptable to Retrospect. It is insisting that I use a volume name of Backup on my NAS and is also appears to be insisting that I use a subfolder called Retrospect.

    • Retrospect/Backup Set NAS1/

    In other words, the only location that works is when I recreate the original path on the NAS! Is there a hidden secret to relocating member locations?

  15. I've just realised that you may have misunderstood what I was trying to do. It's not a matter of wanting to "move member folders of disk sets to new locations". It is the Backup Set itself that now has a new name and path on my NAS. This Backup Set has no subfolders and contains about 4,000 rdb files.

    EDIT:  Please forget this post! I misunderstood the terminology. It is indeed a member folder I am trying to modify.

  16. 18 hours ago, DavidHertzberg said:

    On second thought this smells like an account permissions problem (I only administrate a home LAN without any inter-person security complications), given that haggis999 reports in this post that he/she can run the problematic script manually and run other scripts that backup to the same drive.  IMHO haggis999 should read this Knowledge Base article again, paying special attention to the numbered items at the start of the article and to the "Retrospect 6.5 and Later" section at the end of the article.  The Retrospect Windows 12 equivalent to the procedures in that section starts on page 419 of the UG, headed "Run Retrospect as...".  Haggis999 may have to recreate the problematic script logged-in under an account that corresponds to the account for the Subvolume. 

    Thanks for persevering with this, David. I will do as you suggest and check out that KB article more carefully over the coming weekend.

  17. I've just checked the member properties as Scillonian advised and found that the location is already in UNC format (\\PRIMARYNAS\Backup\). However, the job in question actually saves the backup in \\PRIMARYNAS\Backup\My Pictures. You suggest that this might be a problem, but the job has been running successfully for many years. It's only become an issue since Windows 10 decided to forget my NAS boxes.

    I already have my primary NAS listed under Quick access. That's useful in Windows Explorer, but doesn't help Retrospect find the NAS when running an automated job using the Retrospect Launcher.

  18. I'm hitting similar problems with Windows 10 occasionally losing the ability to discover the NAS boxes on my home network, a situation that is currently preventing one of my automated backup jobs from running (though it works fine if I open Retrospect manually before the job is due to start). Rather oddly, several other automated backup jobs that use the same NAS (though not the same destination folder) continue to run fine. I've just upgraded to V12.5, but it made no difference.

    However, I have not yet found a way in Retrospect to specify the backup destination using the UNC path. I would appreciate some guidance on this point.

  19. That KB article doesn't appear to contain anything relevant. It merely addresses some of the basic issues regarding how to configure Retrospect for auto launching, something I sorted out a long time ago.

    However, it now appears that an issue with the Windows 10 network discovery process is the most likely source of my problem. If I open up Windows Explorer and click on the Network icon, it is not currently displaying my NAS drives (something it normally does), though they are listed under 'Other devices'. I have seen this before and have never found the cause, but it just tends to go away after a few days and everything returns to normal. It's very irritating. Grrrrrrr.   

  • Create New...