Macrium Support Forum

New issue - running a scheduled full backup ran twice

https://forum.macrium.com/Topic26849.aspx

By BobUlius - 2 December 2018 5:50 PM

Hi folks,

Brand new issue. Latest updates to Reflect on Windows 10. First time for this problem on 12/1.

I have a plan that is scheduled to run at 5:00 AM on the 1st as Full, then weekly Differentials and daily Incrementals. It did run as expected, BUT it ran again at 6:00 AM creating two full backups an hour apart. Has never done this before.

Task Manager looks correct. Scheduled backups in Reflect look correct. I do not see anything obvious in the vss logs.

What do you think?

~Bob
By jphughan - 2 December 2018 8:19 PM

Do you happen to live in an area that switched between Daylight Savings and Standard Time this past weekend?  Or more precisely, is your system set to a time zone where that would have occurred?  If not, open Windows Task Scheduler, find the scheduled task that corresponds to running Full backups for this job, select it, and check the History tab.  If it's marked as disabled, which it is on default Windows installations, then there won't be anything useful there.  But if not, it may take a while to populate, but after it does, is there anything useful in there?
By BobUlius - 2 December 2018 8:35 PM

Thanks for the reply.

Interesting thought on time change. It occurred on November 4th here, but this IS the first full backup since then. You think that could have caused it?

History is disabled in Task Manager. Reflect logs do show both being run, but nothing there that showed a failure to cause it to run again. Both fulls are the same size, both ran the retention rules.

~Bob
By jphughan - 2 December 2018 8:50 PM

There are a few threads here and in other forums that have nothing to do with Reflect about scheduled tasks behaving oddly after a time change.  In some cases, the anomalous behavior manifests as an unexpected additional occurrence an hour after the normal occurrence, after which the scheduled task continues as normal.  In other cases, the scheduled task completely fails to run and throws some error code, and that persists until the scheduled task is deleted and recreated (or perhaps modifying it is enough, I can't remember).  Both appear to be bugs in Windows Task Scheduler that have existed for many years and persist into the latest versions of Windows -- unless the recent Win10 1809 has finally solved this, although I'm not holding my breath.  The fact that this was the first time that particular scheduled task was executed since your time change is almost certainly NOT a coincidence, and since your behavior is the "unexpected extra occurrence" variation, things should carry on as normal going forward without you having to do anything.

Side note: The other behavior I described, where the scheduled task completely fails, is a perfect example of why I strongly recommend that people who use email notifications enable them for both failures AND successes.  Many people only enable them for failures, but the problem with that strategy is that you won't know if LACK of emails means that everything is going fine or nothing is happening at all.  In this particular bug, since the error in question occurs at a Windows Task Scheduler level, Reflect never even launches, which means that it would never generate a failure email notification about the problem.  On a server that is typically unattended (i.e. people aren't logging onto it on a regular basis), if the administrator has configured Reflect to only send failure notifications, this bug could cause that server to go quite some time with no backups being generated and nobody realizing there was a problem!
By jphughan - 2 December 2018 9:05 PM

One additional thought: Since I work in IT, I've simply set up a recurring reminder around time changes to check that things are working normally afterward, or in some cases to take action beforehand.  For an example of the latter, although in many cases getting an extra backup isn't such a bad thing, sometimes it can be.  In situations where you might only capture a Full every month or even every few months, getting two Fulls one after the other -- and therefore two runs of your retention policy -- could result in you losing your oldest Full and any of its child backups quite a bit sooner than you would have otherwise.  Or you might lose your oldest set to the disk space purge.  For cases where that risk exists, I'll set an alert for shortly before the time change.  At that time, I'll update the existing scheduled task to specify an end date before the time change, and then I'll create an additional scheduled task that has no end date but whose first occurrence is AFTER the time change.  Then before the next time change, I do it again.  In cases where an extra backup wouldn't create a problem, I'll just set an alert for after the time change to make sure that scheduled backups are still carrying on as normal if I'm not already set up to receive success email notifications
By BobUlius - 2 December 2018 9:34 PM

Great thoughts. Thanks again.

I AM set for successes as well as failures to be emailed. It only emailed ONE success for this task, however. I would not have noticed the additonal backup if I had not gone to my NAS to see the size and completion time. That's when I saw two within the hour and both started right on the hour.

It DOES give me one less retention set. Hopefully never a problem, but could be as you mention. You thought through this very well. Appreciated.

I'll assume this was it and check again on 1/1. If there are two then. I'll be back Smile

~Bob
By jphughan - 2 December 2018 10:05 PM

Hmm, you only got one email? Do the job logs of both runs mention sending an email? They should. Unless your email provider flagged one as spam or there was a transient issue that prevented one of them from being sent in the first place, I can’t imagine why you wouldn’t have gotten both emails. Reflect doesn’t skip emails based on how recently the previous backup occurred.
By BobUlius - 2 December 2018 10:32 PM

Interesting. Both logs show successful email sent. But I only recall seeing one. If I had seen two, I think it would have caught my attention. And did not go to SPAM. I have it white listed and check my SPAM daily.

Perhaps I am mis-remembering. But I don't think so.

