Macrium Support Forum

Scheduled F&F backup task sometimes tries to run image backup

By JK - 29 January 2022 1:21 AM

I'm still on v8.0.6161 (which may or may not be relevant), and I recently set up a scheduled intradaily File & Folder backup job, which has now been running for almost two weeks (daily differentials with intradaily incrementals every 15 min), mostly without issues. 

However, I've noticed on three separate occasions now, that the Scheduled Backups History shows a Task Ended with an 0x02 error, and a very interesting (and perplexing) log entry.  In the Logs view, these errors are associated with a failure in what is shown as a Full Image backup (whereas the definition file and schedules specify a Differential or Incremental File & Folder backup).  In addition, the Image Set ID shown for these failed tasks differs from the Image Set ID for the backup set that the scheduled task normally appends to.  The corresponding log files contain only the following information:

Image ID - 558922E79F802A19
Imaging Summary
Backup Definition File: D:\MyDocuments\Application Data\Reflect\MyIntradailyFF-v01.xml
XML Validation: Error - 'D:\MyDocuments\Application Data\Reflect\MyIntradailyFF-v01.xml' is not valid
Backup aborted! - XML validation error

Anybody seen anything like this before, or have any ideas?  Knowledgebase articles and past forum threads on XML validation errors do not appear to be relevant.
By jphughan - 29 January 2022 2:16 AM

I wonder if a failure to parse the XML file causes Reflect to use that heading as the default for the log. F&F backups were only introduced with Reflect V6, so that may be an inertial vestige of its imaging roots.
By JK - 29 January 2022 3:10 AM

I agree that it may be an unrelated error masquerading as the one shown in the log.  But it is odd that it goes as far as creating a new Image Set ID (a corresponding file name, 558922E79F802A19-00-00.mrimg, is even shown in the Logs list; I also noticed that at some point, the destination folder was added to the folder list on the Image tab of the Existing Backups view).  In any case, why would Reflect be unable to parse the XML intermittently (a very small percentage of the number of times that this backup definition was run by the scheduler)?  It is stored locally, so there shouldn't be any network connectivity issues.

P.S. I was previously under the impression that Macrium had added F&F functionality late in the game, but when researching this for a post in the Acronis forum some time ago, I found out that File & Folder backup was actually added way back in v3.0 (released in 2007, only a year after the original launch of Reflect in 2006).  Of course, it is still possible that the observed log entries are vestigial, as you have suggested, but I thought it was interesting to see that File & Folder backup has been part of Reflect almost from the very beginning.  
By dbminter - 29 January 2022 3:21 AM

I thought F&F backups go as far back as version 4.x.  I initially tried out Reflect because it offered file backups and I started with 4.x.  I first heard of Reflect looking for a file backup application and was recommended trying it.  Since it also did partition backups, primarily, and True Image was getting worse and worse, I moved over to Reflect.
By jphughan - 29 January 2022 3:25 AM

Wow, I could've sworn I remembered F&F backups being mentioned as a new feature for V6.  But perhaps not.

Anyhow, I don't see an actual file name in the log snippet that was posted.  I see a Set ID, sans file name extension, but F&F backups use those as well.  In terms of the underlying cause, an intermittent validation error makes me wonder if something might be modifying that XML file somehow.  There's a separate error if the XML file isn't accessible at all, so it seems that Reflect is finding it but doesn't consider it valid for whatever reason.
By JK - 29 January 2022 4:42 AM

Nevermind about the file name.  I didn't have sufficient column width to discover that they were just names of log files (.html), not .mrimg files:

For the record, the Backup Set ID for all backups created by these schedules is supposed to be CE397FD071CF7975.  I have a single Full backup as a baseline, and the schedule is only supposed to produce differential and incremental backups (so they should all share the backup set ID of the parent full).  Of course, it's internally consistent behavior that a new ID is generated if Reflect thinks it is supposed to be creating an image, because there is no image in the destination folder to append to.  But I think the fact that it is bothering to generate a new ID points to there being more to this behavior than just using some vestigial default info in the logs.

I've checked two of the three cases, and in those, the error occurred on the first attempt at running a scheduled job after the computer had been booted.  Could potentially be a clue.  I'll check on the third case tomorrow.

