In this article, I am going to discuss what is Volume Shadow Copy Service (VSS) and virtual machine (VM) snapshot, and how they can make Hyper-V data protection more reliable. However it’s not recommended to use snapshots as a primary data protection method, and I am going to briefly explain why and for what purposes snapshots were initially designed. I will also define what’s backup in relation to snapshot, what is replica, and why it’s efficient to use them in combination.
It’s not a secret that virtualization has brought a lot of changes into the IT world. That said, it was invented with the purpose of using IT resources more effectively than before. And one of the most important advantages of virtualization is how more convenient it is to protect your data. So, what’s so special about Hyper-V data protection?
The most common approach for protecting data is backup. And when we talk about an application-consistent backup, we’re talking about VSS. Let me explain what VSS is.
Volume Shadow Copy Service
Volume Shadow Copy Service (VSS) is a Windows service, which was introduced in Windows Server 2003 in order to provide administrators backup transaction consistency. It coordinates the whole process of taking data copy in a consistent manner and at the same time making sure that applications stay online. Practically, VSS does not create a copy of data, it rather saves the current data state and makes sure this state is consistent within a point in time.
Basically, VSS orchestrates the smooth collaboration of the service itself and three supplementary components – VSS requestor, VSS provider and VSS writer.
Pic. 1 VSS communication process
The VSS requestor is a component that freezes data for capture.
The Volume Shadow Copy Service writer is a special component that is running together with VSS-aware application since its installation. Most applications that run on Windows these days are VSS-aware. It’s rare to find an older server type application that is not. In order to get a list of VSS-aware applications installed on a particular operating system, run “vssadmin list writers” in the command line. SQL and Exchange are examples of such applications.
Pic. 2 An example of VSS writers
The VSS provider is a component that creates and handles all shadow copies of data on the OS.
So how does the whole service work? The Volume Shadow Copy Service requestor asks to create a server snapshot and requests a list of VSS writers. Then it communicates with each of the VSS writers and tells them to prepare corresponding applications for backup. Once all of the writers complete pre-backup tasks, the requestor instructs the VSS provider to take a snapshot and the snapshot process begins (I will explain what snapshots are later in the article). When the snapshot is created, the VSS requestor notifies the writers about the status of the operation and asks them to perform post-backup tasks. After that, all applications remain working in their regular mode.
Let’s not go further into Volume Shadow Copy Service details here but conclude that VSS is a Windows OS service developed to make data protection easier in general. It also becomes a baseline for snapshots, which gives virtualization another advantage and makes it flourish.
What is a Hyper-V snapshot? How does it work?
Snapshots are a consistent point-in-time (VSS ensured) VM state (with data and hardware configuration). Hyper-V creates it upon request so VMs can easily be reverted to any snapshotted state when needed. Snapshots can be taken regardless of whether the VM is running or not, no matter the OS or hardware configuration.
Modern backup solutions rely on snapshots because it allows performing backup operations with no downtime. Before the actual backup is created, the backup software requests a snapshot. The actual backup only starts when the snapshot is created. Meanwhile, VMs continue to work with the snapshot disk (the hypervisor places their temporary data into the snapshot, not the actual disk). This process goes so smoothly that users working on that VM don’t see any pauses and can continue to work on the VM when it’s running on snapshot. When the backup is finished, the actual disk is unlocked and the hypervisor implements the temporary data from the snapshot into it and, by that, consolidates the data.
As a side note, snapshots should not be used instead of backup for a couple of reasons. One reason is that when you lose a VM (Maybe due to hard disk corruption), you lose the snapshot as well and the ability to recover from it. Moreover, snapshots reduce host performance with along perspective. They are a perfect fit when a new patch should be tested on OS. You always want to make sure the application works properly after an update, right? But after such a test, the snapshot should be deleted (reverted in case of failure or consolidated in case if success).
All in all, Volume Shadow Copy Service and snapshots provide a good mechanism for data protection solutions in virtualized environments. Veeam Backup & Replication, as an example, relies on VSS and Hyper-V VM snapshots technologies and ensures data protection by creation of backups, replicas or combination of both.
What is backup and replication? Why do backup and replication work better together?
A backup is a deduped and compressed file which can contain an unlimited number of VMs inside. A few subsequent backup files are usually organized in backup chains (incremental or reversed incremental).
A replica is a copy of one VM placed on a host, disaster recovery (DR) or another, in a ready-to-use state. Sounds really good, eh? However, backups and replicas work better together. Why?
With backup alone, you miss out on the many advantages of replication. Hyper-V replication provides better Recovery Time Objectives (RTO) values. Since replicas are, again, not compressed and deduped, they will be started within seconds and it allows you to significantly reduce possible production downtime. This is especially important for your Tier 1 services.
On the other hand, imagine that you use only replication. In this case, any problem in the production environment will be replicated to the DR site. At this point, you are basically left with no solution unless you have few backup copies presumable older than the bug. In this case, you’re safe since you are able to recover your VM without an issue.
To sum up, complementary use of Hyper-V backup and Hyper-V replication is the best strategy for your data protection policy, and nowadays, is just a piece of cake. Take advantage of it. Your boss will be happy :)
See also
- How to protect Hyper-V virtual machines: Backup and replication better together
- Volume Shadow Copy Service (MSDN)
- How to create a Hyper-V VM template
- Hyper-V backup & Availability