We'll see what happens on 1/1 Smile
By dbminter - 4 December 2018 2:37 AM

Must be the time change thing.  I encounter the same behavior with all Task Scheduler tasks set to run on Monthly schedules.  And it's always the same behavior: the 2nd instance of the task always runs 1 hour later, exactly, after the last run, run on its scheduled time.


Unfortunately, the only solution I've seen for this bug, since Microsoft won't address it, is it delete and recreate all tasks that do this.
By bk3 - 8 January 2019 8:57 PM

I have run into a similar issue. Full backup scheduled for first Monday of the month at 23:00. In December, the full backup ran on the first Sunday at 23:00, then again on the first Monday at 23:00. Same thing happened in January (I didn't notice it until today). I checked task scheduler and the full task was only there once, scheduled for first Monday. Task history not enabled, so no help there.
By BobUlius - 8 January 2019 9:07 PM

Mine ran as expected on 1/1 - just once. Only glitch seemed to be after the time change. Perhaps it will glitch again on 4/1. I'll keep an eye on it.
By dbminter - 8 January 2019 9:41 PM

History has taught me it will happen again on the next DST time change.
By donald24 - 3 March 2019 11:48 AM

I have come across this now, too, a full backup being called one day too early (first sunday of month, ran actually first saturday, the again one hour later (collision because still running), and then programmed to be run a third time one day later, at correct planning-time.

I've changed my retention policy from backup-set-based to age-based, to tackle early deletion of my backups because of this.

I had no DST-change, this will be end of this month, maybe it's related to leap-year thing (FEB28 one week ago?) Is it enough to change the task properties or should I delete and recreate?
By donald24 - 3 March 2019 12:12 PM

Could this be a fix to the problem?



This checkbox in English is called: "Synchronizing across time zones". It will ignore local DST, and saving the current offset like UTC+2, so it will always have UTC in reference, and will not run based on your local DST. This might not exhibit this problem.
By jphughan - 3 March 2019 2:33 PM

That may indeed work, as long as you’re ok looking at schedules like that. However, Macrium doesn’t recommend editing Reflect scheduled tasks directly. I believe you might also find that that setting gets reset if you ever edit the schedule in Reflect, and some changes can cause scheduled tasks to no longer appear in Reflect, even though they do still work.

I’m not sure why this occurred for you unrelated to a DST change, though this is timely anyway because DST season is starting for various time zones soon.....

In terms of changing your retention policy to use time rather than number of backups, I’m told that Synthetic Fulls can’t be used in that scenario if you’re using those. Macrium says there’s no technical reason it couldn’t work, just that support hasn’t been implemented. And this may not be a practical risk in your case, but be aware that time-based retention policies have their own potential pitfall, namely that if you go a long time without performing a backup, your next backup job might wipe out most or all of your existing backups — especially if you have “Run purge before the backup” enabled. Someone posted a thread about this after running his first backup after a long vacation, for example.
By donald24 - 3 March 2019 3:54 PM

But I think, even when it's Microsofts bug, (which exists like Windows7 or maybe even earlier), Macrium should implement a reconfiguration after DST-change in their service, or any other feasible workaround, or even just pinpoint to this misbehavior when scheduling monthly backups. As least you can rely on Microsoft for not fixing this ancient bug!

Yeah, long time vacation and time-based would have a serious side-effect, which needs to be aware of.  Thanks for that.
By cousinit99 - 5 March 2019 7:32 PM

I also just had a full backup run for the second time (yesterday), where the corresponding task scheduler entry for the backup directs the task to run only once a month, on every first Monday.  The Daylight Savings Time scenario is a complete non-starter seeing as how the job doesn't even run on a Sunday.  The duplicate backup also ran several hours after the first one completed.  This duplicate backup did not occur last month, or any month prior...

What the heck is going on here?

  

  

  
By jphughan - 5 March 2019 7:37 PM

The DST bug's impact is not limited to the day that the DST switchover occurs. It affects the first execution of the scheduled task after the DST switchover, even if that occurs on a later date.  And apparently an even more insidious manifestation of that bug is that ALL occurrences of a scheduled task after the DST switchover simply fail.  In either case, the fix appears to be to delete and recreate the scheduled task.  In Reflect, that would be achieved by removing the schedule entries, clicking "Finish" on the definition file wizard to actually make the changes in Windows Task Scheduler, and then reopen the definition file edit wizard to add the schedules again.
By cousinit99 - 5 March 2019 7:46 PM

jphughan - 5 March 2019 7:37 PM
The DST issue is not limited to the day that the DST switchover occurs. It affects the first execution of that scheduled task after the DST switchover, even if that occurs on a later date.  And apparently an even more insidious manifestation of that bug is that ALL occurrences of a scheduled task after the DST switchover simply fail.  In either case, the fix appears to be to delete and recreate the scheduled task.  In Reflect, that would be achieved by removing the schedule entries, clicking "Finish" on the definition file wizard to actually make the changes in Windows Task Scheduler, and then reopen the definition file edit wizard to add the schedules again.

Alright, noted.  If those are the problem conditions, then unfortunately there's still a couple of incongruities outstanding.  First, the last time DST switched where I live was several months ago, and second, this particular backup has run several times since then, without the occurrence of a duplicate.  No other time zone changes have been made to the machine since its inception.

Either way though, thanks for the assist.  At the very least, I'm going to disable the automatic time zone feature.  I have no idea why the system would have spontaneously changed time zones, but yeah...
By jphughan - 5 March 2019 8:37 PM

Ah ok, I thought you might have been in a location that had a DST change this past Sunday since it's that time of year.  If that's not the case, then if the schedule specifically for your Full backups has behaved normally since the previous time change up until this past weekend, I'm not sure how to account for that.  Sorry!
By dbminter - 5 March 2019 8:43 PM

I've had Scheduled Tasks just randomly fail to run, too, even with no DST involved.  It just seems to affect Monthly tasks only and tasks only imported as XML files.  If you manually create the Task yourself, it seems to run okay.  And they will just randomly "die" on you, failing to run at all except Manually.  Microsoft's implementation of the Scheduled Tasks simply, well, stinks.  It has difficulty executing the simplest, well, tasks that are scheduled to run on Monthly schedules.
By cousinit99 - 5 March 2019 8:44 PM

jphughan - 5 March 2019 8:37 PM
Ah ok, I thought you might have been in a location that had a DST change this past Sunday since it's that time of year.  If that's not the case, then if the schedule specifically for your Full backups has behaved normally since the previous time change up until this past weekend, I'm not sure how to account for that.  Sorry!

Either way, appreciate the input and the assist.  Thanks
By donald24 - 5 March 2019 9:28 PM

But Macrium must be aware of this bug, and still do nothing about it. If this is fixed through a simple recreation of the schedule, then why the heck is this not automated by the Reflect-service?

Don't they know, don't they care? For a company selling this product for productive servers.. well I won't complete this sentence...

At home only I have 12 schedules to recreate after a DST-change, reminds me of turning the wheel back and forth of each non-intelligent watch... Come on Macrium, even when M$ will ever fix that bug, it would be a really good idea to recreate schedules after DST occures automatically. Is this rocket-science?
Somebody from the team reading here?
By Drac144 - 6 March 2019 9:59 PM

I understand that there is a lot of frustration regarding the issue.  And I understand that since Macrium took the easy (?) way out and decided to use the Windows scheduler to run timed backups, they should have SOME responsibility to make sure that feature works.  However, I have used Reflect for many years and have never experienced the problem.  So this is not some hard bug - that can easily be found and fixed.  It seems to only occur on some (and I am guessing only a few) systems.  If Macrium cannot reproduce the bug, it makes it a lot harder to figure out what the problem is and what to do about it.  

If you can offer a scenario that works - and it is something that Macrium can add to Reflect or can supply as a standalone process (like recreate all definition files or remove and re-register all scheduled tasks used by Reflect) then that would seem to be a fair request.  Is that the case here?  Is there a specific fix that works all the time and fixes the issue?  If not, what is Reflect supposed to do - other than find an alternate way to implement scheduled tasks?  They could have one entry in the Windows scheduled task manager and get control once a minute and then check all reflect tasks to see if any need to be started.  I am not sure how hard that would be (I am thinking not very hard) but is it worth making that change unless a large number of people are having the issue?  

I don't believe it is a matter of whether Macrium cares or not.  They are a company and they are in business to make money and as such they need to make good business decisions.  Trying to chase down elusive bugs in other company's software or even trying to create workarounds for them could be a waste of time better used to improve Reflect for all users. 

Have you tried to see what is going on within your system that is different than systems of other users that do not experience the issue?  That may yield a better outcome than hoping Macrium can or will try to find a solution.
By dbminter - 6 March 2019 10:12 PM

Plus, the problem isn't Macrium's to fix.  Microsoft is at fault with this issue.  They need to fix it because it's been in Windows for years and affects scheduled tasks beyond Reflect's.
By BobUlius - 6 March 2019 10:17 PM

Drac144 - 6 March 2019 9:59 PM
I understand that there is a lot of frustration regarding the issue.  And I understand that since Macrium took the easy (?) way out and decided to use the Windows scheduler to run timed backups, they should have SOME responsibility to make sure that feature works.  However, I have used Reflect for many years and have never experienced the problem.  So this is not some hard bug - that can easily be found and fixed.  It seems to only occur on some (and I am guessing only a few) systems.  If Macrium cannot reproduce the bug, it makes it a lot harder to figure out what the problem is and what to do about it.  

If you can offer a scenario that works - and it is something that Macrium can add to Reflect or can supply as a standalone process (like recreate all definition files or remove and re-register all scheduled tasks used by Reflect) then that would seem to be a fair request.  Is that the case here?  Is there a specific fix that works all the time and fixes the issue?  If not, what is Reflect supposed to do - other than find an alternate way to implement scheduled tasks?  They could have one entry in the Windows scheduled task manager and get control once a minute and then check all reflect tasks to see if any need to be started.  I am not sure how hard that would be (I am thinking not very hard) but is it worth making that change unless a large number of people are having the issue?  

I don't believe it is a matter of whether Macrium cares or not.  They are a company and they are in business to make money and as such they need to make good business decisions.  Trying to chase down elusive bugs in other company's software or even trying to create workarounds for them could be a waste of time better used to improve Reflect for all users. 

Have you tried to see what is going on within your system that is different than systems of other users that do not experience the issue?  That may yield a better outcome than hoping Macrium can or will try to find a solution.


I'm the topic starter. Its been a bit, but I recall sending logs and confirming this bug with Macrium, not "if Macrium cannot reproduce the bug, it makes it a lot harder to figure out what the problem is and what to do about it. "

How would you know how many people have this issue?

And the fact that you do not have the issue does not make it any less of a bug. It may and may never get fixed, but it IS a bug.

~Bob
By donald24 - 6 March 2019 10:45 PM

dbminter - 6 March 2019 10:12 PM
Plus, the problem isn't Macrium's to fix.  Microsoft is at fault with this issue.  They need to fix it because it's been in Windows for years and affects scheduled tasks beyond Reflect's.

No, we all know whose fault it is. But if you build a house on "uncertain ground" and sell it, it is going to be your problem, when the owner complains that the structure shifts.
The solution that a company sells should work as advertised, you cannot simply put the blame on a company, that their subfunctions don't work. That would be too easy, and every trial between customer and Macrium would be won.
We've already talked about a possible workaround, why not just implement it? Even moreso, it's an easy fix code-wise....
By dbminter - 6 March 2019 10:51 PM

BTW, what exactly is the possible workaround?  I'd like to know since DST is coming up this Sunday, I think, for me.  I'd like to know to see if I can implement it myself instead of deleting and recreating the jobs.


Thanks!
By jphughan - 6 March 2019 11:00 PM

Given how disruptive it can be for people affected by it, especially the version that causes all subsequent executions of the task to fail after a DST change, this bug would almost HAVE to be very rare even among all users of Windows for it to have persisted across this many major releases of Windows without a fix from Microsoft. And as useful as Reflect is, I don’t think it’s unreasonable to assume that only a small percentage of all Windows installations have Reflect installed and set up for scheduled backups, so the number of people affected by this issue who are also Reflect users would seem to be quite small.

As for mitigations, I can see both sides of the responsibility argument, in that it’s Microsoft’s bug to fix, but Macrium decided to tie a core function of their application to this Microsoft component. But even setting that question of whether Macrium SHOULD take responsibility for fixing this aside, I wonder whether having a service “reset” scheduled Reflect tasks in the background might end up more often creating NEW problems for people who didn’t previously have them than fixing this problem for the people who are experiencing it, which obviously would not be a net benefit. I also seem to recall Macrium talking about working on implementing their own scheduler engine, but a) that’s more work, and b) it’s not even a given that that would be better. I remember back when I had a client using Symantec Backup Exec, which used its own scheduler service, I had a calendar reminder to bounce all of that application’s services after every DST change because....the backups would always fail after that change and continue to fail until that was done. Symantec even had a KB article about this issue with that recommended as the “fix”.
By dbminter - 6 March 2019 11:13 PM

