Macrium Support Forum

Double checking before making changes.

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

By BobUlius - 9 April 2021 9:50 PM

Hi folks, everything working well and as expected but I would like to make a few changes and checking in before I do to hopefully avoid any gotchas.

I have two backup definition files. One runs a 1:00 AM and one runs at 4:00 AM. I want to reverse those times.
Then, one has 3 retained files. I want to change it to 2.
Both started 3 years ago in the edit dialog. I assume I do not need to change that date?

And both have MANY files in their folders. I assume this change will continue on as if I had not made the changes and the incrementals and differentials will join the same folders files?

Thanks!

~Bob
By Froggie - 9 April 2021 10:40 PM

All should work well if you edit the DEF files/sched entries accordingly...
By jphughan - 9 April 2021 11:26 PM

You can certainly edit the schedule time and the retention policy without disrupting existing backups, and subsequent backups will continue to be created just as they've always been if those are the only things you're changing.  In terms of the 3 years ago date, I assume that means the start date on the schedule?  You don't have to change that.  There's nothing wrong with having a start date way in the past.  That typically comes into play either if you want to pre-stage a schedule to start later or if you have a schedule set to run every 2 weeks, for example, in which case the start date will determine which week is a backup week and which one is an "off week".
By BobUlius - 9 April 2021 11:46 PM

jphughan - 9 April 2021 11:26 PM
You can certainly edit the schedule time and the retention policy without disrupting existing backups, and subsequent backups will continue to be created just as they've always been if those are the only things you're changing.  In terms of the 3 years ago date, I assume that means the start date on the schedule?  You don't have to change that.  There's nothing wrong with having a start date way in the past.  That typically comes into play either if you want to pre-stage a schedule to start later or if you have a schedule set to run every 2 weeks, for example, in which case the start date will determine which week is a backup week and which one is an "off week".

Thanks. Exactly what I wanted to know. Seems like it should go smoothly.
By BobUlius - 9 April 2021 11:59 PM

BobUlius - 9 April 2021 11:46 PM
jphughan - 9 April 2021 11:26 PM
You can certainly edit the schedule time and the retention policy without disrupting existing backups, and subsequent backups will continue to be created just as they've always been if those are the only things you're changing.  In terms of the 3 years ago date, I assume that means the start date on the schedule?  You don't have to change that.  There's nothing wrong with having a start date way in the past.  That typically comes into play either if you want to pre-stage a schedule to start later or if you have a schedule set to run every 2 weeks, for example, in which case the start date will determine which week is a backup week and which one is an "off week".

Thanks. Exactly what I wanted to know. Seems like it should go smoothly.


Well, doing some odd things. I had one with 2 retained and one current data sets. I changed to 1 retain and changed the time to 1:00 AM. After saving it ran.Now a little before 5 PM. It deleted the two retained sets and now running a brand new full backup rather the an update to the exisitng set as incremental or differential.

I would have expected it to save one retained and run at a new time adding to the current set.
By jphughan - 10 April 2021 12:25 AM

When Reflect evaluates the retention policy, the current backup is counted.  This is mentioned in Reflect's documentation.  So for example if you have a retention policy to keep 1 Full backup and you have "Run purge before backup" enabled, then every time you create a new Full, Reflect will delete all existing backups before it even starts creating the new one.

If that doesn't completely account for the outcome you saw, then posting the job log of the backup that behaved unexpectedly would likely be helpful.  Make sure not to include your Reflect license key that's included at the bottom of the log.

If the issue is that you had a completely unexpected backup start immediately after you updated the schedule, I wonder if updating the schedule caused Reflect to believe that a bunch of backups had been missed since the start date and the current date.  If so, that sounds like a bug.  In that case, can you be as specific as possible in terms of what your schedule configuration was before you made any changes and what changes you made?  And then are you using Windows Task Scheduler or Macrium Task Scheduler?
By BobUlius - 10 April 2021 12:41 AM

jphughan - 10 April 2021 12:25 AM
When Reflect evaluates the retention policy, the current backup is counted.  This is mentioned in Reflect's documentation.  So for example if you have a retention policy to keep 1 Full backup and you have "Run purge before backup" enabled, then every time you create a new Full, Reflect will delete all existing backups before it even starts creating the new one.

If that doesn't completely account for the outcome you saw, then posting the job log of the backup that behaved unexpectedly would likely be helpful.  Make sure not to include your Reflect license key that's included at the bottom of the log.

If the issue is that you had a completely unexpected backup start immediately after you updated the schedule, I wonder if updating the schedule caused Reflect to believe that a bunch of backups had been missed since the start date and the current date.  If so, that sounds like a bug.  In that case, can you be as specific as possible in terms of what your schedule configuration was before you made any changes and what changes you made?  And then are you using Windows Task Scheduler or Macrium Task Scheduler?

