Start the New Year with a New Backup Strategy


2017, we hardly knew ye! The year came and went in a flash, with many of us still wishing we had more time to do the things we had on our list. That is what the New Year is for right? What better time to refresh, re-organize and revitalize IT to-dos than at the start of the year!

If you’ve added to the data or VM count that you are backing up on site, there is a possibility you may have outgrown your current backup strategy. Perhaps your backups are now exceeding their acceptable backup window, or are running out of storage to keep them on. First things first: Before you start throwing money at the problem, make sure to locate the current holes in your strategy. Is our backup server resource constrained and can no longer process the backups in time?  Or perhaps the repository is the bottleneck?

Before you invest in server or storage resources, consider that a brand new backup method might be a better fit for your current requirements.  Our trusted partner Veeam has a very nice and detailed breakdown of different backup configurations on their expert exchange, which I have summarized below.

The table below provides a general overview of Veeam-supported backup methods and their I/O impact on source and destination storage:

Method

I/O impact

Forward incremental 1x write I/O for incremental backup size
Forward incremental, active full 1x write I/O for total full backup size
Forward incremental, transform 2x I/O (1x read, 1x write) for incremental backup size
Forward incremental, synthetic full 2x I/O (1x read, 1x write) for entire backup chain
Reversed incremental 3x I/O (1x read, 2x write) for incremental backup size
Synthetic full with transform to rollbacks 4x I/O (2x read, 2x write) for entire backup chain

 

Forward Incremental Backups 

The forward incremental backup method generally works well with all storage devices, although it requires more storage space than other backup methods due to the fact that it requires the creation of periodic full backups.

Active Full Backups

When creating an active full, the I/O pattern on the backup storage is mainly sequential writes, which generally provides good performance for most storage solutions. However, all the data (not just the changes) has to be copied from the production storage, and this will increase the duration of the backup activity and the time a VM snapshot remains open.

Use

Don’t Use

Recommended for deduplication appliances that use SMB or NFS protocols. When backup window does not allow enough time for re-reading all of the source VM data.
On storage systems that use software or non-caching RAID hardware such as many low-end NAS devices. For large or performance sensitive VMs where re-reading the data can have a negative impact on the VMs performance.

Synthetic Full

Due to the way synthetic full works, having many smaller backups jobs with fewer VMs will allow for faster synthetic full operations. Keep this in mind when setting up jobs that will use this method or choose to use Per VM Backup Files.

Use

Don’t Use

When repository storage uses fast disks with caching RAID controllers and large stripes. Small NAS boxes with limited spindles that depend on software RAID.
Deduplication appliances that support offloading synthetic operations. Deduplication appliances that use SMB or NFS protocols.

Forever Forward Incremental

The primary advantage of using forever forward incremental backup method is space savings. However, the tradeoff is the required resources for the merge process. The merge process may take a considerable amount of time, depending on the amount of incremental changes that the job has to process. The advantage is that the merge process impacts only the target storage.

Use

Don’t Use

Repositories with good performance. Smaller backup repositories or NAS devices with limited spindles and cache.
Ideal for VMs with low change rate. Jobs with significant change rate may take a long time to merge.

Reverse Incremental

This method provides space-efficient backup, as there is only one full backup to store. It also facilitates retention, since removing old restore points is simply a matter of deleting old VRB files.

The disadvantage is that creation of rollback files occurs during the backup process itself, which results in higher I/O load on the target storage and can slow down the backup process.

Also, over time the in-place injection of new blocks into the full file causes fragmentation of the VBK file. This can be partially fixed by using compact operations.

Use

Don’t Use
When repository storage uses fast disk with caching RAID controllers and large stripe sizes Small NAS boxes with limited I/O performance
VMs with low change rate Deduplication appliances due to random I/O pattern
High change rate VMs, as VM snapshot may be open for a long time

Updated: January 2019

Explore INAP Disaster Recovery as a Service.

LEARN MORE

INAP
  • Editor

READ MORE