I admit, I've kind of wished Reflect had its own backup service.  I'm so sick of Task Scheduler failing at the drop of a hat to run tasks, either because of DST changes or importing XML's set to to run a Monthly schedule.


To be honest, I've pretty said sc*** Task Scheduler and use my e-mail's scheduler function to send me monthly e-mails as reminders for monthly tasks.  Then, I just execute them manually.  Hence why I've got shortcuts to all my Reflect XML jobs.  I created shortcuts in a dedicated Start Menu folder to access them all in one convenient place.
By BobUlius - 7 March 2019 12:38 AM

donald24 - 6 March 2019 10:45 PM
dbminter - 6 March 2019 10:12 PM
Plus, the problem isn't Macrium's to fix.  Microsoft is at fault with this issue.  They need to fix it because it's been in Windows for years and affects scheduled tasks beyond Reflect's.

No, we all know whose fault it is. But if you build a house on "uncertain ground" and sell it, it is going to be your problem, when the owner complains that the structure shifts.

Actually, no we don't. I have other tasks that run monthly None have ever run twice after a time change other than Reflect. On two computers with two operating systems.
By Drac144 - 7 March 2019 9:05 PM

BobUlius,

I "know" that this is not a bug affecting a lot of users based on the response to this thread as well as a lack of continued complaints about this issue (or I should rightly say continued complaints by many different users). 

