I have my boot disk scheduled to do a full backup on the first day of the month, and forever incrementals for every other other day of the month. It does that full backup on the first day just fine, but then the next night it does yet another complete full backup again, rather than doing an incremental. Any idea why it does this?

The full backup schedule is set to 12:00 AM on the first day of the month. And the incremental is scheduled for 12:01 AM every other day of the month.I give the incremental an extra minute to start so that if a full is scheduled it will run first rather than the incremental. The incremental should fail out due to a schedule conflict on the days that the full is run.

This started happening last month, and it has continued happening this month too.

Is your claim that another Full is running based on reviewing actual Reflect job logs, or just the Date Modified timestamps of your backups? If it’s the latter, an Incrementals Forever strategy involves consolidation, either between the two oldest Incrementals or between the oldest Incremental and the parent Full (if you have Synthetic Fulls enabled). Either way, whenever a backup that includes a consolidation operation occurs, you’ll end up with a new backup and then you will ALSO see the Date Modified timestamp of the file that was consolidated get updated.

If on the other hand you’re looking at actual Reflect job logs that are indicating Full backups at unexpected times, I experienced that behavior when I was using Windows Task Scheduler, and it was a bug in Windows Task Scheduler that affected Reflect. That was solved with Reflect 7.3 when Macrium introduced the option to use Macrium Task Scheduler. I switched Reflect over to that (Edit Defaults > Schedule) and haven’t had the problem since.

Lastly, in terms of your schedule, you’re making that unnecessarily complicated. If you want a Full each month and then an Incremental on all other days, then just set a monthly Full schedule and then an Incremental schedule to occur every day at the same time. Any time that multiple types of backups for the same job are scheduled at the same time, Reflect will only run the “highest order” backup and ignore the other(s), so an Incremental would be skipped to run a Differential, which would be skipped to run a Full. But if you set the Incremental to 12:01, that won’t happen. Just set a basic schedule for an Incremental every single day at 12 AM, and you won’t end up with an Incremental at all on days when a Full is also going to run. This behavior is covered in Reflect’s documentation.

+x

 

jphughan - 2 May 2021 5:49 AM

Is your claim that another Full is running based on reviewing actual Reflect job logs, or just the Date Modified timestamps of your backups? If it’s the latter, an Incrementals Forever strategy involves consolidation, either between the two oldest Incrementals or between the oldest Incremental and the parent Full (if you have Synthetic Fulls enabled). Either way, whenever a backup that includes a consolidation operation occurs, you’ll end up with a new backup and then you will ALSO see the Date Modified timestamp of the file that was consolidated get updated.

If on the other hand you’re looking at actual Reflect job logs that are indicating Full backups at unexpected times, I experienced that behavior when I was using Windows Task Scheduler, and it was a bug in Windows Task Scheduler that affected Reflect. That was solved with Reflect 7.3 when Macrium introduced the option to use Macrium Task Scheduler. I switched Reflect over to that (Edit Defaults > Schedule) and haven’t had the problem since.

Lastly, in terms of your schedule, you’re making that unnecessarily complicated. If you want a Full each month and then an Incremental on all other days, then just set a monthly Full schedule and then an Incremental schedule to occur every day at the same time. Any time that multiple types of backups for the same job are scheduled at the same time, Reflect will only run the “highest order” backup and ignore the other(s), so an Incremental would be skipped to run a Differential, which would be skipped to run a Full. But if you set the Incremental to 12:01, that won’t happen. Just set a basic schedule for an Incremental every single day at 12 AM, and you won’t end up with an Incremental at all on days when a Full is also going to run. This behavior is covered in Reflect’s documentation.

There is an actual full backup on the next day, as big as the previous day's full backup, I can actually see the file sitting there in the backup drive's folder. For example, I see one file named "DA22A3CA1E591CA1-00-00.mrimg" of about 100 GB, and the next day a new file called "F13E2C916EB30741-00-00.mrimg" also about 100 GB. And, yes they both show up in the Macrium logs too.

So I believe that I'm running into the same Windows task scheduler bug you ran into. Other than upgrading to Reflect 7, how do you work around the Windows task scheduler bug? Should I make them all 12:01 rather than 12:00 so that it gets a chance to fully skip across the midnight switchover properly?

In my own case, the bug behavior was that I started with a monthly Full schedule that ran on the first day of the month.  And then I ended up getting a Full on that day and also the last day of the previous month, i.e. a day earlier than expected.  So I switched the schedule to be the first Sunday of the month, wondering if that variation on a monthly schedule might make a difference.  And once again, I ended up getting a Full on the correct day, and also on the previous day.  I ended up having to switch my Full retention policy from being based on number of backups to being based on number of weeks, because that extra Full was causing an old set to be purged a month earlier than it should have been.  I never did find a way to prevent the unwanted Full from running in the first place, but since my backups were scheduled for 7 PM, I doubt the midnight timing is the issue in your case, and therefore I don't think altering it will fix it.  Issues like this, and especially odd behavior that could occur after DST switchovers -- including additional backups like this or sometimes no backups at all -- were a large part of what motivated Macrium to implement their own task scheduler into Reflect, since this was a case where a bug that wasn't Macrium's fault or within Macrium's power to fix was negatively affecting the experience of Macrium's customers.

