Why Hyper-V Replica Doesn’t Replace Backups

Once upon a time, insurance was the only product that you purchased in the hopes that you’d never need to use it. Then, Charles Babbage made the horrible mistake of inventing computers, which gave us all so much more to worry about. The good news is that, whereas insurance can’t do much more than pay money when you lose something, computers have the ability to recover data that you lose. The bad news is that, just like insurance, you must spend a lot of money for that power. Not only has the tech world come up with a cornucopia of schemes to protect your data, it’s produced catchy names like “Disaster Recovery” and “Business Continuity” to get you in the money-spending mood. This article compares two of those product categories within the scope of the Hyper-V world: Hyper-V Replica and virtual machine backups.

Meet the Players

If you’re here looking for a quick answer to the question of whether you should use Hyper-V Replica or a virtual machine backup product, the answer is that they are both on the same team but they play in different positions. If you can’t afford to have both, virtual machine backup is your MVP. Hyper-V Replica is certainly valuable, but ultimately nonessential.

What is Hyper-V Replica?

The server editions of Hyper-V include a built-in feature named Hyper-V Replica. It requires a minimum of two separate hosts running Hyper-V. A Hyper-V host periodically sends the changed blocks of a virtual machine to another system. That system maintains a replica of the virtual machine and incorporates the incoming changes. At any time, an administrator can initiate a “failover” event. This causes the replica virtual machine to activate from the point of the last change that it received.

What is the Purpose of Hyper-V Replica?

The general goal of Hyper-V Replica is to provide rapid Disaster Recovery protection to a virtual machine. Disaster Recovery has become more of a broad marketing buzzword than a useful technical term, but it is important here: Hyper-V Replica does not have any other purpose. To use another marketing term, they can also be said to enable Business Continuity. Little time is necessary to start up a replica, making it ideal when extended outages are unacceptable. However, this does not change the core purpose of Hyper-V Replica, nor does it qualify as an automatic edge over virtual machine backup.

What is Virtual Machine Backup?

I am generically using the phrase “virtual machine backup” in this article, not specifically referring to Altaro’s product. A virtual machine backup is a software-created duplicate copy of a virtual machine that is kept in what we usually call a cold condition. It must undergo a restore operation in order to be used. Virtual machine backups require one Hyper-V host and some sort of storage subsystem — it could be magnetic disk, optical disc, magnetic tape, or solid-state storage.

I am deliberately scoping backup to the virtual machine level in this article in order to make the fairest comparison to Hyper-V Replica. There are backup applications available with wider or different targets.

What is the Purpose of Virtual Machine Backup?

At first glance, the purpose of virtual machine backup might seem identical to Hyper-V Replica. Virtual machine backups can certainly provide disaster recovery protection. However, they also allow for multi-layered protection. Not all failures qualify as disasters (although impacted parties may disagree). Equally as important, not all uses for virtual machine backup involve a failure. The purpose of virtual machine backup is to provide an historical series of a virtual machine’s contents.

A Brief Overview of Hyper-V Replica

To understand why Hyper-V Replica can’t replace backup, you’ll first need to see what it truly does. Fortunately, all of the difficult parts are in the configuration and failover processes. A properly running replica system is easy to understand.

The Hyper-V host that owns the “real”, or maybe the “source” virtual machine tracks changes. At short, regular intervals, it transmits those changes to the Hyper-V host that owns the replica.

For this discussion, the most important part is the short, regular interval. You can choose a different value for short, but there can be only one.

Where Hyper-V Replica Falls Behind Backup

As I start this section, I want it made clear that I am not attempting to disparage Hyper-V Replica. It is a fantastic technology. The stated goal of this article is to explain why Hyper-V Replica does not replace virtual machine backup. Therefore, this section will lay out what virtual machine backup gives you that Hyper-V Replica cannot.

Retention

You can instruct Hyper-V Replica to maintain multiple Recovery Points. These are similar to backups in that each one represents a complete virtual machine. You can recover from one of them independently of any other recovery points. However, these recovery points are captured once every hour and you cannot change that interval. Therefore, opting to keep more than a few recovery points will result in a great deal of space utilization in a very short amount of time. All of that space will only represent a very short period in the life of the virtual machine. You won’t be able to maintain a very long history using only Hyper-V Replica.

In contrast, you can easily configure virtual machine backups for much longer retention periods. It’s not strange to encounter retention policies measured in years.

No Separate Copies

When Hyper-V Replica receives new change information, it merges the data directly into the Replica virtual machine. If you are maintaining recovery points, those are essentially change block records that are temporarily spared from the normal delete process. The files generated by the replica system are useless if you separate them from the replica virtual machine’s configuration files and virtual hard disks. More simply: Hyper-V Replica maintains exactly one standalone copy of a virtual machine per target replica server. As long as that copy survives, you can use it to recover from a disaster. Any damage to that copy essentially makes its entire replica architecture pointless.

Virtual machine backup, on the other hand, grants the ability to create multiple distinct copies of a virtual machine. They exist independently. If the backup copy that you want to use is damaged, try another.

No Separate Storage Locations

Since a virtual machine replica only has a single set of data, each of its components exists in only one location. For Hyper-V Replica’s intended purpose, that’s not a problem. But, what if something damages a storage location? What if a drive system fails and corrupts all of its data? What if the replica site suffers a catastrophe?