I never suggested that just because the problem did not affect me it is not a real bug.  In another thread from today a user pointed out that the error (bug) they were experiencing was due to using a non-default location for their Reflect installation.  When Macrium tried to reproduce the bug they could not because they installed reflect to the default location.  I DID suggest that if Macrium could not reproduce the bug they might have a difficult time fixing it - ESPECIALLY since (in this case) software from a 3rd party is involved - and in this case a 3rd party known for their poor response to user complaints: Microsoft.

Macrium could write their own scheduling which would probably have bugs of its own for a while (no offense intended toward Macrium - just a reality of software development). and take a lot of effort away from Backup related features.  However, like the thread mentioned above, when the OP figured out why the error was occurring and informed Macrium, I suspect it insured a quick fix to the issue.  That is why I suggested to you that if you could figure out why my system works and yours (and others) does not, that could go a long way towards getting the issue fixed (or at least a workaround developed).  It is NOT your job to do this.  But if you have the time AND expertise to experiment, you could get the problem resolved.  

I am not in a position to volunteer JP's time but with someone like him as a resource and a few other users that do and do not have the issue, maybe we can work together to figure out what the differences are.
By dbminter - 9 March 2019 12:54 AM

I don't know if it was in this thread, but I think I read somewhere someone positing that disabling Synchronize across time zones would fix this DST problem.  I can say with somewhat certainty it probably doesn't because I checked my Task Scheduler backup tasks for Reflect jobs as well as others and Synchronize across time zones was unchecked on all of them.  Unless of course the solution was to ENABLE it.  Then, I can't say if that might work or not.  Wink
By donald24 - 7 April 2019 9:16 PM

