Why Synthetic Full Backup Implementations are Riskier with Image-Based Data Protection

In general, Synthetic Full or "Incremental Forever" options have a bad name in the industry. This is because they are hard to make work correctly. They are difficult to implement for the vendor. They are also typically hard to configure and operate, for administration teams.

Also, when Synthetic Full implementations go wrong, the damage that they do to data is large and hard to repair.

First, let's start by being clear about how Synthetic Full backup is intended to operate. The theory is that you do a single full backup for a given set of data, and then every additional full backup for that data is synthetically built from the intervening incremental and differential backup copies. For example, in a backup cycle that includes a weekly full and nightly incremental backups, then the next full backup copy is built from taking blocks from the original full combined with the new blocks from the incremental backups that occurred during the week.

Once started, Synthetic Full can go on theoretically forever. The benefit is intended to be that you never again need to take the time to complete a full backup. Instead, you simply run "incrementals forever." The backup software does the heavy lifting by assembling the full from all of the previous backups.

Here's the catch: depending on the implementation of the backup software, its capability to continue to assemble Synthetic Fulls is reliant on keeping the first Full backup available. If something happens to that Full copy -- such as the data being corrupted by a bad disk or overwrite -- then future Synthetic Fulls may be disrupted. Not only that, but every Synthetic Full created since the Full is also disrupted and unrecoverable. These problems combined with the administrative complexity of working with the feature, have caused Synthetic Full implementations to be unreliable. As a result, for the large majority of backup environments, Synthetic Full has fallen out of active use.

The problems with Synthetic Full are even worse in an image-based backup product than with traditional backup. This is true because Synthetic Full causes constant modification of the backup image held in the archive. The Full is not left intact as with traditional backup. Instead, the image must be modified on the fly.

Is there a Better Method for Improving the Performance of Full Backups?

Rather than add complexity to the backup process by replacing Full backups with a synthetic process, what's needed is an improvement in the way that Full backups are made. As part of the image-based backup process, a Full requires all of the blocks on the disk to be read. The image-based read process includes all of the empty blocks in the VM image. VM images contain a large percentage of white space, or empty blocks. Simply skipping those empty blocks during the read process for creating a Full can dramatically improve backup performance and avoid the need for complex synthetic processes.

But don't I already skip the white space on read? My backup product has white space omission.

The short answer is no. Any image-based backup solution must read the white space -- must read every empty block -- before it can remove that white space from the image.

The only method which is known to help avoid the process of reading the white space in an image is called Active Block Mapping (ABM). This patent-pending capability was invented by Vizioncore to query the file system, and skip inactive blocks during the read. This speeds Full backups dramatically. Why read, for example, 10GB of empty blocks in every image when you can just skip them?

In head-to-head testing, the performance improvement of using image-based backup with ABM versus a competitive image-based backup product using Synthetic Full is dramatic evidence of the power of ABM. We are not ready to release the detailed results just now. But, we will be soon. The net results show that if you can gain a 3:1 improvement in performance on Full backups versus working with the complexity of Synthetic Full.

Can't I combine Full and Synthetic Backup to reduce my risk?

Most implementations of Synthetic Full make you pick one method forever. Check with your vendor, but once you start using Synthetic Full you may find that you need to keep using it forever. Conversely, these vendors may also force you to create a Full backup image on every backup pass, if you decide to create more than one Full backup for the same VM image.

About the Author