How Backup Works with Hyper-V

What is a virtual machine? From the perspective of a storage system, it’s normally just a few files. That’s one of the nice things about virtualization: virtual machines are just files, and files are easy to back up and restore. Backing up a physical server isn’t so bad, but it sure is stressful when you get a call at 2 a.m. on a Saturday to do a bare-metal restoration to a different set of hardware. Not so with virtual machines; they are abstracted from the underlying hardware. A virtual machine restoration is much like restoring a few files—although it requires just a little bit more than that, as you are about to learn.

Volume Shadow Copy Service Framework

Microsoft introduced the Volume Shadow Copy Service (VSS) framework to enable consistent backups of open files. Initially it was used to dependably back up open files, such as those on a file server. But soon after, Microsoft added VSS support for databases such as SQL Server and Exchange to enable their databases and log files to be consistently backed up.

Consistency is critical; you cannot have a safe backup if the database file is backed up at one point, the log file then commits and flushes, and then the log file is backed up. If you were to restore this database and log file, the database would be missing the data that was committed after the backup, and the database would be inconsistent.

Not only does VSS allow open files to be backed up, but it also briefly places VSS-compatible services into a quiescent state. Placing a virtual machine into a quiescent state is a process whereby buffers are flushed and writes are briefly paused. This brief pause allows a consistent VSS snapshot to be created of the volume in question, containing the data that is to be backed up. The snapshot is maintained long enough for the backup application to perform the backup from the snapshot.

Snapshot! What Snapshot?
Snapshot is a term that is overused in the world of virtualization. There are three types of snapshots in Hyper-V:
Hyper-V Snapshot
Also known as a checkpoint, a Hyper-V snapshot captures the state of a virtual machine at a certain point in time by using AVHD files. An administrator can create this snapshot, perform some work on a virtual machine (such as doing a demo or testing an application), and then apply the snapshot to return the virtual machine to that point in time. Hyper-V snapshots are not a form of backup. A backup stores a historical copy of the virtual machine on some out-of-band remote storage. That’s not what a Hyper-V snapshot is; it maintains a constantly growing AVHD file in the same location as the virtual machine in question. Keeping this kind of snapshot also reduces the performance of a virtual machine. Lose the virtual machine, and you lose the Hyper-V snapshot. There are some unfortunate stories of Hyper-V snapshots being misused in this manner, and they never end well—except for the consultant who is called in to rescue a client and is charging by the hour.
VSS Snapshot
VSS creates a snapshot, or a shadow copy, of a storage volume by using spare space within the targeted volume. This allows two important things to happen. First, open files can be backed up. Second, when combined with a brief pause of VSS-compatible services, it enables the data of those services to be backed up consistently. This chapter focuses on VSS snapshots.
Storage Area Network Snapshot
A storage area network (SAN) may have the ability to create snapshots of a LUN by using additional storage on the SAN. This feature can be built in or can require additional licensing to be purchased from the SAN vendor. With the supporting software from the SAN manufacturer, SAN snapshot functionality can be used by VSS to create volume snapshots more rapidly than Windows Server can do it. This is particularly useful when dealing with large volumes because the snapshot process is much quicker than a snapshot performed by VSS alone.

Several components are involved in the creation of a consistent VSS backup, as seen in Figure 10-1:

Requestor The Requestor initiates a VSS-enabled backup operation. This is usually a backup agent, such as Windows Server Backup, System Center Data Protection Manager (DPM), or others.
Volume Shadow Copy Service The Requestor invokes VSS, which in turn enumerates the Writers and starts the VSS snapshot-creation process.
Writers Every VSS-compatible service has a Writer. This includes SQL Server, Exchange, and Hyper-V. The Requestor can communicate with a Writer to discover which files, and therefore which volumes, must be backed up for a particular service, such as a virtual machine.
Writers also interface with the services in question. They arrange to briefly pause the services, putting them into a quiescent state, so that a snapshot of the service’s files can be created. This can include actions such as flushing caches and committing open transactions before flushing the file system buffer. The maximum length of this pause is 60 seconds. The Writer will inform the VSS framework, which is orchestrating the backup, after the targeted volumes are in a quiescent state.
Providers The Provider, started by the VSS framework now that the volume is in a quiescent state, is responsible for creating a snapshot for each volume that contains files to be backed up. If files included in the backup span more than one volume, the Provider will synchronize the creation of snapshots of the volumes to ensure consistency. The Provider has up to 10 seconds to create the snapshot. The pause that was initiated by the Writers is ended after the Provider has created the snapshot. The Provider will return the location of the snapshot to the Requestor. The Requestor will perform the backup from the snapshot, and the snapshot will then be removed.