Welcome people to a new summer-time DST!!

Here is my first occurence of a full monthly backup was not running with following error:
Task Scheduler The operator or administrator has refused the request (0x800710E0)

This is on Win10 1809, but should be the same on every Windows ver. Manual run then went without problems afterwards.

I did not recreate the task after DST-change, but in Q1 when we discussed about it. I think Macrium should take DST problems in their hands and program tasks independendly of M$ flaws with the already discussed option of the task. You should be able to rely on your backup tasks for gods-sake!
By dbminter - 7 April 2019 9:36 PM

Yes, my Monthly scheduled tasks stopped working, too, and will always stop working because M$ won't address this bug.  I think before Version 2 of Task Scheduler, there wasn't this problem.  So, some versions of Windows 10 DID work.  M$ did mess up Task Scheduler so much when releasing Version 2 that Reflect scheduled tasks ALL broke.  Regardless of the schedule.


So, what I ended up doing was queuing an e-mail sent to me on a Monthly basis to tell me to run the Reflect shortcuts manually.


I have already put it in the Wish List for Macrium to develop its own task scheduler service to get around this idiocy.


Actually, I think there IS a fix for this, but it's drastic.  Whenever new Windows 10 refresh versions are installed, I think they fix this issue.  So, it may be possible, if the installer allows it to "update" your current Windows 10 to its current version again.
By jphughan - 7 April 2019 11:02 PM

Dbminter, I believe someone said that ENABLING “Synchronize across time zones” avoids this issue since it’s disabled by default, as you found. The problem with that workaround is that it will cause your tasks to shift by an hour during DST. So for example if you have a task that runs at 5PM during standard time, when the clock moves an hour forward for DST, your task will run at 6PM. Evidently that’s what synchronizing across time zones means, since the result is that your task runs at a consistent time according in GMT regardless of clock variations in your particular time zone.
By BobUlius - 7 April 2019 11:47 PM



Interesting. I did not even think about this until the email of new posts on this topic. Everything ran as expected on 4/1. And I run TWO full backups to different drives that morning. So for me, it seems the Spring Ahead works as expected, but perhaps not the Fall Back? Won't know until December.

~Bob
By dbminter - 7 April 2019 11:54 PM

jphughan - 7 April 2019 11:02 PM
Dbminter, I believe someone said that ENABLING “Synchronize across time zones” avoids this issue since it’s disabled by default, as you found. The problem with that workaround is that it will cause your tasks to shift by an hour during DST. So for example if you have a task that runs at 5PM during standard time, when the clock moves an hour forward for DST, your task will run at 6PM. Evidently that’s what synchronizing across time zones means, since the result is that your task runs at a consistent time according in GMT regardless of clock variations in your particular time zone.

I enabled Synchronize Across Time Zones for my Day 14 backup scheduled task.  As it stands now, Day 14's backup won't run on its own.  I'll see if it runs on the 14th, even if it runs an hour off.  I'm just interested to see if it runs at all.


Well, what do you know?  It actually did work!  Smile  Day 14 not only ran, it ran on its scheduled time.  Of course, when the DST occurs, it might be problematic in that the scheduled time it runs might be an hour off, as jphughan said.
By MichaelP - 8 May 2019 12:22 PM

jphughan - 2 December 2018 8:19 PM
Do you happen to live in an area that switched between Daylight Savings and Standard Time this past weekend?  Or more precisely, is your system set to a time zone where that would have occurred?  If not, open Windows Task Scheduler, find the scheduled task that corresponds to running Full backups for this job, select it, and check the History tab.  If it's marked as disabled, which it is on default Windows installations, then there won't be anything useful there.  But if not, it may take a while to populate, but after it does, is there anything useful in there?

I have been struggling to get a grip on error code 0x800710e0 which sometimes occurs when I try to run a monthly scheduled full file and folder backup in Macrium Reflect v.7.2. When I amend the backup file to run a little later in the day after I noticed the error, the task completes successfully.
What is strange is that I do not recall seeing this behaviour with the monthly full image backup. I begin to suspect that this is due to there being weekly incremental image backups which "sort things out" before the next monthly full image backup.
It would be an enormous coincidence if this error were not related to the change to daylight saving time. Last year the problem also occurred in April, i.e. after the time change in March.
Macrium support are very unhelpful with their suggestions of what to do. One suggestion is to change the account from SYSTEM to a user account with administrative privileges. I told them I was not persuaded by that suggestion but I think I can now see why this would SEEM to work because the backup definition file will be rebuilt. I am disappointed that Macrium may not be aware of the subject of this post. The very least they could do is to point people who have this problem to it. I reluctantly agree that it is not Macrium's responsibility to fix this problem in Task Scheduler - if that is where it is.
Thank you, JPHUGHAN, for having come up with this.
By jphughan - 8 May 2019 2:15 PM

