This article explains the situations when Reflect will create a full backup instead of an incremental or differential backup.
There are a number of cases when you have a backup task, either scheduled or manually triggered, that is configured to produce a differential or incremental backup as part of a backup set and Reflect instead reverts to a full backup. This article explains why this may occur.
If the full (or parent incremental) is inaccessible for any reason
Example: There are a number of scenarios in which this can occur. We shall take one example. Suppose you have two backup locations:
Primary location: \\myserver\backups\pc1\
Alternative location: d:\mydata\backups\pc1\
Suppose that you are taking incrementals at the primary location but at the time of backup the network location is not reachable. In this case, as requested, Reflect will use the alternative backup location. As it cannot read the backup set at the primary location it will then create a full backup at the alternative location.
Note: the online help for Macrium Reflect contains a section on alternative backup locations.
Reason: Reflect needs to be able to read the existing backup set to work out what has changed.
If the backup set being appended cannot be opened due to corruption.
Example: This issue is triggered when the source backup set is corrupted for some reason. As an example, suppose that you are backing up to an external USB 3 disk called G: and suppose that the existing backup set is created at G:\backups\pc1\. Now, suppose this backup set has somehow become corrupted. Reflect cannot recognise this as a valid backup file and so creates a new backup set.
Reason: If files are corrupted such that they are not recognisable as backup sets, it is likely their indexes (used for performing incremental or differentials) are unusable too.
If the full (or parent incremental) contains a non matching set of partitions compared with the requested incremental.
Example 1: Suppose your system contains drives C:, D: and E:. Initially, your backup definition contains C:,D:. You take a full followed by a series of differentials. You then edit the backup definition file to include E:. Reflect will then trigger a full backup.
Example 1: Suppose your system containsdrives C:, D: Initially, your backup definition contains C:,D:.You take a full followed by a series of differentials. You then resize D:. Reflect will then trigger a fullbackup.
Reason: Reflect considers that if a backup definition differs from what is contained in the backup set, then it is potentially an entirely different backup source. It would be difficult to reliably distinguish between the sensible examples given above and removing all of the source drives and using others. The resulting incremental would make little sense. The potential for an invalid backup set to be created is high, so Reflect prevents this.
If the disk ID is different to that in the full (or parent incremental).
Example: Suppose you have a backup set for a system on a network share. You then perform a clone of this system to a new disk, remove the old disk and boot the new system. You then ask Reflect to back up the system using the existing backup set. Reflect will create a full.
Reason: Macrium Reflect uses the Disk Identifier in MBR, or the Disk GUID on GPT systems, to uniquely identify the disk and verify that the backup set and backup source are of the same disk layout. These values remain stable so are a reliable identifier.
If the source folders, or filters, are changed in a File and Folder backup
Example: Suppose you are backing up *.doc in C:\ImportantData\. You then modify the backup definition to back up *.doc;*.xls in C:\ImportantData. Reflect will then create a new full backup.
Reason: Changing the directory or filter essentially changes the source definition. In many circumstances it would not make sense to take an incremental from this source, so Reflect defaults to a new full.