Figure 10-1 The components of VSS

c10f001.eps

VSS can use three types of Providers:

System Provider This is built into Windows and will create a VSS snapshot of a volume by using free space within the volume for a backup.
Hardware Provider Some SANs support the creation of a SAN snapshot of a LUN for the purposes of VSS. This solution requires that the SAN manufacturer support the creation of Cluster Shared Volume (CSV) snapshots for Windows Server 2012 Hyper-V. Be sure of this; many have experienced problems when they incorrectly assumed they had support for creating SAN snapshots of Windows Server 2008 R2 CSVs. If you have this support, and if your SAN has the feature turned on or licensed, then you can install Hardware Providers on each host connected to the SAN; check with your SAN manufacturer for instructions.
Windows will automatically favor the Hardware Provider over the Software Provider. Maybe you are having issues with a Hardware Provider and need to force Windows to use the System Provider. You can force this override by setting UseMicrosoftProvider (REG_DWORD) in the Registry at HKLMSystemCurrentControlSetControlBackupRestore.
Software Provider A Software Provider provides the same functionality as a Hardware Provider, but for software-based storage. The difference is that the hardware solution uses hardware to create and manage snapshots, whereas the Software Provider solution must use software.

You will now look at how VSS can be used to perform different kinds of backup of virtual workloads on Hyper-V.

Virtual Machine Backup Strategies

There are a number of strategies you can take with backup and Windows Server 2012 Hyper-V. There is no one right strategy. One will be right for company A. Company B might go in another direction. And company C might choose to use bits of one strategy and bits of another. Here are some of your options:

Storage-Level Backup

With this type of backup, your solution backs up virtual machines, as they are running, using VSS at the host or storage level, just as if it were backing up a database on a SQL server. The Requestor, or the backup agent, is installed on all of your Hyper-V hosts in the management OS. It will be responsible for backing up the running virtual machines. There is no need to install a backup agent in the virtual machines’ guest operating systems.

The Hyper-V VSS Writer identifies the volumes that targeted virtual machines are stored on. The VSS Provider uses this information to create snapshots of those volumes. To maintain consistency, the Hyper-V VSS Writer is used. It not only places the virtual machines into a safe quiescent state but also uses any VSS writers found within the virtual machine to place services running within the virtual machine into a consistent quiescent state. This means that sensitive-to-backup applications such as SQL Server or Exchange can be safely backed up with this method. Note that clearing the check box for Backup (Volume Snapshot) in the Integration Services section of a virtual machine’s settings will disable this default behavior.

The benefit of this approach is that backing up a virtual machine becomes simple: you just target the virtual machine in your backup application. Restoration is an administrator’s dream come true; if you lose a virtual machine, you just restore it. The backup application restores the files for you. Some backup products will even register the virtual machine in Hyper-V for you. It doesn’t matter if you backed up the virtual machine on a Dell host and are restoring it on an HP cluster. The hardware is abstracted, thanks to virtualization. Compare that to trying to do a bare-metal restoration of a physical server.

Storage-level backup works only with virtual hard disks (VHD or VHDX).

In the past, it was recommended that you do a storage-level backup on an infrequent basis, such as once per week or once per month. This was for two reasons. In a cluster with CSVs, backup caused redirected I/O to occur across the network designated for cluster communications (the network with the lowest network metric). That’s no longer a problem in Windows Server 2012, thanks to a new distributed snapshot system.

The other reason was that this type of backup was always a full one, not incremental, when the virtual machines were on a Hyper-V cluster. This was wasteful; a typical virtual machine would have a relatively tiny amount of growth every day, but everything had to be backed up, transmitted over the network, and archived. That would consume a lot of space on the disk-to-disk backup storage or tape library. Windows Server 2012 does a lot to alleviate this problem by adding the ability to do incremental backup of running virtual machines. This means that if your backup solution can support it, you can take just the changes from the backup application.

Many Hyper-V backup solutions favor this style of backup, particularly solutions that are designed for small and medium enterprises (SMEs). And many solutions, including System Center DPM, include the ability to mount a backed-up virtual hard disk and restore individual files from it.

