Shifting to Software-Defined
Showing results for 
Search instead for 
Did you mean: 

Disaster Recovery Throw Down: Snapshots vs. Traditional Backups



Hani A.jpgBy guest blogger, Hani El-Qasem, Solution Architect

In the IT field, most professionals are loyal to one disaster recovery method: either snapshots or backups. However, is one really superior to the other? Most traditional storage vendors will use some kind of snapshot functionality to provide a rudimentary level of data protection and then enlist the assistance of third-party backup tools to cater to the deficiencies of a snapshot-based strategy. To get a better understanding of these two methods, let’s compare snapshots and backups.


A snapshot can be defined as a point-in-time copy of data, used to freeze that data in an un-changing state so it may be recalled at a later time if required. Although useful for short-term, ad-hoc operations such as testing patches or small software changes, it should be considered as a limited data protection methodology.

The key characteristics of a snapshot are:

  • Complete in a matter of seconds
  • Chain dependent (meaning linked together with other snapshots)
  • Stored “on-device” with production data
  • Lacking granularity for management and restores
  • Lacking application consistency

While snapshots can be performed in a rapid fashion (usually in a matter of seconds), the tradeoff for this speed is limited protection against anything other than simple software failures. 

Snapshots in most storage systems begin with a base snapshot; subsequent periodic snapshots are then linked to that base snapshot, and the storage device will have a mechanism for recording the delta differences between the snapshots in a metadata system or volumebigstock-Two-Old-Brown-Boxing-Gloves-Hi-134955308.jpg map. Consequently, if there are any problems (e.g., corruption) with the base snapshot or older snapshots in the chain, all the connected more recent snapshots are unusable. This dependency between the base and chained snapshots is a key risk with the use of snapshots as the sole data protection strategy.

Another issue with snapshots is they are stored on the same physical device as the production data and other snapshots. So, if you lose your production storage device, you’ll lose all of your snapshots. Clearly, this is not a good position to be in, though it is possible to replicate snapshots to a different device to defend against losing data. Doing so, though, takes significant effort and requires a huge amount of storage activity that must be scheduled at off-times as to not disrupt daily operations.

As most storage providers have historically been in the mindset of logical unit numbers (LUNs), they have a slightly different perspective on application VM-centric protection. It’s easier to tackle LUNs as you load your VMs on a LUN and snapshot it simultaneously; however, this process may cause problems with application control and consistency. On top of the complex management required to manage each VM on each LUN, you cannot restore an individual file or VM without restoring the entire LUN with all of its other VMs. These LUN-level snapshots are rarely application consistent, causing further headaches during restores.

While snapshots provide some value, there are too many deficiencies to use snapshots for data protection in most traditional environments. And if you do, a third-party backup tool is often still required.

Traditional Backups

Like a snapshot, a backup can also be loosely defined as a point-in-time copy of data, used to freeze that data in an un-changing state so it may be recalled at a later time if required. This is identical to the definition of a snapshot. Slightly confused? That’s understandable, but the two do differ in their implementation and associated risks.

The key characteristics of a backup are:

  • Saved on a separate physical device
  • Improved data efficiency, when compared to snapshots
  • Application consistent backups and granular restores at the VM, file, or application level

The key deficiencies for traditional backup are time and load. It takes a great deal of time and I/O to move data off the primary device and then move it through the restore process or across the network. Because of that, traditional backups are usually scheduled in the evening at off-peak times. Snapshots can do the job more efficiently, but just for short-term operations like software or patch changes.

The superiority of snapshots vs. backups is not a question that can be answered easily. At the end of the day, IT teams need a method to save copies of their data, and the best method to do so depends on what works best for them. Each method comes with tradeoffs that the team must accept; however, adopting the right solution can reduce the number of tradeoffs.

Stay tuned for my next blog in this series to learn about how HPE SimpliVity hyperconverged solutions leverage snapshots and backups to protect your data. In the meantime, read this hyperconverged ebook: How Hyperconvergence Can Help IT.


Hani El-Qasem is a UK based Solution Architect. A 20-year veteran of the IT industry, he has worked with a broad range of client organisations and an equally broad range of technologies. Prior to HPE SimpliVity he held positions at Veeam Software and more recently VMware.  With his experience of applications, platforms and infrastructure through the eras of mainframe, client-server, virtualisation and cloud, he now helps organisations to leverage hyperconvergence to simplify, protect and optimise their IT environments.

Follow HPE Composable Infrastructure

0 Kudos
About the Author