Most virtual machine backup applications allow you to place your backups on separate storage media. For instance, Altaro Virtual Machine Backup is friendly to the idea of rotating through disks. Others let you cycle through different tapes. With copies on separate physical media, you can put distance between unique copies of your virtual machines’ backups. That allows some to survive when others might not. It prevents one bad event from destroying everything.

All or Nothing

You can either bring up the replica of your virtual machine or not. There really isn’t any in-between. You don’t want to tinker with the VHDX file(s) of a replica in any way because that would break the replica chain. It wouldn’t write new change blocks and you’d be forced to start the replica process anew from the beginning. There are alternatives, of course. You could perform an export on the replica. If the replica has recovery points, you could export one of them. You’d then be able to do whatever you need with the exported copy. It’s a rather messy way to extract data from a replica, but it could work.

Almost all commercial virtual machine backup vendors design their applications to handle situations in which you don’t want complete data restoration. The features list will typically mention “granular” or “file-level” restoration capabilities. You shouldn’t need to endure any intermediary complications.

Limited Support and Interoperability

Microsoft does not support Exchange Server with Hyper-V Replica. Active Directory Domain Services sometimes stutters with Hyper-V Replica. Microsoft will support SQL Server with Hyper-V Replica, under some conditions. That series only included Microsoft products. Your line-of-business applications might have similar problems. Furthermore, each of the three items that I mentioned have their own built-in replication technologies. In all three cases, the native capabilities vastly outpace Hyper-V Replica’s abilities. For starters, they all allow for active/active configurations and transfer much less data than Hyper-V Replica.

I’ve seen a lot of strange things in my time, but I don’t believe that I’ve encountered any software vendor that wouldn’t support a customer taking backups of their product. You sometimes need to go through some documentation to properly restore an application. Some applications, like SQL Server, do include their own backup tools, but you can enhance them with external offerings.

Little Control Over Pacing

Once Hyper-V Replica is running, it just goes. It’s going to ship differences at each configured interval, and that’s all there is to it. You can change the interval and you can pause replication, but you don’t have any other options. Pausing replication for an extended period of time is a poor choice, as catching up might take longer than starting fresh.

One of the many nice things about backup applications is that you have the power to set the schedule. You define when backups run and when they don’t. You can restrict your large backup jobs to quiet hours. If you have a high churn virtual machine and need to take backups that are frequent, but not as frequent as Hyper-V Replica, you have that option. If you have a very small domain that doesn’t change often, you might want to only capture weekly backups of your domain controller. You might decide to interject a one-off backup around major changes. Backup applications allow you to set the pacing of each virtual machine’s backup according to what makes the most sense.

Heavy Configuration Burden

Hyper-V Replica requires a fair bit of effort to properly set up and configure. With basic settings, you can set up each involved host in just a few minutes. If you need to use HTTPS for any reason, that will need some more effort. But, initial configuration is only the beginning. By default, no virtual machines are replicated. You’ll need to touch every virtual machine that you want to be covered by Hyper-V Replica. Yes, you can use PowerShell to ease the burden, but I know how so many of you feel about that.

Even the worst virtual machine backup that I’ve ever used at least tried to make configuring backups easy. They all try to employ some sort of mechanism to set up guests in bulk. The biggest reason that this matters is configuration fatigue. If it takes a great deal of effort to reach an optimal configuration, you might take some shortcuts. Even if you suffer all the way through a difficult initial setup, anyone would be resistant to revisiting the process if something in the environment changes. Whereas you’ll likely find it simple to configure a virtual machine backup program exactly as you like it, most people will have almost no variance in their Hyper-V Replica build — even if it isn’t the best choice.

Higher Software Licensing Costs

If your source virtual machine’s operating system license is covered by Software Assurance, then you can use Hyper-V Replica without any further OS licensing cost. Otherwise, a separate operating system license is required to cover the replica. I don’t keep up with application licensing requirements, but those terms might be even less favorable.

Virtual machine backup applications generate copies that Microsoft labels “cold” backups. Microsoft does not require you to purchase additional licenses for any of their operating systems or applications when they are protected like that. I don’t know of any other vendor that requires it, either.

Higher Hardware Costs

The replica host needs to be powerful enough to run the virtual machines that it hosts. You might choose a system that isn’t quite as powerful as the original, but you can’t take that too far. Most organizations employing Hyper-V Replica tend to build a secondary system that rivals the primary system.

If we accept that the primary use case for a replica system involves the loss of the primary system, we see where backup can save money. Only the most foolish business owners do not carry insurance on at least their server equipment. It’s fair to presume that whatever destroyed them would qualify as a covered event. Smaller organizations commonly rely on that fact as part of their disaster recovery strategy. After a disaster, they order replacement equipment and insurance pays for it. They drag their backup disks out of the bank vault and restore to the new equipment.

Of course, they lose out on time. A Hyper-V Replica system can return you to operational status in a few minutes. If you’ve only got backups, then leaning on local resources might have you running in a few hours at best. However, small budgets lead to compromises. Backup alone is cheaper than Hyper-V Replica alone

The Choice is Clear

I don’t like setting down ultimatums or dictating “best practices”, but this is one case where there is little room for debate. If you can afford and justify both virtual machine backup and Hyper-V Replica, employ both. If you must choose, the only rational option is virtual machine backup.