v.7 on Win 10 Pro. 
Occasionally, my backup will create 2 files during the backup run, for example, this morning. These are not large files so wondering why.
Log Sample for our OS Drive C::
2/23/21 1:05 AM  Disk partition image, Inc backup   2,715,950KB
2/23/21 1:01 AM  Disk partition image,  Inc backup    730,588KB 

Log Sample for our DATA Drive E:
2/23/21 3:01 AM Disk partition image, Inc backup  15,046KB
2/23/21 3:01 AM Disk partition image, Inc backup  18,614KB

Usually, these nightly backups create only 1 file but it happens randomly and makes 2 files.
Any ideas?:  Please advise.
John D.

Those lines you posted didn't come from an actual Reflect job log.  Are the timestamps you posted the Date Modified timestamps asshown in Windows?  If so, then what you're seeing is probably the result of Incremental consolidation.  In that case, the Date Modified timestamp of the backup will not correspond to the "backup date", i.e. the date of the data that it contains.  If you check the log of whatever job ran at approximately 2/23/31 at 3 AM, at the top or bottom of the log (depending on whether you have "Run purge before backup" enabled or disabled), you will likely see a reference to consolidation.  That operation is necessary to enforce an Incremental retention policy since older Incrementals can't simply be deleted, since that would invalidate all subsequent Incrementals in the chain.  So instead, the oldest Incrementals are consolidated so that old Incrementals can be purged without breaking the chain.  But that consolidation operation counts as a file change as far as Windows is concerned, so in that situation you end up with the remaining consolidated having a Date Modified timestamp corresponding to the time of the consolidation -- along with a backup that was in fact created at that time.

So you didn't get two new backups.  You got one new backup, plus a consolidation of old backups.

As a tip, when using backup strategies like this, it's much easier to look at your backups within Reflect itself, under the Restore tab.  That will allow you to view and sort by the actual Backup Date.

+x

 

jphughan - 23 February 2021 9:54 PM

Those lines you posted didn't come from an actual Reflect job log.  Are the timestamps you posted the Date Modified timestamps asshown in Windows?  If so, then what you're seeing is probably the result of Incremental consolidation.  In that case, the Date Modified timestamp of the backup will not correspond to the "backup date", i.e. the date of the data that it contains.  If you check the log of whatever job ran at approximately 2/23/31 at 3 AM, at the top or bottom of the log (depending on whether you have "Run purge before backup" enabled or disabled), you will likely see a reference to consolidation.  That operation is necessary to enforce an Incremental retention policy since older Incrementals can't simply be deleted, since that would invalidate all subsequent Incrementals in the chain.  So instead, the oldest Incrementals are consolidated so that old Incrementals can be purged without breaking the chain.  But that consolidation operation counts as a file change as far as Windows is concerned, so in that situation you end up with the remaining consolidated having a Date Modified timestamp corresponding to the time of the consolidation -- along with a backup that was in fact created at that time.

So you didn't get two new backups.  You got one new backup, plus a consolidation of old backups.

As a tip, when using backup strategies like this, it's much easier to look at your backups within Reflect itself, under the Restore tab.  That will allow you to view and sort by the actual Backup Date.

+x

 

jphughan - 23 February 2021 9:54 PM

Those lines you posted didn't come from an actual Reflect job log.  Are the timestamps you posted the Date Modified timestamps asshown in Windows?  If so, then what you're seeing is probably the result of Incremental consolidation.  In that case, the Date Modified timestamp of the backup will not correspond to the "backup date", i.e. the date of the data that it contains.  If you check the log of whatever job ran at approximately 2/23/31 at 3 AM, at the top or bottom of the log (depending on whether you have "Run purge before backup" enabled or disabled), you will likely see a reference to consolidation.  That operation is necessary to enforce an Incremental retention policy since older Incrementals can't simply be deleted, since that would invalidate all subsequent Incrementals in the chain.  So instead, the oldest Incrementals are consolidated so that old Incrementals can be purged without breaking the chain.  But that consolidation operation counts as a file change as far as Windows is concerned, so in that situation you end up with the remaining consolidated having a Date Modified timestamp corresponding to the time of the consolidation -- along with a backup that was in fact created at that time.

So you didn't get two new backups.  You got one new backup, plus a consolidation of old backups.

As a tip, when using backup strategies like this, it's much easier to look at your backups within Reflect itself, under the Restore tab.  That will allow you to view and sort by the actual Backup Date.

You are absolutely correct.  What I posted was NOT coming from the Log but merely a list of the files on my mobile drive after the backup. My apologies.
Also, I do not enable purging before backup. I also need to read about consolidation.
 Having said all this, If that would change your reply I would appreciate your further explanation.
John D.

The question is whether you're using Incremental backups and have an Incremental retention policy applied (as opposed to having that option completely unchecked so that they would only get deleted when their parent Full or Differential gets deleted).  If both of those are true, then you'll see Incremental consolidation whenever the quantity or age of Incrementals at your destination exceeds your retention policy setting.  Macrium has a nice YouTube video showing how consolidation works here.  Each time the consolidation shown in the animation occurs, the remaining file will have its Date Modified timestamp updated to the time of the consolidation, which will not match the time of the backup data that it stores.  Note that the animation I linked shows the oldest two Incrementals being merged for consolidation.  There is another variation called "Synthetic Fulls" where the oldest Incremental is merged into the Full, thus "carrying it forward" in time rather than leaving it "frozen in time" as it appears in the video I linked.  The consolidation you're using will depend on your backup strategy and settings, and there are pros and cons to each approach, but the consolidation concept is the same.

+x

 

jphughan - 24 February 2021 1:55 AM

The question is whether you're using Incremental backups and have an Incremental retention policy applied (as opposed to having that option completely unchecked so that they would only get deleted when their parent Full or Differential gets deleted).  If both of those are true, then you'll see Incremental consolidation whenever the quantity or age of Incrementals at your destination exceeds your retention policy setting.  Macrium has a nice YouTube video showing how consolidation works here.  Each time the consolidation shown in the animation, the remaining file will have its Date Modified timestamp updated to the time of the consolidation, which will not match the time of the backup data that it stores.  Note that the animation I linked shows the oldest two Incrementals being merged for consolidation.  There is another variation called "Synthetic Fulls" where the oldest Incremental is merged into the Full, thus "carrying it forward" in time rather than leaving it "frozen in time" as it appears in the video I linked.  The consolidation you're using will depend on your backup strategy and settings, and there are pros and cons to each approach, but the consolidation concept is the same.

This and the video was very helpful.
Thanks much.