Update: Yes, according the Windows event log,  it appears that all three instances of this error were preceded by a boot-up:
  • On 1/17, boot-up at 10:37pm; the next scheduled incremental (10:45pm) failed.
  • On 1/24, boot-up at 10:40pm; the next scheduled incremental (10:45pm) failed.
  • On 1/28, boot-up at 8:35am; the daily differential (which was scheduled for 7:00am but had been missed) failed at 8:36am.
However, please note that there were about 9 other boot-up sequences during this time period that did not result in a backup error.
By JK - 30 January 2022 3:10 PM

Another piece of information:  The errors do not appear to be correlated with automatic  Windows updates or software updates.  

My best guess is that there is something occurring approximately once a week during the startup sequence that is interfering with Reflect.  But I'm unsure of whether this is just a case of a (very) misleading error message, or whether Reflect is somehow getting tricked into attempting to perform an Image backup instead of the specified F&F backup.

Occam's razor seems to point to the latter possibility.  As soon as Reflect has (mistakenly) decided that the scheduled task is an image backup, then all of the other observations could plausibly follow from that event alone:
  • It would explain why the Logs list displays the backup as an "image" instead of F&F (because Reflect thinks it's supposed to be creating an image);
  • It would explain why the Logs list displays the backup type as "Full" instead of incremental or differential (because there are no image backup files at the destination to append to);
  • It would explain why the Logs list displays a new backup set ID instead of the existing parent ID CE397FD071CF7975 (because Reflect thinks it is creating a new full);
  • It would explain why the log contents record an XML validation error (it makes sense that the contents of the XML file for the specified F&F backup task are inconsistent with the XML contents that Reflect would expect to see for an image backup task).

So, if I'm right, the big question is: how is Reflect getting the backup type confused (and what are the precipitating conditions that trigger this intermittent error?)?

Edit: Revised some wording to prevent misunderstanding.
By pokeefe - 30 January 2022 9:54 PM

I would guess your first 3 bulleted questions could all be the result of not having a valid backup definition, and not having a valid backup definition would be consistent the XML Validation Error.  But what is interfering with Reflect's reading the definition file (which was valid both before and after the error)?  And why would Reflect go ahead and try to take the backup if it thinks the definition file is not valid?

Very odd.
By JK - 30 January 2022 10:42 PM

Patrick... apologies for not writing more clearly:  the bullet points were not actually questions, they were a list of observations that could be explained by a single hypothesized failure mode (Reflect mistakenly trying to make an image backup when a F&F backup was specified).  I have now revised my previous post so that the bullet points don't start with the word "why", to make it more clear.

I know that the XML is valid (for performing a F&F backup), because Reflect has successfully used the exact same XML to complete hundreds of backups.  I was trying to apply Occam's razor and identify the simplest explanation that would account for all observations. 

Very odd.

By dbminter - 30 January 2022 11:31 PM

BTW, to establish a baseline, have you tried recreating this XML as a brand new XML and seeing if it performs as expected?  It may be a more serious issue with F&F's on your end.
By JK - 15 February 2022 3:08 PM


The reported behavior (Reflect attempts to create an image when a scheduled File & Folder backup definition is launched) still occurs in Build 8.0.6560.

Moreover, I believe I have determined the conditions necessary for this bug to be triggered: 

This happens after I reboot my computer, if the scheduled tasks are launched before I log on to my account (i.e., after Kernel-General Event 12 but before Winlogon Event 7001).

Is there any valid reason why Reflect should not be able to complete a backup task in the period between power-up and logon?  If so, this issue may be in the category of a valid/normal error condition that gets misreported (albeit in a very bizarre way).  If scheduled tasks are supposed to be able to complete before the user has logged on, then the issue is more serious.
By dbminter - 15 February 2022 3:41 PM

I don't know if it's related, but during beta testing of v8, I had an issue where scheduled backups weren't running at all.  What had happened was Reflect was "stuck" on start of Windows.  If I waited a minute or two before entering my password and logging, on, scheduled backups started on time.  If I entered my password to log into Windows right away when the logon prompt appeared, Reflect's scheduled backups would not start.  Reflect was updated to fix this "hang" on Windows start.