If Reflect has determined that that isn't possible due to some change on the source disk, then you can't override that by changing settings. It won't allow Reflect to continue appending new backups to that older set. And to be clear, the retention policy setting change will just make sure that the older backups will still be purged according to your retention policy rather than being ignored. I have personally upgraded multiple systems from V7 to V8 without being required to start a new backup set as a result. But that would not be related to the Reflect upgrade. Now select a backup in the new set and compare the partition size figures you see there. Note the exact sizes of each partition in the map, which is the lower figure on each partition. If you want to check this, look in your Existing Backups tab and select one of the backups in the older set to display the partition map of the disk contained in that image set above. It's more likely that a Windows update was installed that altered your partition layout, even if only slightly. The "ignored" Incrementals wouldn't be related to the upgrade. But see the first post in this thread for a possible explanation of why that's occurring and what you can do about it.
A backup executed from the Backup Definition Files tab would run in your user context.Īs for not "seeing" your existing backups, that would be a completely separate issue from an error that prevented the backup job from even accessing the destination. Having a mapped drive wouldn't change anything for scheduled backups, including manual invocations from the Scheduled Backups tab, because again, only backups run within your user context would have access to drive mappings in your user context.
Is that the case? The more specific you can be about what's going on, the more likely you'll be able to get useful assistance. For the first screenshot, exactly what method did you use to run the backup? Does saying that it "ran on its own" mean that it was a normally scheduled backup executing according to a schedule? If so, then this would appear to be a case where an invocation method that reliably worked in the past is now broken.
0 kommentar(er)