Two kinds of virtual machine will have issues with storage-level backups. Linux does not support VSS. The storage-level backup requires virtual machines with a Linux guest OS to pause for the host volume snapshot. This is not a problem if in-virtual machine backup is used with virtual machines with Linux guest operating systems. They are simply backed up as if they were physical machines but still retain the other benefits and flexibility of virtualization.

The Hyper-V Writer enables you to protect virtual machine files in a volume. Pass-through disks are not files in a volume; they are a volume. That means that pass-through disks cannot be protected with this simple backup and restoration strategy. This is another reason to use VHDX files instead of pass-through disks.

In summary, the ability of a storage-level backup to restore a virtual machine with its complex workload and data via just a few mouse clicks is attractive. But there are downsides:

  • Protecting an entire virtual machine requires more space than just protecting the business data in the virtual machine.
  • The dependency on the Hyper-V VSS Writer precludes protection of Linux gusts and pass-through disks.

In-Virtual Machine Backup

With this method, you are doing the same kind of backup that you would do with a physical server. The Requestor, or the backup agent, is installed into each and every guest operating system. The backup administrator then has to select every individual file that will be backed up, as opposed to selecting the virtual machine with the storage-level backup type. The backup administrator will also have to protect the system state if they want to protect against losing the entire virtual machine in the case of corruption or accidental deletion.

The benefit of this approach is that it is very granular; the backup administrator, depending on the organization’s policy, can pick as many or as few files/services to protect as desired. A few will choose to back up the system state and the entire file system—doing a storage-level backup would be more efficient! Most who choose the in-virtual machine backup will protect the changing data such as file shares or databases. That strategy can greatly reduce the size of a backup. Selective targeting will prove attractive to those who are concerned with the storage requirements for protecting an entire virtual machine; and you’ll probably have lots of virtual machines!

Historically, the in-virtual machine backup was considered more efficient than the storage-level backup. Only the changing data was protected, probably incrementally, at the block rather than the file level, as opposed to an entire virtual hard disk being protected every time.

Although storage-level backup can safely restore individual files, sometimes that is not granular enough. What if you want to do a brick-level backup of your Exchange or SharePoint databases that enables you to restore individual files or emails? For that, you will need an in-virtual machine backup using an agent that understands these services, such as DPM.

In-virtual machine backup will also be attractive to administrators of Linux virtual machines and virtual machines that use pass-through disks. This is because the Requestor, or backup agent, is installed in the guest OS and treats the guest’s volumes as if they were physical, whether they are (pass-through disk) or not (VHD/X-attached Linux guest).

If you have backed up the system state and the entire file system, you can do a bare-metal restoration within a blank or template virtual machine. If you have backed up just the changing business data, you need to create a new virtual machine, install the necessary software, apply hotfixes and security updates, and then restore the data. This will be slow, but it consumes very little space.

Also consider that restoring a virtual machine from a storage-level backup restores one or a few large files (the virtual hard disks) and a few XML files. Restoring from an in-virtual machine backup restores thousands of small files, each of which must be found, have metadata queried, be confirmed as restored, and so on; restoring fewer, larger files will be much quicker. To summarize in-virtual machine backups,

  • You can protect just the data that you want to protect.
  • Applications can be backed up and restored at an object level, such as SharePoint-stored files or Exchange emails.
  • File systems for which the Hyper-V VSS Writer cannot create snapshots can be protected, such as Linux guests and pass-through disks.

No Backup

As odd and as unsafe as this might sound, some organizations choose not to do backups. Sometimes there are too many virtual machines and too much data to protect. This is truly a rare situation; how many businesses can dispense with backups that are required for protection or regulatory compliance reasons? Those few organizations that do fit in this tiny niche might choose to rely on selective disaster-recovery replication (see Chapter 11, “Disaster Recovery”) instead of a normal backup archive.

A Hybrid Backup Strategy

There are positives and negatives with both the in-virtual machine and the storage-level backup strategies. It is possible to use both approaches to create a single strategy:

  • Perform an infrequent storage-level backup on Hyper-V VSS Writer-compatible virtual machines.
  • Perform a more frequent in-virtual machine backup for Hyper-V VSS Writer-compatible guests, targeting the changing business data.
  • Perform an infrequent in-virtual machine backup for non-Hyper-V VSS Writer-compatible guests, protecting the system state and the entire file system.
  • Do not protect low-priority virtual machines that are used for testing.

