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

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
History has taught me it will happen again on the next DST time change.

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
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?
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
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.
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
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.
Edited 3 March 2019 2:34 PM by jphughan
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
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.
cousinit99
cousinit99
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 9, Visits: 34
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?

  

  

  
Edited 5 March 2019 7:37 PM by cousinit99
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
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.

Edited 5 March 2019 7:38 PM by jphughan
cousinit99
cousinit99
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 9, Visits: 34
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...
Edited 5 March 2019 7:59 PM by cousinit99
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
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!

Edited 5 March 2019 8:37 PM by jphughan
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