The only workaround that MIGHT be effective would be to switch from a monthly schedule to a weekly schedule set to run only every 4 weeks.  Reflect supports this, and since our issues only ever occurred with monthly schedules, maybe switching to a weekly schedule will avoid this problem.  Of course every 4 weeks isn't precisely every month, but one of the virtues of that setup is that if you do decide to use time-based retention policies, Reflect only supports days and weeks for time anyway, not months, in which case using a weekly schedule will make it easier to align your retention policy to your schedule.  But apart from that, I'm afraid I don't have any better suggestions other than upgrading.  If it's any consolidation, Reflect V8 is expected quite soon, so you'll at least be making a bigger leap in exchange for upgrading.

I know back when I had DST issues with Reflect schedules on the Microsoft Task Scheduler, my weekly scheduled backups were always fine.  It was the ones set on a monthly schedule that wouldn't run properly.

I've always used a single 1am schedule & a backup scripted to check the date & run either full or incremental contingent on the date returned.
Works completely reliably, no problems with DST. 
The bug people run into becomes irrelevant, since it's not present with "every day" & the full/incremental decision is made within the script itself.

+x

 

jphughan - 2 May 2021 11:51 PM

In my own case, the bug behavior was that I started with a monthly Full schedule that ran on the first day of the month.  And then I ended up getting a Full on that day and also the last day of the previous month, i.e. a day earlier than expected.  So I switched the schedule to be the first Sunday of the month, wondering if that variation on a monthly schedule might make a difference.  And once again, I ended up getting a Full on the correct day, and also on the previous day.  I ended up having to switch my Full retention policy from being based on number of backups to being based on number of weeks, because that extra Full was causing an old set to be purged a month earlier than it should have been.  I never did find a way to prevent the unwanted Full from running in the first place, but since my backups were scheduled for 7 PM, I doubt the midnight timing is the issue in your case, and therefore I don't think altering it will fix it.  Issues like this, and especially odd behavior that could occur after DST switchovers -- including additional backups like this or sometimes no backups at all -- were a large part of what motivated Macrium to implement their own task scheduler into Reflect, since this was a case where a bug that wasn't Macrium's fault or within Macrium's power to fix was negatively affecting the experience of Macrium's customers.

The only workaround that MIGHT be effective would be to switch from a monthly schedule to a weekly schedule set to run only every 4 weeks.  Reflect supports this, and since our issues only ever occurred with monthly schedules, maybe switching to a weekly schedule will avoid this problem.  Of course every 4 weeks isn't precisely every month, but one of the virtues of that setup is that if you do decide to use time-based retention policies, Reflect only supports days and weeks for time anyway, not months, in which case using a weekly schedule will make it easier to align your retention policy to your schedule.  But apart from that, I'm afraid I don't have any better suggestions other than upgrading.  If it's any consolidation, Reflect V8 is expected quite soon, so you'll at least be making a bigger leap in exchange for upgrading.

It's the same situation here with me, but instead of getting a full backup on the first day and last day of the month, I'm getting one on the first day and the second day of the month. And the issue is also that I'm getting an older full backup being prematurely deleted. I have the rule set to keep 3 full backups for 3 full months, but once the 2nd full backup occurs in the same month, the oldest backup disappears.

This also only occurs on image backups rather and file/folder backups. Do the image vs. file/folder backups have a different scheduling system? I have a separate file/folder backup with the exact same retention and full/incremental switchover policies as the imaging backup set to run after the image backup runs, it's never had this problem.

You can't have a retention rule to keep "3 full backups for 3 full months".  You can either specify retention in terms of number of backups or quantity of time, not both.  Based on your description, it sounds like you have your retention policy set to 3 Full backups and a schedule set to perform monthly Fulls -- but Reflect does not take your schedule into account when evaluating the retention policy in order to figure out how long a Full is "supposed to" be kept based on your schedule and quantity of Fulls to retain.  If you have your retention set based on quantity of backups, that's all Reflect looks at.  But if you change your Full retention period to 12 Weeks, for example, then they won't be deleted early even if you get an extra Full -- assuming you don't trigger the low disk space threshold purge, assuming you've got that option enabled at all.

Image and F&F backups use the same scheduling engine, so if you've got the same schedules, I'm not sure how to account for the difference in behavior there.  But I'm also not sure what causes this problem in the first place when it occurs.