By zr0 - 4 February 2022 12:19 AM
This error message only started popping up after I upgraded from the free version to paid.
I'm currently on v8.0.6392
I've browsed the forums and have probably found every person with this issue on different versions of Reflect.
I've tried all the suggested solutions but nothing has worked.
Trying to create backups on a NAS (which worked fine on free version), credentials are entered correctly.
Backup works fine if ran manually from the Scheduled Backups tab.
I'm out of ideas on how to fix this issue. And also very curious why this would happen when the only change was upgrading from free to paid?
|
By jphughan - 4 February 2022 3:05 AM
The backup works correctly when you use the Scheduled Backups tab? So the failure condition is when you invoke it from the Backup Definition Files tab? That's the opposite of the "typical" problem scenario, because invoking the job from Backup Definition Files would cause the job to run in your own user context, in which case Reflect would have access to network connections open in your user session. Do you have an open network connection to this network share in your user session? If so, are you possibly connected to that share using an account that's limited to read-only access as a security precaution? If so, Windows doesn't support connecting to the same share within the same user context using multiple separate credentials, which means that if there's already an open connection, Reflect wouldn't be able to use the credentials you're storing in the application when running backups within your user context. It would have to rely on the connection that was already open. The credentials only come into play when there is NOT an existing network connection open in the user context that's running the backup.
All that said, if that were the problem, I would admittedly have expected an error message more clearly identifying that as the cause, but if the job fails ONLY when run interactively and not when executed as a background scheduled task, that's the only item that comes to mind.
|
By zr0 - 4 February 2022 4:45 AM
As far as I am aware, there is no open connection to the network share. I did go into the NAS and see that there was a connected user (me) using my 'Windows Backups' folder under 'Resources' (I forgot to screenshot it before I killed it). But the timestamp lined up with when the backup tried running the first time today.
I agree it's odd that it works when run from the Scheduled Backups tab as I've seen in other posts people saying the opposite.
Any of my accounts to the network share have full read/write permissions.
Should Macrium need the credentials regardless? Is there any scenario where it could write to the NAS without credentials?
|
By jphughan - 4 February 2022 5:12 AM
If you run an interactive backup with an existing read/write connection open, Reflect should be able to write to the NAS. In fact that may be worth testing just as a data point. Try mapping a drive to the share path you use in your Reflect job and then run the backup interactively. No need to modify the backup job specifically at the mapped drive letter. As long as the Reflect job and the mapped drive point to the same network path, you should be good to go.
|
By zr0 - 4 February 2022 5:23 AM
I'll have to wait until tomorrow to see if the scheduled backup works. If I run it manually, I know it will work as usual. There must be something going on when I restart the computer.
The free version I had was v7 and now I'm on v8. Probably nothing to do with anything, I just can't understand why this is all of a sudden a problem when it was working as expected prior to upgrading.
Will report back tomorrow.
|
By jphughan - 4 February 2022 5:27 AM
No, I meant map a network drive and then try running from the Backup Definition Files tab so it runs in your user context. If a manual invocation from Scheduled Backups works, then a typical scheduled backup would work too (unless maybe there was something about the specific time the job was running), so that wouldn’t be a useful data point.
|
By zr0 - 4 February 2022 5:34 AM
That's the thing - manual invocation from Schedule Backups does work. Seems to only happen on the first (the only) backup of the day.
I mapped the share as a network drive and ran both Backup Definition File and Scheduled Backups manually. They worked.
I guess I'll just have to wait and see what happens tomorrow. I honestly can't think of anything that would prevent the user/pass from working.
|
By jphughan - 4 February 2022 5:41 AM
Ok, time to back up. Your original post mentioned that manually running a backup from Scheduled Backups works. I figured, apparently incorrectly, that what WASN’T working in that case was interactive backups invoked from the Backup Definition Files tab. You didn’t correct me on that, but now you just said that the failure occurs with a regular execution of a scheduled backup. (Next time it would be worth being as clear about the failure circumstances as about the success circumstances.)
So does this first backup of the day always occur at a specific time, or does it run as soon as you start your system, or what?
|
By zr0 - 4 February 2022 5:46 AM
I think I mistook what you said originally about it failing from the Backups Definition Tab. But yes, the ONLY time it fails is on a new scheduled backup (daily)
It will usually run when I turn on the system. It's scheduled for 9:00am but usually start it up later than that.
There have been absolutely NO changes to anything since upgrading. To the system, to the network, or to Macrium (other than upgrading)
|
By jphughan - 4 February 2022 6:06 AM
Can you try moving the scheduled backup to a time when your PC will reliably be on? It would be useful to isolate the variable of "first/only backup of the day" vs. "backup attempted as soon as the system powers on", in case something may be going on that causes network connectivity not to be ready somehow when Reflect attempts to run a backup as soon as the system starts.
|
By zr0 - 4 February 2022 6:11 AM
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.
|
By zr0 - 4 February 2022 7:04 PM
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.
|
By jphughan - 4 February 2022 9:36 PM
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.
|
By zr0 - 4 February 2022 10:30 PM
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:
 
