Seventeen tips for Hyper-V disaster recovery that could save your bacon

The cyber world can be a perilous one. Even though you may never know exactly when a disaster will occur, you should always be ready for any scenario that may unfold across your data center. We have compiled a list of 17 tips that you can use to help you keep your datacenter ready for any type of disaster that may occur.

Your backup schedule depends on the needs of your business and the importance that you assign to each of your VMs. Take a few minutes to establish some kind of schedule—however simple—to ensure that you don’t neglect to perform the backups that are important to you and your team.

Create and maintain an easily accessible document that contains a list of step-by-step procedures that any staff member can read and perform in the event that a VM becomes unresponsive. It should be complete and simple, such that another person can quickly restore any VM.

Backup scripts are often unreliable because they lack sufficient Hyper-V (What is Hyper-V?) and VSS integration, error detection and handling, logging, and verification. If you factor in all the effort that’s necessary to write a comprehensive script with error management, it is much less expensive to buy a full-service backup tool.

Backup tools depend on an array of Windows system APIs and work very closely integrated with Windows. So, when Microsoft releases more product changes or adds new features and APIs, the backup tool must accommodate such modifications. This is especially common with Hyper-V, since Microsoft continues to evolve the methods for managing virtual machines. Use a backup tool that can detect new APIs and Hyper-V extensions.

As virtually all conventional backup guidelines stipulate, you should store any copies of your Hyper-V backup data in a remote physical location—such as a separate server, cloud storage, or remote network share that resides in another office. Very simply, this arrangement all but eliminates the risk of having of single point of failure.

Don’t wait for a critical event to be the first time that you verify VM backup data. It’s important that you verify that you can restore any VM backup immediately after the backup completes. Then, periodically test the entire backup restoration process. You’ll gain peace of mind while ensuring that restored VMs will function properly.

It’s vitally important to apply all Windows Updates to ensure that you have all the latest Microsoft bug fixes and interoperability fixes. Also, Hyper-V is a hot, evolving product. So Microsoft regularly adds more extensions and bug fixes for Hyper-V—many of which pertain to Hyper-V Integration Services. This means that it’s important to apply all Windows Updates within each VM.

Eventually, a disk will fail or a memory segment will become unstable and the result is likely to be some degree of corruption in your data. You can reduce exposure to such potential nightmares by periodically performing RAM and disk verification tests.

Most Windows disk warnings are indications of a bad disk. Unlike so many other notifications, this OS alert is quite valuable as advance notice that the disk has at least one physical defect. Take it seriously, divert any critical data away from this disk, take a  copy of your data, and seek an immediate replacement of this disk.

Typically, backups require plenty of space, and VM backups are often quite large—so more time is necessary to complete the backup. Hyper-V administrators that use backup scripts often struggle to cope with their VM copies, usually because scripts cannot handle deduplication. This means that the backup footprint is much larger than necessary, and will increase exponentially over time. Commercial backup software can help you manage the size of your backups and warn you when space is decreasing below a critical threshold.

Keep 25% or more of space available in the backup media to ensure an adequate buffer. Having plenty of free space also keeps backups fast, since NTFS works more efficiently with plenty of free space. Plenty of RAM is important, also. If a VM is shut down and you attempt a restart, it may fail for lack of sufficient contiguous RAM. Consider keeping the Windows system paging file at a fixed size, on a dedicated disk, at 3 times the size of the physical RAM on the server.

If you set compression too low, you’ll improve speed but waste disk space. Consider switching to the next compression rate increment to improve use of storage space and a slight decrease in performance. Conversely, an excessively high compression rate is likely to decrease CPU speed and only modest gains in the use of your storage space. Experiment to find the balance that’s right for your hardware and data mix.

Consider keeping additional hardware on standby, which you can use exclusively as a replacement in the event that a Hyper-V virtual machine host fails. It’s unwise to rely on another server that you think is capable of sharing the additional Hyper-V load. Without tedious planning and enforcement, you may overburden hardware that tends to fill to capacity in the time that leads up to the failure.

Hyper-V snapshots are different from VM backups. Snapshots create a point-in-time capture of specific state for a virtual machine. Multiple snapshots can easily consume large amounts of disk space, so use them sparingly.

VSS is critical to the Hyper-V backup process, since it manages the states of virtual machines that run during a particular backup. Consequently, it’s critically important that your Hyper-V backup solution makes proper use of VSS.

The default settings for VSS are usually inadequate, and need tuning to ensure efficient and reliable backups. Through the VSS admin user, you can tune the storage limits for each drive. Typically, it’s best to use No Limit or a significantly high value for the write buffer—especially if you expect long backup durations.

Proper communication between a host and its VMs requires stable and current integration services components. Hyper-V Integration Services are critically important to the VM backup process because the VSS backup signal passes from the host through the integration services to the VM. If there’s a glitch, Hyper-V can’t run backups.