New issue - running a scheduled full backup ran twice


Author
Message
BobUlius
BobUlius
Junior Member
Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)
Group: Forum Members
Posts: 48, Visits: 52
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.

Edited 7 March 2019 12:47 AM by BobUlius
Drac144
Drac144
Expert
Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)Expert (812 reputation)
Group: Forum Members
Posts: 537, Visits: 2K
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.

dbminter
dbminter
Master
Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)
Group: Forum Members
Posts: 1.2K, Visits: 12K
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

Edited 9 March 2019 12:54 AM by dbminter
donald24
donald24
New Member
New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)New Member (30 reputation)
Group: Forum Members
Posts: 20, Visits: 102
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!
dbminter
dbminter
Master
Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)
Group: Forum Members
Posts: 1.2K, Visits: 12K
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.

Edited 7 April 2019 9:38 PM by dbminter
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
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.
Edited 7 April 2019 11:03 PM by jphughan
BobUlius
BobUlius
Junior Member
Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)Junior Member (53 reputation)
Group: Forum Members
Posts: 48, Visits: 52


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

dbminter
dbminter
Master
Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)Master (1.6K reputation)
Group: Forum Members
Posts: 1.2K, Visits: 12K
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.
Edited 14 April 2019 3:10 PM by dbminter
MichaelP
MichaelP
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 16
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.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)Macrium Evangelist (8.9K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
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.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search