If you find that you need to do a restoration, your plan will depend on what has been lost:

Files from a Windows Virtual Machine File Share The files could be restored from the in-virtual machine backup.
A Lost Linux Virtual Machine A bare-metal restoration would have to be done from the in-virtual machine backup.
A Lost Windows Virtual Machine Assuming it uses only VHD or VHDX storage, the virtual machine could be simply restored from the storage-level backup.
A Lost Pass-through Disk The files and folders would be restored from the in-virtual machine backup.

Choosing a Backup Strategy

Which is the right backup strategy for your virtual machines? We hate to say it, but unfortunately this is a case for the consultant’s answer: it depends. In this section, you will look at a few examples. Bear in mind that these are examples and not rules:

A Public Cloud In the hosting world, every cent spent on infrastructure, administration, and support must be passed on to the customer. Each customization to the backup strategy adds cost. If customer A has one policy and customer B has another, then it becomes more expensive to implement a self-service solution and more time-consuming to manage the infrastructure. In a highly competitive world, in which every company with an Internet connection appears to be launching a public-cloud service, offering a low-cost service is critical. Typically, a public-cloud customer is trying to save money. The base service that the customer subscribes to must be economical, to compete not only with other hosting companies, but also with private-cloud alternatives.
In the world of a public cloud, one might choose to extend the pay-for-what-you-consume model into the backup strategy. A simple solution might be to enable self-service in-virtual machine backup and restore. With this approach, customers can choose what data they want to protect and therefore limit the cost of backup. Customers can be completely empowered to select files/folders for backup and be able to restore those files/folders depending on the backup solution that is implemented.
Remember that the backup data is now leaving the confines of your security boundary, and it could be leaving the country. The data may even be entering the legal reach of another country just by being stored in a data center owned by a native of that country (for instance, under the U.S. Patriot Act). How will this impact your security and regulatory requirements?
A Small/Medium Enterprise Windows Server 2012 might be referred to as a cloud operating system by Microsoft, and they might believe that everyone is implementing private clouds, but not everyone is big enough to justify the complexities and costs of a cloud infrastructure. Implementing a private cloud requires a number of integrated management systems, and this alone could be bigger than the business system’s infrastructure.
A small/medium enterprise (SME) might have a small or even an outsourced IT department. SMEs want something that is not complex and that can be used by entry-level IT staff. In this case, a storage-level backup solution could be implemented. Restoring a virtual machine is easy, as is restoring a file. The only need for additional complexity is if the business needs granular restorations for applications such as Exchange or SharePoint—but Microsoft would argue that this SME should be using Office 365 for mail and collaboration services anyway!
A Private Cloud Although IT has little involvement with day-to-day operations of the virtual machines, there will likely be a requirement for regulatory compliance to ensure protection of business data. Administrators will never really know what’s happening inside virtual machines; end users could be installing MySQL, SQL Server, IIS, Tomcat, or anything else that serves the business’s needs. That’s why a private cloud was deployed in the first place. In order to provide a base level of adequate protection, the IT department can choose to protect all virtual machines with a storage-level backup strategy, maybe performing the backups once per night. The new incremental backup support for Hyper-V virtual machines in Windows Server 2012 will minimize the consumption of required archive space.
Bear in mind that organizations that are big enough to have a private cloud are probably likely to have a mixture of Windows Server and Linux guests. It might be unpopular to have Linux guests pausing while their host volume has a snapshot created by the Hyper-V VSS Writer. You would either live with this, or engineer your automation systems to place virtual machines onto dedicated CSVs and deal with the Linux guests by using a different backup strategy.
The self-service nature of the private cloud will require that you empower end users (usually application administrators, testers, or developers) to back up and restore files for themselves. This would mean that you adopt a hybrid backup strategy rather than just doing storage-level backups. The private-cloud infrastructure—System Center 2012, for example—could enable end users to install the protection agent (VSS Requestor), configure backups, and restore files without the involvement of the IT department. However, the storage-level backup is always there as a fallback point just in case the users screw things up!

These are just examples. The backup strategy that an organization chooses to implement will usually be dictated by the board of directors or the CIO, and an engineer or consultant will interpret that to create a solution. There are options for all situations, and no one size will fit all.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.110.194