Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Scillonian

  1. If the Owner, Group and/or Permissions have been changed in the copy from the backup NAS the idea would be to login to the new NAS via SSH and use the chown command to change the Owner and Group and the chmod command to change the file permissions as necessary.
  2. Issues with using optical disks in Retrospect 15

    If you would still like to recover the old configuration for the drive I believe the custom configuration files have a .rdi file extension. The .rdi files shoul be located in one of the Retrospect folder in Program Files or Program Data. I'm not near a machine running Retrospect at present so can't be certain which folder.
  3. What shown for Owner and Group on the backup NAS? If the Synology Backup and Replication was doing its job then the Owner, Group and Permissions should be what they were on the old NAS. The Backup and Replication would have been the best option to restore the files to the new NAS. Has Synology created a replacement for Backup and Replication? Have you ever accessed your NAS via SSH and do you have any experience of command line Linux?
  4. It could do with a better name. In use it means the Destination is always an exact copy of the Source. You add a file to the Source it gets added to the Destination. You change a file on the Source it gets updated on the Destination. You delete a file on the Source it gets deleted on the Destination. It will also delete any other files, however they got there, that are on the Destination that are not on the Source. The other options do not delete any deleted or extraneous files. That is what I was hoping you did but this may also be what caused the problem. I don't know about the Synology File Station but the QNAP equivalent has a habit of changing the Owner:Group information on the NAS file system for the copied files. If the Owner:Group on the NAS file system are different to the Owner:Group that Retrospect presents then the files will be seen as different. How were the files duplicated to the backup NAS from the old primary NAS?
  5. Issues with using optical disks in Retrospect 15

    Would your "all file" backup include the Retrospect configuration files in it. If it does then you may be able to recover your configuration from before you made the change.
  6. I've checked the log of a small Duplicate script that runs daily (see below). Once Retrospect has scanned the Source it identifies which files have changed then deletes the old versions on the Destination before copying the new versions to the Destination. Retrospect does't overwrite a changed file on the Destination — it deletes the old version then creates the new version. Unchanged files are skipped. In the script the Destination is set to Replace Entire Volume and there are 23 files and 35 folders on the Destination. When you copied the digital images from your backup NAS to your new NAS what method did you use? This could also have an effect on your chances of success.
  7. Is the share name and folder structure EXACTLY the same on your new NAS as they were on your old NAS? In order to convince Retrospect that not much has changed you need to make the new configuration match the old configuration as much as possible. Also it is worth checking is what option are set for the Destination of the Duplicate script. If this has been set/reset to Replace Entire Volume then every time the script is run Retrospect will delete everything on the Destination and copy it again. When you copied the digital images from your backup NAS to your new NAS what method did you use? This could also have an effect on your chances of success.
  8. Every time a backup is run Retrospect will create a .session file, containing details of the files from that backup, in the same folder as the .rdb files. When Retrospect does a Catalog rebuild it will read these .session files for the necessary information which is faster than reading the individual.rdb files. If you need to perform a thorough rebuild it is necessary to delete the .session files. (During the rebuild the .session files will be recreated.) This feature for faster Catalog rebuilding was added in Retrospect 11 for Windows and Retrospect 13 for Macintosh.
  9. In the past when you updated DSM the UUID (Universal Unique IDentifier) of the volume on the NAS would not change. By changing to Btrfs the volume will now have a different UUID. Even if you had kept the same file system for the volume on the new NAS it would still have a different UUID. The only way you could have kept the original UUID would have been to transfer the hard disks from the old NAS to the new NAS and keep the existing storage configuration.
  10. Hopefully your problems are down to a simple typing error. Your folder structure is invalid. It should be \\BONZONAS\PCBackup\Retrospect\Backup Set NAS1(e)\1-Backup Set NAS1(e) (based on your previous posts) not \\BONZONAS\PCBackup\Retrospect\Backup Set NAS1e\1-Backup Set NAS1(e). The member folder name is always the Backup Set folder name with an n- prefix added. You can ignore the following if you like but I'll leave it here for the moment to show how sometimes it easy to overlook what it there in plain sight. I should noticed it in your previous post! I've had a look at the log. Is \\BONZONAS a home-built NAS or a commercial unit such as QNAP or Synology? Retrospect can at least see that there are files in the 1-Backup Set NAS1(e) folder. Retrospect is doing a thorough rebuild of the catalogue by reading the contents of the .rdb files. Had you deleted the .session files from the folder 1-Backup Set NAS1(e) before starting the rebuild? Retrospect is trying to create the AA130340988226970000.session file to a location that does not exist. For some reason that I can't fathom the path for the member folder has been almost duplicated. \\BONZONAS\PCBackup is the NAS and share. \Retrospect\Backup Set NAS1e\1-Backup Set NAS1(e) is as it should be. \Retrospect\Backup Set NAS1(e)\1-Backup Set NAS1(e) is almost duplicated part. ** And this is when I realised it was hopefully a simple typing error **
  11. It'll be interesting to see how they will define what are 'server-level Linux distributions'.
  12. I'll have a look this evening when I'm near a PC again.
  13. Just looked at your naming structure again and realised why it wasn't working. Backup Sets have to exist in a parent folder named Retrospect. In the case of a NAS (or other network share) the Retrospect folder has to exist withing a share folder. It can't be the share folder. I should have noticed the error earlier! 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. I use the Advanced option because direct entry of the UNC path doesn't always work for me. Retrospect will sometimes give an error along the lines of the network resource does not exist. This may due to my Backup Sets being in hidden shares on my NAS. I'm using Retrospect 15 Desktop for Windows but this has worked for me since 7.x of Retrospect when I started using a NAS for backups. (Used tape before that.) [From the Windows side] The Retrospect folder can exist as a top level folder on any HDD connect directly to the Backup Server either internally or externally. On an SMB share (e.g. Samba on a NAS) the Retrospect folder must reside in a share folder which in haggis999's case would be PCBackup.
  14. I've just done a trial move of the Snowball-WS [B1611] Backup Set on my NAS. Original location of Backup Set files: \\Boxer\BackupSets-Other\Retrospect\Snowball-WS [B1611]\1-Snowball-WS [B1611]\*.rdb New location of Back Set files: \\Boxer\BackupSets-Temporary\Retrospect\Snowball-WS [B1611]\1-Snowball-WS [B1611]\*.rdb This is what I did: Configure > Backup Sets In the Backup Sets dialog select Snowball-WS [B1611] and click Properties... In the Snowball-WS [B1611] Properties dialog select the Members tab On the Members tab select 1-Snowball-WS [B1611] on BackupSets-Other and click Properties In Member Properties for 1-Snowball-WS [B1... dialog Location for backup data folder: will display \\BOXER\BackupSets-Other\ Click Browse In the dialog that appears (labelled Retrospect) offering places to browse click Advanced... In the next dialog (also labelled Retrospect) where it asks Please enter the UNC or HTTP path for the volume or subvolume: enter \\BOXER\BackupSets-Temporary and click OK In Member Properties for 1-Snowball-WS [B1... dialog Location for backup data folder: will now display \\BOXER\BackupSets-Temporary\ Click OK to save the changes On the Members tab in the Snowball-WS [B1611] Properties dialog the member is now shown as 1-Snowball-WS [B1611] on BackupSets-Temporary Exit the Snowball-WS [B1611] Properties dialog and the Backup Set is now working in its new location I've used my NAS name (BOXER), share names (BackupSets-Other, BackupSets-Temporary) and Backup Set name (Snowball-WS [B1611]) here for simplicity (of writing) so you will have to change these as appropriate. I move the location of active Backup Sets on my NAS quite often and this has always worked for me. I've also never had to rebuild the catalogue after moving a Backup Set.
  15. Retrospect does not finish backup

    Which version of Retrospect and which version of Windows are you running?
  16. Error scanning network 1116

    Retrospect will run successfully in a virtual machine. For many years I successfully ran Retrospect in a VMware Workstation virtual machine. Do you have both IPv4 and IPv6 enabled on your network? I have come across instances where you can browse the local network over IPv6 but not over IPv4. This is not a problem for applications that are IPv6 aware but for applications that are IPv4 only, such as Retrospect, any attempt to browse the network from that application will fail. Personally I gave up on trying to browse the 'Microsoft Windows Network' years ago because it so very rarely worked and instead enter the UNC for the desired Source using the 'Advanced...' button.
  17. This will not work where Retrospect.exe is launched by the Retrospect Launcher service. From Windows Vista onward applications that run as a Windows Service, and any application(s) that they may launch, are not allowed to have* a GUI. (*Although it is the same Retrospect.exe that has GUI functionality when launched by a user, that functionality is disabled/suppressed when it is launched by the Retrospect Launcher service.) Applications that run as a Windows Service from Windows Vista onward are also not allowed to interact directly with a user. This is why dashboard.exe exists in Retrospect for Windows to allow indirect user interaction with Retrospect.exe when it has been launched by the Retrospect Launcher service. (I don't know if dashboard.exe communicates directly with Retrospect.exe or through the Retrospect Launcher service.)
  18. Duplicate always erases all files first

    This could be because you are duplicating the files from the Windows NTFS file system to macOS HFS+ or APFS file system. There are attributes on NTFS which do not exist on HFS+/APFS that will have to be emulated such as file and folder security information. If you are only interested in the file contents and not the security information you could try disabling the duplication of the file and folder security information in the Duplicate script. From the Duplicate script's Edit dialog select Options > Windows > Security and deselect the file and folder security options.
  19. Error -530 (backup client not found)

    Have you tried disabling power management on the network adapters on the Client machines? I had -530 errors on a laptop and disabling power management on the ethernet adaptor solved it for that machine. This may be an interaction between Windows power management and certain chipsets. I've never had -530 errors from my machines with Broadcom and Intel chipsets but my laptop with a Realtek chipset had -530 errors until I disabled power management.
  20. Disaster Recovery Disk Method

    Are you running a version of Bootcamp on the Mac Mini that is compatible with Windows Vista? From what I have read Apple started to drop support for Windows Vista with version 3.2 and dropped it completely by version 4.
  21. In this respect there is no difference between 12.5 and 12.6.
  22. On the Windows platform Retrospect is a monolithic application. The reason for the behaviour you have observed is because of security features that were introduced with Windows 7. In short the restrictions are that any application that is automatically launched in not able to interact directly with a user, even if it was launched as that user. For Retrospect to Work on Windows the same way it does on Mac will [apparently] require a substantial rewrite. There have been hints in the past from Retrospect staff that they thinking about doing this, maybe, one day but that is about it for now.
  23. Disaster Recovery Disk Method

    You only need to create the Disaster Recovery Disk on the Backup Server. If you have a valid Disaster Recovery license on the Backup Server the functionality will be added to the Disaster Recovery Disk. When you boot the Client from the Disaster Recovery Disk the Dissimilar Hardware Restore will be available.
  24. Retrospect 12.x Cannot Backup System State

    Hi Tony This line is telling the user that Retrospect is trying to backup the System State but the underlying Windows function that is called is returning an error condition to Retrospect that Retrospect dose not understand. This would indicate to me that there is some problem with the 'EFI System Partition' which isalso referred to as the ESP. The ESP is a small hidden partition ~128 MB in size which contains the files necessary to boot an operating system on a device with UEFI firmware. A good place to check first for what the problem may be with the ESP is the 'Event Viewer' in Windows. Look for any error or warning events at the same time as Retrospect reported the error. Initially look for errors/warnings where the 'Source' is VSS (Volume Shadow Copy Service) as this is the Windows feature that provides the System State data. EDIT: What version of Windows are you running?
  25. ?corrupt data file - how to fix in 12.6

    The only solution I have found is to delete the corrupted .rdb file — in your case AA000077.rdb. Once the file has been deleted rebuild the Catalog file during which Retrospect will give a warning about the missing .rdb file. Grooming should now run to completion on the Backup Set as long as there are no other corrupt .rdb files. If there are then repeat the procedure. What I will add is that by manually deleting a .rdb file the integrity of the Backup Set is now compromised. When I have encountered this in the past I have as soon possible afterwards retired the Backup Set and transferred its contents, less what is in the missing file(s), to a new Backup Set. I have not found a way to directly repair a corrupt .rdb file but it is sometimes possible to recover the active contents of the file, if you really need to, by doing a Transfer Snapshot for the appropriate date to another Backup Set.