Snapshots are moving to the forefront of many data centers when it comes to data protection. Therefore, it’s important to have a solid understanding of how they work and what to use them for. It’s also very important to understand that their value is greatly limited if they are not replicated to another system.
A snapshot is a virtual view of a volume or file system from a particular point in time. After a snapshot is taken, the snapshot system preserves the view of that point in time by preserving any blocks that change after that point. A copy on write system copies to a snapshot area any blocks that are about to be overwritten with newer information. When an application reads the snapshot, the snapshot software will know which blocks have been updated since the snapshot and will know to get those blocks from the snapshot area instead of the current volume. In a redirect on write system, blocks are never overwritten. If a block needs to be updated in the current view of the file system, the file system redirects its pointer to a new block. When an application reads a redirect on write snapshot, it simply uses the pointer that was present at the time the snapshot was taken – no special snapshot area needed.
The advantage of redirect on write snapshots is performance. A copy on write snapshot requires multiple I/O’s for every updated block, where a redirect on write snapshot requires only the single I/O and a modification of the pointer. The more snapshots you take and the longer you leave them around, you will see a greater performance difference between these two snapshot methods.
Snapshots have two primary purposes: a consistent point in time for a traditional backup software system, or recovery from all of the same things that backup software is designed to protect you from. The best example of the first use of snapshots is Windows Volume Shadow Services (VSS). When a backup application backs up Windows, it communicates with VSS. VSS tells the backup application what VSS-supported applications are on the server or VM, and the backup application communicates with each of them to tell them to do whatever it is they do before a snapshot is taken. VSS takes the snapshot once all applications have communicated that they are prepared for it. Once the backup application has successfully completed a backup, it can use VSS to tell the applications that they have been backed, allowing them to clean up after the snapshot. They perform activities such as emptying the transaction logs of a database that are no longer needed since a backup has been performed.
If a snapshot is going to also be used to protect against both user error and damaged hardware, it is important to understand that all snapshot methods use the original volume to read any blocks that have not been modified since the snapshot was taken. If you lose three disk drives in a RAID6 array, a snapshot will be as useless as a snapshot of your house after it is burned down. In order for snapshots to protect against volume damage, they must be replicated to another volume.
Snapshots are a very valuable tool, but you must understand how they work in order to use them properly. If you are using snapshots to provide a consistent point in time for a backup application, make sure that you are integrating with the application the way VSS does prior to taking the snapshot. Otherwise, your snapshots will be crash consistent and not application consistent. Most importantly, snapshots rely on the original volume and so must be replicated if they are to be used to recover against volume loss.
Sponsored by Commvault