Hyper-V Disaster Recovery Planning for Small Business

Backup and disaster recovery are not the same thing

Backup is about being able to recover data. Disaster recovery is about how quickly the business can resume operating after that data, or the host it lives on, is unavailable. A business can have perfect backups and still face days of downtime if there is no plan for where those backups get restored to, who executes the restore, and in what order. Our broader backup and disaster recovery service covers this distinction across all systems, not just Hyper-V.

Setting recovery objectives before choosing technology

Recovery time objective (RTO) is how long the business can tolerate being down. Recovery point objective (RPO) is how much data loss is acceptable, measured in time since the last good backup. These two numbers should come from a conversation with business leadership about what each hour of downtime actually costs, not from whatever a backup platform happens to support by default.

• A line-of-business application the whole team depends on hourly likely needs an RTO measured in hours, not a full business day
• A file server used mainly for archival documents can often tolerate a longer RTO
• Line-of-business databases usually need a tighter RPO than general file storage

Recovery options for a Hyper-V environment

Documenting the failover process

1. List every virtual machine on the host, in priority order of what needs to come back first.
2. Document the exact restore or failover steps for each virtual machine, including where credentials and licence keys are stored.
3. Name who is authorized to declare a disaster and initiate the plan.
4. Include network dependencies, such as DNS, DHCP, and Active Directory, that other virtual machines depend on to function once restored.
5. Keep a printed or offline copy of this plan, since it is not much use if it only exists on the server that just failed.

Ransomware changes the disaster recovery conversation

A ransomware incident is different from a hardware failure because the attacker may have been in the environment for days or weeks before triggering encryption, and they often specifically target backup infrastructure. Disaster recovery planning for Hyper-V needs to account for restoring to a clean, isolated environment rather than the same compromised network, and confirming which backup restore points predate the intrusion. Our guide on ransomware recovery for business covers this scenario in more depth.

Testing the plan, not just writing it

A disaster recovery plan that has never been tested is a guess, not a plan. Run a tabletop exercise at least annually, and a real failover or restore test at least twice a year, to confirm the documented steps actually work and the recovery time matches what was promised.

Sources and further reading

• Canadian Centre for Cyber Security: Developing your incident response plan

Frequently asked questions