Three ways for admins to use a VM snapshot

An effective virtualization backup strategy is crucial for IT. Snapshots offer admins the opportunity to roll back VM settings to those used before an outage or unintended change.

Virtualization technology allows data center administrators to capture snapshots of each virtual machine. A VM runs in computer memory, and snapshots capture the complete state, configuration and data associated with the VM at that moment. Then, the VM snapshot is saved as a file in storage. Unlike traditional backups, storage snapshots complete quickly and rarely require quiescing the VM workload. Administrators can capture frequent snapshots, and it is also easy to create, retain and manage multiple snapshots over time.

Since a snapshot describes the complete state of a VM, admins can use it as a restorative mechanism. Applying a snapshot can essentially restore -- or roll back -- the VM to an earlier point in time when the selected snapshot was taken. Both rollbacks and a VM snapshot can serve many purposes in the data center.

Guard against the unexpected

You can use snapshots to guard VM workloads against risky changes or unforeseen results when changes occur. Change always presents some risk for any production data center environment, no matter how well you test the changes in advance. Capture a snapshot of the existing VM before you make any changes so you can restore the snapshot later if stability, performance or other unintended consequences arise. This will undo the changes and restore the VM to its previous state.

This use of a VM snapshot is common when admins apply configuration changes, or a software patch or update, to a workload. For example, software updates can notoriously cause unintended consequences, such as a subtle change in data formats or a tweak in API usage that might disrupt other related workloads. When you apply a previous VM snapshot, it removes the changes. However, there may be some data loss between the point in time when you took the snapshot and the point in time when you restored it.

Another common example includes recovery from malware. For example, any VM workload that can open and run files is potentially vulnerable to malware infection or attack. Server-wide antimalware tools can detect and probably remove the malware, but not all infections are easily cleaned, and difficult attacks may require snapshot restoration to a point in time before the malware was launched.

Restore a nonpersistent state

Most VM workloads are intended to be persistent. That is, snapshots periodically protect the workload against faults. When faults occur, you can restore the workload to a recent state. For example, a busy database application would benefit from frequent snapshots, helping to mitigate data loss and speed restoration when disruptions occur. However, this isn't always necessary or desirable for certain applications that might not require such persistence.

No snapshots needed

Not every VM workload requires the rollback or restoration benefits that snapshots provide, and nonproduction VMs can typically forego snapshots.

For example, consider a temporary VM created to test a new application for software development or data center evaluation purposes. These "throwaway" VMs probably don't justify the additional storage usage -- especially when the VM is deployed in the public cloud -- or management effort needed to implement snapshots. If that temporary, nonproduction VM fails, restore it from the original VM file and start it fresh.

Consider snapshots of temporary desktop instances for clients, temporary employees or other guests that you can spin up on demand and then discard when no longer needed. Another example might include VMs with pre-patched and preconfigured web servers that can be used to restart existing web servers if failures occur. In these cases, you won't need regular snapshots because you're concerned with the desired working version of the workload rather than the current state of the application.

Restoration and recovery

Storage snapshots play a core role in overall VM protection, which is an ideal complement to any disaster recovery or data protection scheme. This normally involves an initial copy of the VM, and each subsequent snapshot represents a differential, or delta, of the VM's contents at each point in time. The central advantages of this process are speed and rollback capability -- the ability to restore the VM to any number of specific points in time. VM snapshot speed is important because it allows you to frequently take snapshots for low recovery point objectives. However, rollback capabilities aren't the main goal here. The real end game is to capture the snapshots so that you can restore and restart them from a known-stable point.

There are two tricks to use snapshots for backup or protection purposes. First, take the snapshot in a consistent state, which almost always requires you to queisce the VM workload first. Quiescing the workload pauses the application and flushes buffers to clear any data in-process. This ensures that you can restore the resulting snapshot to a safe state and restart it without being in the middle of any processes that you might not be able to recreate successfully when you restore the VM.

Second, in order for a VM snapshot to work as a backup or other protective mechanism, you must replicate the snapshot to some location other than the default local storage subsystem. Typically, you should replicate snapshots that are intended for protection to off-site storage locations such as secondary data centers or cloud storage resources.

Next Steps

Consider a remote data replication strategy

Why a data center shutdown procedure is important

Don't get hung up on VM snapshots

Dig Deeper on Virtualization and private cloud