Jump to content

Scillonian

Members
  • Content count

    556
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Scillonian

  1. Scillonian

    Error -1103 after Windows 10 April Update

    If you are running the Pro, Education or Enterprise editions of Windows 10 then you can delay Feature Updates (which 1803 is) for up to 365 days. Unfortunately if you are running the Home edition you will get Feature Updates when Microsoft decides.
  2. Scillonian

    Error -1103 after Windows 10 April Update

    These were settings to suppress VSS warnings that I had made myself on the 1709 machine I was using for comparison. I doubt that added them to the 1803 machine before update. On the two machines that I have tested the 1803 update on they both fail with an -1103 error for the system volume. It makes no difference whether I do an Immediate, Run menu or Sheduled backup. However a clean install of 1803 on these two machines will backup without errors. One is an old HP xw4600 Workstation that was updated from production 1709. The other is a Dell Inspiron N5050 laptop that went from production 1709 to 1803 via various Isider Preview builds (starting at about 17115). I'm currently looking into whether the 1803 update is corrupting files in the C:\Windows\InfusedApps\Packages folder tree which I have found on two different disks. (Because it is not easy to gain access to this folder from within Windows I mounted the disk in Linux to see what was in this folder tree and while poking around the Caja file managed reported an error. Caja does not report an error for the same files on a clean install.) What is the VSS error you are seeing?
  3. Scillonian

    Error -1103 after Windows 10 April Update

    Are you using an online Microsoft Account (MSA) or an offline Local Account to login to these machines? I am about to start a clean install of 1803 on a 2012 Dell laptop and was wondering whether to add this permutation to the testing.
  4. Scillonian

    Error -1103 after Windows 10 April Update

    I changed a few permissions during my testing and I managed to get the VSS error to go away and also a backup of the system volume to partially work which led me down the path of it being a permissions migration problem. However I ran out of time so got no further. The changes on the 1709 machine were ones I had made some time ago related to VSS warnings in the Windows Event Log. Could this problem be related to the age of the processor? The machine I was testing on has a Core 2 Duo Q6600 processor. What is the processor in your old laptop? However this suggests that Retrospect Client can work with 1803: Hofstede: What are the processors in the four that work and the two that don't work? It may be nothing but I have in the back of my mind reading something about Windows 10 and hardware (processor) based security features in Windows 10 1803 that require recent processors to work correctly. No problem.
  5. Scillonian

    Error -1103 after Windows 10 April Update

    My testing so far suggests to me that during the upgrade from Windows 10 1709 (16299) to Windows 10 1803 (17134) some security settings related to Windows services are not being carried forward correctly. In the case of the Retrospect Client this is preventing it from correctly interacting with VSS for system volumes. The test machine I have 1803 installed on has two volumes — a system volume and a data volume. The system volume fails with the above error but the data volume completes without error. Initial comparison of some security permissions between a 1709 Client and the 1803 Client show some settings missing. However to be certain it is not something I changed in the past I'll need to do some more checking and do an 1803 clean install on something.
  6. The files and folders in the C:\Program Files\WindowsApps\ folder tree are for Windows Store UWP offerings and only TrustedInstaller and SYSTEM accounts have Full control permissions here which is needed for a restore. In theory the Retrospect Client should be able the restore here, as it runs under the SYSTEM account, but Microsoft have locked-down this folder so much that it is difficult to view the permissions of the folder let alone see what is in the folder! There is also the C:\Windows\SystemApps\ folder tree for Windows System UWP applications and only TrustedInstaller, SYSTEM, CREATOR OWNER and Adminstrators accounts have Full control permissions here which are needed for a restore. In theory the Retrospect Client should be able to restore here, as it runs under the SYSTEM account, but Microsoft have locked down this folder so much that by default it is not possible to even see what is in this folder. As far as a backup is concerned the Retrospect Client has sufficient permissions. I'll update this later with more details when back at desktop instead of a Nexus 7.
  7. On the Backup Server you will need to Forget the old instance of the Client and add it again. Even though this is a new instance of the Client on the Backup Server you will still be able to restore from the backups of the old instance including a full system restore.
  8. 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.
  9. 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. 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. If this one has had the same change of destination I suspect it will have the same issues.
  10. Scillonian

    Issues with using optical disks in Retrospect 15

    Thank you for the feedback. For the benefit of future reader the device configuration files are located at: C:\ProgramData\Retrospect\. The .rdi file will be named devicenn.rdi where nn is a two digit number starting from 00 for the first configured device.
  11. 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.
  12. Scillonian

    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.
  13. 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?
  14. 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?
  15. Scillonian

    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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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 **
  21. It'll be interesting to see how they will define what are 'server-level Linux distributions'.
  22. I'll have a look this evening when I'm near a PC again.
  23. 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.
  24. 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.
  25. Scillonian

    Retrospect 10.5.0.110 does not finish backup

    Which version of Retrospect and which version of Windows are you running?
×