Storage 101: Snapshots vs backup

Snapshots 101

Fundamentally, a snapshot is a record – comprised of metadata – that indicates the state of blocks and files in a unit of storage. Often, snapshots come as a feature of NAS or SAN storage and are created and held on that storage.

They allow the user to roll back to previously existing versions of a volume, drive, file system, database, etc. So, for example, you can roll back to the state of a unit of storage at any previous snapshot.

Snapshots are like a point-in-time copy or table of contents that shows which blocks and/or files existed and where. In the case of rolling back, the volume or unit of storage in question would be changed to a state that reflected the snapshot, by removal and movement of blocks, etc.

Where blocks have been deleted, these have to be retained, and are added to the snapshot in case they are needed. In such a case, the version rolled back to could be a mixture of metadata from previous snapshots, data retained by those snapshots and whatever counts as a parent copy (ie, before snapshots).

So, snapshots are not backups because they are not copies. They don’t take up much space individually, but their total volume can grow, especially if there are lots of deleted blocks/files, and so suppliers usually limit the amount of snapshots that can be retained.

Snapshots: Benefits and pitfalls

A key benefit of snapshots is that they allow a faster roll-back to a previous point-in-time than from backups.

Another plus is that snapshots allow much more frequent protection than backup. It is possible to set snapshots for, say, once an hour, without affecting production systems, whereas backups are likely to run once a day and outside main production hours because of their impact on resources.

The flipside to being rapidly available comes down to snapshots usually being held locally on the storage device. That means they are vulnerable to any outages that affect that system and they use up (potentially primary) storage capacity.

So, snapshots are best used in conjunction with a backup strategy. Snapshots are good for more frequent protection measured in minutes or hours, while backups are used for daily protection. Snapshot retention periods will usually reflect that, with deletion of snapshots occurring after, say, 48 hours, which allows for one or two backups to have taken place in that period.

Snapshot types

There are two fundamental types of snapshot mechanism: copy-on-write and redirect-on-write.

Copy-on-write

In copy-on-write, when an I/O request seeks to change a storage block, that block is copied first and retained by the snapshot to which it belongs. That keeps everything consistent for that snapshot, which comprises pointers to unchanged blocks and copies of those subsequently changed.

Copy-on-write snapshots save on space because unchanged data is referenced from the original copy (as long as not much has changed). The downside is that performance can be affected because every write request is accompanied by the need to copy out a block for retention by the snapshot.

Redirect-on-write

With redirect-on-write, when new blocks are created, it only requires one write and that is to the snapshot. That means any reference to the current state of data is to the original and the snapshot. When snapshots are deleted, all those differences need to be reconciled back to the parent.

Because new data only exists across potentially multiple snapshots, access to it can become complex and performance can suffer, but less storage volume is required.

There are a few other common snapshot types:

Continuous data protection

Continuous data protection (CDP) is the creation of snapshots as above, but every time a change is made to the unit of storage in question – or at least at a level that is relevant to human users, such as file creation, update or deletion. That means CDP allows for roll-back to any point in time, but it also means a performance hit for more of the time. Where normally snapshots would run at intervals of once an hour, for example, with some performance overhead at those times, CDP creates extra I/O every time something occurs.

Mirroring, clones and replication

Related to snapshots, but entirely different in terms of mechanism, are the various forms of cloning. At its simplest, a clone is exactly as it sounds: an identical copy of a unit of storage. Not an original and snapshots of updated areas, but the whole thing.

This could take the form of one-off cloning of a drive or regular cloning of a volume, drive, etc, by the snapshot utility. Or it could be synchronous or asynchronous mirroring, in which data is written to two physical locations (almost) simultaneously. Here we are talking about replication, which is at the higher end of things in terms of technical and cost considerations.

Replication is a highly effective form of data protection and is used in the most transaction-sensitive verticals for its ability to provide an instantly available failover copy.

But replication can’t replace backups. They have to work together. For example, because replication is near-real time in the way it makes its copy, if corrupted or infected files are replicated, then you need a version to roll back to. Of course, that could be a snapshot, as discussed above, but then they also need underpinning by backups because of their limited lifespan. Also, because replication can be costly, it may be that only certain datasets are replicated, while everything is backed up.