OK, you are correct on the retained sets. But I did not expect a brand new set to be started after making the change so I would have had one reatined and a working set. Now the retained WAS my working set hours ago and an brand new fiull ran.

Yes that was a surprise. I was set for
a full 1:00 AM every 1st of month
a differential 1:00 AM Every Sunday
an incremental 1:00 AM every day

These all say and said starting 2/9/2018 (which is why I asked about the date)_
Aside from changing the retention, I changed all three above to 4:00 AM

I saved and a minute or two later it deleted two retained sets and started running a new full which is still in progress.

Might be a bug.


By BobUlius - 10 April 2021 12:46 AM

PROBLEM: Looking at the scheduled, the time for the one running is correct as the path. But  time and path are wrong for the other one changed that has not yet run.

I changed what I mentioned above in the Backup definition files. Did I need to do something else? Perhaps to the scheduler?
By jphughan - 10 April 2021 12:48 AM

Just to help me try to reproduce this and maybe narrow it down to the simplest possible trigger condition, what time was it where you are when you made that change?  And are you using Macrium Task Scheduler or Windows Task Scheduler?  You can check the latter by going to Edit Defaults > Schedule.  MTS is only available starting with Reflect 7.3.  If you're on an older release, you won't have an option and will therefore be using WTS.
By BobUlius - 10 April 2021 12:49 AM

MORE:

The top pane for the scheduler on that backup is correct.

Below that it says referenced File and the Image Options there are for the other backup - times and path.

So maybe it is ok. What is the Referenced File?
By jphughan - 10 April 2021 12:49 AM

BobUlius - 10 April 2021 12:46 AM
PROBLEM: Looking at the scheduled, the time for the one running is correct as the path. But  time and path are wrong for the other one changed that has not yet run.

I changed what I mentioned above in the Backup definition files. Did I need to do something else? Perhaps to the scheduler?

I'm not sure what "the other one" means in this context.  If you only edited schedules, then the path shouldn't have changed.  And you can't have different paths for different schedule types (Full/Diff/Inc) within the same definition file.
By BobUlius - 10 April 2021 12:50 AM

Got it. Clicking one of the backups in the Image changes the referenced file. Its ok there. WhewSmile

By jphughan - 10 April 2021 12:50 AM

BobUlius - 10 April 2021 12:49 AM
MORE:

The top pane for the scheduler on that backup is correct.

Below that it says referenced File and the Image Options there are for the other backup - times and path.

So maybe it is ok. What is the Referenced File?

Screenshots might help at this point....
By BobUlius - 10 April 2021 12:57 AM

No that is settled now, thanks. Did not know what Referenced File was or how it changed and it was showing a different set while I selected the name of the set. Changed to proper when Full or Incremental Or Differential was selected. All sorted.

So the  only surprise is that instant full backup. Art least for now. If that completes and I get my incremental to both at the new times tonight, should be good.
By jphughan - 10 April 2021 1:07 AM

Ok, but you still may have stumbled on a bug there.  If the schedule changes somehow caused Reflect to conclude that scheduled backups had been missed, then it would have run the "highest order" missed backup, which in this case would have been a Full.  That would explain a Full starting right after you made the changes. But since that shouldn't really happen in your scenario, I thought it might be worth trying to reproduce in a test environment.  That's why I asked what time it was where you were when you made the change, and also which scheduling engine you're using.  That might make it more likely I can make it happen on my end.
By BobUlius - 10 April 2021 1:22 AM

jphughan - 10 April 2021 1:07 AM
Ok, but you still may have stumbled on a bug there.  If the schedule changes somehow caused Reflect to conclude that scheduled backups had been missed, then it would have run the "highest order" missed backup, which in this case would have been a Full.  That would explain a Full starting right after you made the changes. But since that shouldn't really happen in your scenario, I thought it might be worth trying to reproduce in a test environment.  That's why I asked what time it was where you were when you made the change, and also which scheduling engine you're using.  That might make it more likely I can make it happen on my end.


OK. I changed from 1:00 AM to 4:00 AM and it was 4:52 PM when the full started.

As far as I know I am using the Macrium scheduler??? I know I had issues of 2 fulls after a daylight savings and I thought there was a change to your scheduler to avoid that. How would I check?

And agreed, seems like a small bug.
By BobUlius - 10 April 2021 1:23 AM

Found it. Macrium.

By jphughan - 10 April 2021 1:23 AM

Check Edit Defaults > Schedule to see which scheduler you're running.  EDIT: Saw your new post.  Ok, I'll see if I can trigger it myself.
By BobUlius - 10 April 2021 1:28 AM

jphughan - 10 April 2021 1:23 AM
Check Edit Defaults > Schedule to see which scheduler you're running.  EDIT: Saw your new post.  Ok, I'll see if I can trigger it myself.


Cool. Again, I changhed retention for 3 to 2 and time to a different run time 3 hours later  for all types of backup. I think the retention change was the culprit.