I'll give it a shot but I do know that as soon as windows starts up, network connectivity is instant - I can navigate my network folders immediately, before the backup even starts.

Just ran again on it's own, computer has been on. Share was mapped to a network drive.
Still getting the same error.


Also noticing this when a scheduled incremental is set to run - it doesn't see the set that's already there.

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

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.  A backup executed from the Backup Definition Files tab would run in your user context.

As 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.  But see the first post in this thread for a possible explanation of why that's occurring and what you can do about it.

I'm sorry if I'm not being clear enough. Yes it was a regularly scheduled backup that ran. And again, if I run it manually, it works.
Exactly what you are saying - it is a method that worked before upgrading and now doesn't.
I made the changes mentioned in the thread you linked - but just like the backups, it was matching sets fine before the upgrade.
I'm not sure what other info I can relay.
Here's a couple more screenshots to show exactly how it's configured:

The "ignored" Incrementals wouldn't be related to the upgrade.  It's more likely that a Windows update was installed that altered your partition layout, even if only slightly.  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.  Note the exact sizes of each partition in the map, which is the lower figure on each partition.  Now select a backup in the new set and compare the partition size figures you see there.  But that would not be related to the Reflect upgrade.  I have personally upgraded multiple systems from V7 to V8 without being required to start a new backup set as a result.  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.  It won't allow Reflect to continue appending new backups to that older set.  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.

As to the original issue you reported, if scheduled backups that run on their regular schedule always fail, while backups invoked manually from the Scheduled Backups tab always work, but backups invoked manually via the Backup Definition Files tab fail (this is another example of why it's good to be clear about what you mean by "running manually"), then I don't know what might be going on.  I'm not aware of any changes made from V7 to V8 that affect network backups, apart from a recent V8 update that was meant to solve situations wherein backups to network locations that began right when Windows started might fail.  Macrium responded by adding this setting to allow delays there.  But you're seeing this even with other backups.  It shouldn't matter whether your scheduled backups are invoked by a schedule or executed manually from the Scheduled Backups tab, and if you have a mapped drive to that share with read/write access, then a backup initiated from the Backup Definition Files tab should work even if you had no credentials stored in Reflect at all.  But since those clearly aren't the results you're getting, if you don't get a response from Macrium Support here soon, I'd suggest opening a formal support ticket with them and referencing this thread.  And if you do that, please report back as to what was discovered.

Unfortunately I can't compare a new set because when it fails it doesn't create the image. And then I manually run it and it appends to the set anyway. I don't think windows has done any updates recently though either.
And it doesn't matter where I manually run the image - whether from the Backup Definition Files tab or the Scheduled Backups tab - it will work. It is only the regularly scheduled backups that have an issue.

I'll try reaching out to support on this and see if they've got any ideas. I appreciate all the help!

Will report back.

Wait, earlier you said that manually running from Backup Definition Files did NOT work. Which is it?

My mistake on the above, I went back and found that you said that Backup Definition Files execution DID work.  In that case, do you have any third-party anti-virus/anti-malware software running that might somehow be denying network access to a background task that executes without any manual input from you?  That's the only theory I've got at this point.

If the log showing "Full -- Incremental specified but no existing set to append to" came from a job that subsequently failed with the error we've been discussing all along (which wasn't clear because of how you cropped the screenshot), then I guess that would be because the network error prevented Reflect from seeing ANY existing backups.  But if manually invoked backups are still appending to the existing set, then don't worry about that error message on the jobs that are failing anyway.

That makes sense about the appending error.
I don't have any third party software or antvirus/antimalware running. Only windows defender which was active before any of this started happening.

I don't see any relevant errors in windows event viewer and the NAS doesn't report anything out of the ordinary.

Im wondering if by some odd chance, upgrading Macrium to home from free somehow either corrupted the way the user/pass credentials are being accessed or now that it's a 'different' program, the NAS - or windows - is somehow locking it out. Seems super far fetched but just throwing it out there.

Well if you want to test that out, it's easy enough.  You can just uninstall and reinstall Reflect.  The uninstaller defaults to KEEPING things like settings, logs, schedules, etc. -- basically everything you'd want to keep if you will be reinstalling again.  So it's a pretty painless process.

The only other variable I can think you could try changing, even though you shouldn't have to, is the scheduling engine.  Since Reflect 7.3, Macrium has offered the option to use either Windows Task Scheduler or their own Macrium Task Scheduler.  Try switching from whichever you're using now.  Reflect will automatically convert all scheduled backups over to the new engine, so it's painless.  I'm just curious if that somehow gets regularly scheduled backups working.  If it does, I won't have any idea WHY that would matter, since both engines should of course run scheduled backups properly, but it might at least give you a workaround for now, as well as a potentially useful data point for Macrium Support.