It's not the definition file that would "need" to be rebuilt, but rather the scheduled tasks that call that definition file.  Changing the user account that Reflect uses for background tasks does indeed cause it to go through and modify (maybe delete and recreate?) any existing scheduled task to use those new credentials.  You would NOT need to go through and recreate your entire definition file, which includes the other settings you want to use for the job, e.g. what data to back up, the destination, encryption/compressio, retention policy, etc.
By MichaelP - 9 May 2019 10:23 AM

jphughan - 8 May 2019 2:15 PM
It's not the definition file that would "need" to be rebuilt, but rather the scheduled tasks that call that definition file.  Changing the user account that Reflect uses for background tasks does indeed cause it to go through and modify (maybe delete and recreate?) any existing scheduled task to use those new credentials.  You would NOT need to go through and recreate your entire definition file, which includes the other settings you want to use for the job, e.g. what data to back up, the destination, encryption/compressio, retention policy, etc.


Thank you for that. What you say makes sense. But at the same time it is noteworthy that just changing the scheduled time in the definition file enabled the backup, scheduled to run a little later in the day, to run successfully. So, there too, seems to be some "rebuild" going on. Unfortunately, the interface between Reflect and the Task Scheduler is a bit of a closed book.
I'll leave the account at SYSTEM (I believe this is the installation default in the latest version of Reflect) and see what happens with the next scheduled run on 03/06/2019. 
By BobUlius - 1 January 2020 11:33 PM

Hi folks and Happy New Year.

Guess what's back? Smile
One of my two scheduled monthly tasks has been running twice each month for at least the last two months. Makes sense as Daylight Time changed the month before. But this time it has done the same run twice for two months so does not fix itself the second month. And the other monthly backup on the same computer but to a different destination only runs once.

Have we learned anything that can fix this since last posts?

Thanks.

~Bob

By dbminter - 1 January 2020 11:36 PM

Yes, if you haven't, try editing your task(s) in Task Scheduler and enable Synchronize across time zones.  It's what's always fixed my problems with double running tasks.
By BobUlius - 1 January 2020 11:45 PM

BTW, i was going to try "synchronize across time zones" but cannot find that setting anywhere in the definition file or task scheduler. Is that really the fix? And where might it be?

~Bob
By dbminter - 2 January 2020 12:04 AM

Open Task Manager.  Double click on a task that is running twice.  Select the Triggers tab.  Select Edit at the bottom.  At the end of the Start line is a box you can check that says Synchronize across time zones.  Check that box.  Select OK.
By BobUlius - 2 January 2020 12:23 AM

dbminter - 2 January 2020 12:04 AM
Open Task Manager.  Double click on a task that is running twice.  Select the Triggers tab.  Select Edit at the bottom.  At the end of the Start line is a box you can check that says Synchronize across time zones.  Check that box.  Select OK.


Thanks! Just could not find that. Now checked.

Is that really the valid fix for this issue. Have others found it to work?

Last time this happened in the spring, it ran twice one month after time change, then once a month after until this November time change. SO a little different than it was for me.
By dbminter - 2 January 2020 12:29 AM

I found that it worked after someone else posted on here it worked for them.  I was skeptical, too, but I tried it, willing to try anything rather than delete and recreate scheduled tasks, and, to my complete surprise, it did work.


What used to work, as I said, was deleting the old scheduled backup and recreating it.  But, it only works until the next DST change, when the issue returns.  And you must delete the scheduled backups and recreate them again.  So, that works, too, but as you can tell, is a pain to have to do.
By BobUlius - 2 January 2020 1:55 AM

dbminter - 2 January 2020 12:29 AM
I found that it worked after someone else posted on here it worked for them.  I was skeptical, too, but I tried it, willing to try anything rather than delete and recreate scheduled tasks, and, to my complete surprise, it did work.


What used to work, as I said, was deleting the old scheduled backup and recreating it.  But, it only works until the next DST change, when the issue returns.  And you must delete the scheduled backups and recreate them again.  So, that works, too, but as you can tell, is a pain to have to do.

Cool. I won't know until Feb 1, but agree that creating another scheduled backup is not my chosen way to go.
What happens with this checked and time changes? Does a 5AM schedule then run at 4 AM or 6 AM? Or does it stay at 5 AM?

Surprised Macrium hasn't implemented a fix. I was suprised to see this back again.

And thanks for the replies. Much appreciated.
By dbminter - 2 January 2020 2:00 AM

When I enabled Synchronize, one task runs at the scheduled time and no other times.


Macrium can't implement a fix because it's been a bug in Microsoft's Task Scheduler for years.  Microsoft refuses to address it, so there's nothing Macrium can do.


