I deleted the root image, the full image backup ending in 00.mrimg.  Therefore, I expected that when the next incremental backup ran, it would notice that the base image was missing and run a full backup.  But instead, it proceeded to do an incremental backup.  Doesn't a restoration require a full image backup as a starting point, to which the incremental and differential backups are applied?  If this is true, then why didn't Macrium notice that the full image backup was missing and do a full backup rather than proceed with an incremental, which if I understand correctly, is worthless because there is no base image to which incrementals  may be applied.

I believe if you'd have deleted the full image through Reflect as opposed to using a utility such as Windows Explorer it would have deleted the entire chain.  (I am jumping to an assumption here.)  This is one of the reasons why Macrium has suggested deleting image and backup files from within Reflect.

However, if it didn't elongate the process very much, I think Macrium should build a way into Reflect to have it check for issues such as this.

Indeed it does as you suggest... but surely Macrium should not continue the process without that FULL being present, or any required piece of the chain, for that matter.  I'm sure they'll address the issue.

Hi

Image sets can be split over multiple destinations. This is perfectly normal. This happens when space runs out on the destination drive and you are prompted for a new destination to continue. It also happens when writing to multiple DVD's. To write an incremental the previous backup in the set needs to be present in the target folder, not the entire set. When this happens there is a Warning message in the log, but the incremental will complete.

Deleting partial sets using Windows Explorer should be done with caution. There is a delete function in Reflect that ensures backup set chain integrity.

Kind Regards

Nick

Macrium Support

See our reviews on

This would suggest that every incremental has a full cluster map, otherwise the full backup would be required to know what is changed. 
That might explain some of the questions people have asked about the size of an incremental backup when very little has changed. If the disk is large every incremental contains that large map.

What Nick is saying, is that my problem occurred because I didn’t go through the software to make the deletion.  Because the historical backups in the chain might be on inaccessible volumes, the backup process cannot know if there are missing links in the chain.  Splitting backups across volumes, where previous volumes are not available, e.g., backups to DVDs, would not work in the general case.   At the minimum, you would always need the previous backup, whether that is a full backup, a differential or an incremental, so the delta operation could be performed.
  
I gave up trying to understand the sometimes large backup sizes.  Once, the day after a full backup of 335 GB, the incremental backup was 36 GB on what was basically a quiet system.  Did it forget something the day before and have to go back and get it?  Macrium may very well be doing exactly what it’s supposed to be doing, but it’s hard to disregard the weird proceedings.
 
I think I’ll go kick some more tires and see what else shakes out.

HarpKat 4/2/15