Snapshots have lots of benefits. They allow a quick roll-back to a previous point in time and allow for much more frequent protection than backups, without affecting production systems.
Meanwhile, backups are likely to run once a day and outside main production hours because of their impact on resources.
But snapshots and backups are best as complementary components in a data protection strategy, and here we look at five key points about the use of snapshots, including what is unique to snapshots and why they are not backups, as well as the limits to snapshot use that we need to keep in mind, such as how many should be retained.
1. Snapshots are a record of changes to a disk or volume
Snapshots record the state of blocks and files in storage at a given point in time. They are used to allow roll-back to previously existing versions of a volume, drive, file system, database, etc.
Snapshots show which blocks and/or files existed and allow the base units of storage to be changed to a past state by removal and movement of blocks, addition of those deleted, etc.
2. Snapshots are not backups
Snapshots are not backups because they are not copies. The original drive, volume or whatever still exists and snapshots function to indicate its previous states and allow the customer to roll back to them.
For that reason, if the base unit of storage being protected is compromised in some way, then snapshots only allow a roll-back that will also be compromised, or not be possible at all.
Also, snapshots are taken frequently, such as every 15 minutes or every hour, but it doesn’t make sense to keep too many of them. Backups can be kept that record the state of systems going back a long way.
3. Don’t store too many snapshots
Snapshots don’t take up much space individually, but their total volume can grow, especially if there are lots of deleted blocks/files. This is another reason why snapshots do not substitute for backups. You just can’t keep enough of them.
Why not? Firstly, to keep lots of them increases the complexity of the rebuilding process. That is because to recreate the state of storage at a given point in time involves recreating it from many incremental records that comprise all the changes that have taken place.
That could mean a lot of storage space to retain those snapshots, but it definitely means a high processing overhead to put all those pieces back together again.
4. Delete snapshots after backups have been made
Snapshots can take up a lot of storage space and become increasingly onerous to rebuild from as more are accumulated. For those reasons, it makes sense not to keep snapshots for more than a certain – relatively short – period. A rule of thumb would be not to keep them after a backup has been made.
Just using snapshots for roll-back between daily backups should ensure the snapshot chain doesn’t get piled too high.
Some suppliers recommend maximum numbers of snapshots are kept, but here again the more you keep, the more performance will be eroded.
5. Be aware of user snapshot permissions
It is often the case that users have permission to create snapshots but not to delete them, and this can lead to a build-up of snapshots. That is because to deletes are usually considered a more dangerous permission, but as we have seen, to allow too many snapshots to hang around can degrade storage and virtual machine performance.