Although, Macrium has said they do plan on implementing their own task scheduler service at some point in the future to handle scheduled jobs.  No ETA on that feature, though.  I can't wait for it to be implemented, though, as long as it's implemented right.  With the ability to export and import jobs like Task Scheduler can.
By BobUlius - 2 January 2020 2:21 AM

So let me ask then....

I have maybe 4 other tasks for Macrium in task scheduler but no others run twice. Should I enable sync for those even though they work as expected? Preventive maintenance?


By dbminter - 2 January 2020 2:45 AM

Good question.  I checked some of my tasks and not all of my Macrium tasks have Synchronize enabled.  I only enabled it on those specific tasks that were running twice.  Since the issue appears to be random and doesn't affect all tasks, I'd just edit those tasks that are running twice.  Although, I can't foresee a problem enabling it on all of them.  But, there's also that old adage: "if it ain't broke, don't fix it."
By BobUlius - 2 January 2020 3:36 AM

OK, see ya back here on Feb 1st Smile Hopefully with good news.

Thanks for all the advice.
By BobUlius - 1 February 2020 3:08 PM

Welcome to Feb 1st. Long month waiting to see what happened. Ran twice. But please look at the following carefully to see what it did. And note, of the three scheduled actions for 5:00 AM (monthy, Monday, Daily) the only one set to synch across time zones is the monthly full. But I do not think that is the issue, but it might be.

Here is my folder yesterday:

This is today:

And here is the backup plan:



See anything of interest? What shall I try for March? Smile
Thanks.

~Bob
By MichaelP - 2 February 2020 1:08 PM

BobUlius - 1 February 2020 3:08 PM
Welcome to Feb 1st. Long month waiting to see what happened. Ran twice. But please look at the following carefully to see what it did. And note, of the three scheduled actions for 5:00 AM (monthy, Monday, Daily) the only one set to synch across time zones is the monthly full. But I do not think that is the issue, but it might be.

Here is my folder yesterday:

This is today:

And here is the backup plan:



See anything of interest? What shall I try for March? Smile
Thanks.

~Bob

Hi, I'd just like to point out that it is possible in Macrium to copy definition files for backup and restore purposes. Perhaps this facility can be used to back up pre and post date changed versions. Regards, Michael
By BobUlius - 2 February 2020 2:02 PM

Thanks Michael. Not quite sure what that would do for me?

Let me add to the puzzle:

I have 2 definition files that are VERY similar but not matching. one backs up to an external drive, one to a NAS. The external drive runs twice for FULL on the 1st. The NAS never runs twice. Simplified, this is what they look like:
External:                                  NAS
Full 1:00 AM 1st                       4:00 AM 1st
Diff 1:00 AM Every Sunday        5:00 AM Every Monday
Incr 1:00 AM Every Day             5:00 AM Every Day

BOTH:
Retain     3 Full
              4 weeks Diff
             15 days Incr   
Could these simple difference make the difference why one runs twice? And the one that runs twice is the one synced over time zones.

Thanks!

By dbminter - 2 February 2020 4:15 PM

Wasn't the reason you set synchronize across time zones to begin with was because it was running twice already?
By BobUlius - 2 February 2020 4:40 PM

dbminter - 2 February 2020 4:15 PM
Wasn't the reason you set synchronize across time zones to begin with was because it was running twice already?


Exactly. And it seems it did not work. This is the first test since that was recommended and implemented.
By dbminter - 2 February 2020 5:49 PM

Then, you can probably rule out it was the synchronizing across time zones that did it, as you questioned earlier, since it was already doing it before.  It is most likely just coincidence that your other two jobs to NAS aren't affected and your external drive is.  This issue occurs randomly, for apparently no known reason.  Like why Task Scheduler decided to Disable HALF of my scheduled Monthly backup tasks recently and I only just discovered this yesterday..
By BobUlius - 2 February 2020 7:00 PM

dbminter - 2 February 2020 5:49 PM
Then, you can probably rule out it was the synchronizing across time zones that did it, as you questioned earlier, since it was already doing it before.  It is most likely just coincidence that your other two jobs to NAS aren't affected and your external drive is.  This issue occurs randomly, for apparently no known reason.  Like why Task Scheduler decided to Disable HALF of my scheduled Monthly backup tasks recently and I only just discovered this yesterday..


Hah!

I went ahead and changed the Full at 4:00 AM to 5:00 AM so both Definitions are identical except for time of day and drive. Doubt that is it and hope all of the above helps someone to say., AHA, its this....Not even sure if deleting the definition file and recreating would help or make things worse.
By MichaelP - 2 February 2020 8:17 PM

BobUlius - 2 February 2020 2:02 PM
Thanks Michael. Not quite sure what that would do for me?

Let me add to the puzzle:

I have 2 definition files that are VERY similar but not matching. one backs up to an external drive, one to a NAS. The external drive runs twice for FULL on the 1st. The NAS never runs twice. Simplified, this is what they look like:
External:                                  NAS
Full 1:00 AM 1st                       4:00 AM 1st
Diff 1:00 AM Every Sunday        5:00 AM Every Monday
Incr 1:00 AM Every Day             5:00 AM Every Day