|
By jphughan - 5 February 2022 12:31 AM
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.
|
By zr0 - 5 February 2022 12:54 AM
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.
|
By jphughan - 5 February 2022 2:37 AM
Wait, earlier you said that manually running from Backup Definition Files did NOT work. Which is it?
|
By jphughan - 5 February 2022 2:41 AM
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.
|
By zr0 - 5 February 2022 2:49 AM
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.
|
By jphughan - 5 February 2022 4:43 AM
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.
|
By zr0 - 10 February 2022 5:00 PM
So I jumped into a remote support session with Macrium and while we were troubleshooting an idea popped into my head to try creating a new user on the NAS.
So far that seems to be working.
I'm still truly baffled as the other account I was using had no changes made to it prior to all the scheduled backups failing.
However, if this solution sticks, I don't really have a problem having an account on my NAS strictly for backups.
|
By jphughan - 10 February 2022 5:37 PM
Glad it’s resolved, although I know the frustration of fixing a problem without realizing why the problem is fixed. But a dedicated NAS user isn’t a bad idea. As a security precaution, I recommend creating a dedicated SHARE for your Reflect backups, separate from all other data, and then granting access to two user accounts. One has read-only access and one has read/write. The read/write credentials to go Reflect, and the read-only credentials are used whenever you want to access the share within Windows for the purpose of restoring backups or extracting data from them.
|
By zr0 - 10 February 2022 5:54 PM
That's a great idea! I'll set that up to ensure everything runs smoothly in the event of having to restore from a backup. Thanks for the suggestion!
|
By jphughan - 10 February 2022 5:56 PM
Glad you like it! It’s a nice additional safeguard against malware. If network connections within Windows Explorer practically always use read-only credentials, then malware wouldn’t be able to piggyback on that connection to perpetrate destruction of your backups. The chances of the malware looking for the read/write credential info stored by Reflect are much slimmer than malware just taking advantage of whatever network connections are already open.
|
By zr0 - 15 February 2022 6:00 PM
So a couple days go by and the same thing starts happening again.
Now I'm really at a loss.
Don't really have anything new to add, just thought I would update the thread in case anyone else can chime in.
|
By zr0 - 15 February 2022 6:19 PM
Just enabled these in case they have any affect.
They weren't enabled when it ran on this account before and it worked but the logs do say that the user I created is accessing the folder through SMB3.
It's almost like Macrium piggy backs off a connection if I have accessed the NAS in anyway.
I made sure to restart the computer and schedule the backup to run after a couple minutes and it succeeded.
We'll see if that sticks or not.
|
By jphughan - 15 February 2022 6:24 PM
Still no idea what's going on with your system given the parameters of this behavior, but Reflect relies on Windows for file share connections, Windows uses SMB, and SMB 3.0 specifically has been available since Windows 8 / Server 2012. If that wasn't enabled before, then I'm not sure how it worked at all beforehand unless the default state is to allow anything unless you specifically choose to set per-protocol policies.
|
By zr0 - 16 February 2022 5:04 PM
Yep still failing.
I'm about ready to just write to the local disk and let Synology Drive Sync the files.
Scheduled backup failed same as usual, but ran manually from the scheduled backups tab, it worked.
Another anomaly I'm noticing is that the scheduled backup used a different user (the one I was originally using but removed from Macrium)
When I manually ran it, it used the other user.
|
By zr0 - 19 February 2022 8:40 PM
I'm still going at it trying to figure this out. And I'm leaning towards this having something to do with the Windows Credentials Manager.
Still a bit confused on how it works, but from what I understand, you can't have two different connections/credentials to the same network location in order for Macrium to work correctly?
Windows is using the UNC name for the network location in file explorer but I'm also using the IP for network folders (it was having issues using the UNC path)
So basically, UNC path is used if accessing the network through file explorer (unless I access the drives directly where it uses the IP address). I need this functionality to read/write files to the NAS.
Is there any way to configure this so that Macrium will be able to connect? Do I need to utilize this section in Macrium?:
|