BOTH:
Retain     3 Full
              4 weeks Diff
             15 days Incr   
Could these simple difference make the difference why one runs twice? And the one that runs twice is the one synced over time zones.

Thanks!


Sorry to be obtuse. I misunderstood. Not having read the thread very carefully I inferred there may be versions for before and after time change and that changing them was a bit of bother. Having a copy of each version to be restored from backup seemed to make life easier.
Incidentally, I use the facility to copy between computers requiring me to make very few changes.
Good luck with your endeavours.
Best regards, Michael
By BobUlius - 4 February 2020 1:38 AM

Tried to create a ticket but that interface does not seem to be working. Nowhere to enter the issue, When I replied to my ticket, the text was white on white! Curious.

That being said, can the resident experts comment on what might be going on with this continuing issue and how best to solve it?

Thanks!
By MichaelP - 4 February 2020 10:57 AM

jphughan - 2 December 2018 8:50 PM
There are a few threads here and in other forums that have nothing to do with Reflect about scheduled tasks behaving oddly after a time change.  In some cases, the anomalous behavior manifests as an unexpected additional occurrence an hour after the normal occurrence, after which the scheduled task continues as normal.  In other cases, the scheduled task completely fails to run and throws some error code, and that persists until the scheduled task is deleted and recreated (or perhaps modifying it is enough, I can't remember).  Both appear to be bugs in Windows Task Scheduler that have existed for many years and persist into the latest versions of Windows -- unless the recent Win10 1809 has finally solved this, although I'm not holding my breath.  The fact that this was the first time that particular scheduled task was executed since your time change is almost certainly NOT a coincidence, and since your behavior is the "unexpected extra occurrence" variation, things should carry on as normal going forward without you having to do anything.

Side note: The other behavior I described, where the scheduled task completely fails, is a perfect example of why I strongly recommend that people who use email notifications enable them for both failures AND successes.  Many people only enable them for failures, but the problem with that strategy is that you won't know if LACK of emails means that everything is going fine or nothing is happening at all.  In this particular bug, since the error in question occurs at a Windows Task Scheduler level, Reflect never even launches, which means that it would never generate a failure email notification about the problem.  On a server that is typically unattended (i.e. people aren't logging onto it on a regular basis), if the administrator has configured Reflect to only send failure notifications, this bug could cause that server to go quite some time with no backups being generated and nobody realizing there was a problem!

This is interesting. I have noticed double runs too. This was months ago so I can't remember details. Then the problem went away. I'm pretty sure that, in order to leave no stone unturned, I have reconstructed my definition files. What is also interesting is that I notice different behaviour (and this is ongoing) between my Samsung laptop and my Microsoft Surface Pro 3. I have raised that in Windows and Surface forums. Particularly odd is the Windows 10 (Windows 7) backup - Microsoft's own software - on the Surface follows the same behaviour as Reflect.
I have come across a Task Scheduler help document running to over 1,200 pages, mainly coding examples. This is dated January 2020, so perhaps Microsoft are working on the Task Scheduler problems people experience.
By MichaelP - 4 February 2020 11:13 AM

jphughan - 6 March 2019 11:00 PM
Given how disruptive it can be for people affected by it, especially the version that causes all subsequent executions of the task to fail after a DST change, this bug would almost HAVE to be very rare even among all users of Windows for it to have persisted across this many major releases of Windows without a fix from Microsoft. And as useful as Reflect is, I don’t think it’s unreasonable to assume that only a small percentage of all Windows installations have Reflect installed and set up for scheduled backups, so the number of people affected by this issue who are also Reflect users would seem to be quite small.

As for mitigations, I can see both sides of the responsibility argument, in that it’s Microsoft’s bug to fix, but Macrium decided to tie a core function of their application to this Microsoft component. But even setting that question of whether Macrium SHOULD take responsibility for fixing this aside, I wonder whether having a service “reset” scheduled Reflect tasks in the background might end up more often creating NEW problems for people who didn’t previously have them than fixing this problem for the people who are experiencing it, which obviously would not be a net benefit. I also seem to recall Macrium talking about working on implementing their own scheduler engine, but a) that’s more work, and b) it’s not even a given that that would be better. I remember back when I had a client using Symantec Backup Exec, which used its own scheduler service, I had a calendar reminder to bounce all of that application’s services after every DST change because....the backups would always fail after that change and continue to fail until that was done. Symantec even had a KB article about this issue with that recommended as the “fix”.

It may be worth repeating here that I have differences in behaviour between my Samsung laptop and my Microsoft Surface Pro 3 which are both running on the latest version of Windows 10 (OS build 18363.628). On the Surface the Windows 10 (Windows 7) backup fails to run as scheduled at 4 a.m. on Sundays; similarly for Reflect at 9 a.m. Theyt only start together (!) when I log in. I have raised this in Windows and Surface forums.
By BobUlius - 4 February 2020 2:29 PM

Thanks Michael. For more info, this started in 2018 when the time changed. Was then fixed and working fine again until Nov 2019 (perhaps Dec 2019) This time continues every month since.So something different this time around the same issue.