When you take into account host data, volumes, domains, disks, VSS writers, services, and the problems that may follow, backing up Hyper-V virtual machines can become challenging. We've compiled a list of 10 best practice guidelines for Hyper-V backups in order to keep your virtual machines' backups as straightforward and reliable as their surroundings.
1. Don't add any additional roles or programs to your Hyper-V host.
The sole purpose of your physical Hyper-V host server should be to serve as the Hyper-V host server. It shouldn't serve double duty as an application server, a DNS server, or even worse, a file server. Software and data not compatible with Hyper-V should be on another physical server or one of the Hyper-V guests (VMs).
If you don't heed this advice, host-level backups may become more difficult, and the host server's stability may suffer. The guests may be impacted by any issues with other roles or applications running on the Hyper-V host. All of your Hyper-V guests (VMs) and the services they offer could go down as a result of even something as simple as an application patch requiring a physical server reboot.
2. Only provide each guest with a single role or application.
One role or application should be the only thing that each Hyper-V guest (VM) has. Another guest can be created with relative ease, and dedicated environments are what virtual machines excel at.
Having only one role or application per guest simplifies backups so that you can:
- In a controlled manner, recover customers and services.
- Distribute backup personnel and licenses
- Execute granular data restorations inside Hyper-V guests.
3. Put the guest first only backups for Hyper-V
The platform, architecture, and procedures necessary to support and maintain your Hyper-V guests are provided by the Hyper-V host (VMs). A bare-metal backup of the complete physical server is a good idea, but you should also consider making a copy of only the Hyper-V guests because they include all the information you require and take up less space. Simply reinstall Hyper-V Server and utilize the backup to add the guests back for recovery. A decent balance can be achieved by combining daily "guest-only" backups with a weekly full-metal archive backup schedule.
4. Allow services for Hyper-V integration.
The term "crash-consistent" refers to the ability of backup software to use a VSS snapshot to preserve a copy of data that has changed during the backup and ensure that all of the data in the backup reflects the data as it was at a particular point in time. Application-consistent denotes that a VSS-Aware application verifies the accuracy of its own files in the VSS snapshot. The snapshot is more accurate and consistent since it takes into account things like data that is in memory and open database transactions. This is crucial, especially for programs like SQL and Exchange.
You will only receive a crash-consistent backup of the guest if you don't have Hyper-V Integration Services installed because a guest won't be aware that a backup process is occurring on the host. In the Hyper-V guest, you may create online, application-consistent backups of programs like Exchange and SQL by installing the Hyper-V Integration Services on the host and turning it on in the guest.
5. Use the Hyper-V host server to perform the backup, not the guest
Installing your backup program on the Hyper-V host (physical server) and backing up the guests from there is the simplest way to secure Hyper-V guests. In this manner, you are able to back up numerous guests at once using a single backup process. Because you only need one backup license, doing this will also save you money. Vinchin needs a single host license, unlike some backup systems that could require backup agents for every guest.
The Hyper-V VSS writer on the host, where the backup is executing, can connect with an application (Exchange, SQL) VSS writer on the guest so that you get application-consistent backups of all guests - in a single backup. This is possible as long as Hyper-V integration services are available.
6. Avoid directly backing up a CSV device.
You shouldn't back up the cluster shared volume (CSV) directly if your guests use it because the Hyper-V Server's VSS writer won't be involved. Back up the Hyper-V Server so that data on the cluster shared disk can be backed up in an application-consistent manner using the Hyper-V VSS writer.
7. Join a workgroup with the Hyper-V host.
When one of your Hyper-V guests (VMs) serves as the domain controller, this protection is in effect. It's possible that you won't be able to connect to your Hyper-V Server if that domain controller guest goes down and the host is on the same domain.
8. Make a full-volume backup
It is recommended to back up the entire volume while creating a Hyper-V image backup (i.e., Vinchin System Protection backup). This can speed up backups and enhance the performance of incremental image backups.
Your non-production guests (VMs) should be on a distinct volume so that you can exclude them from the backup if you adhere to this best practice and back up the entire disk. Both backups and restores become more difficult and ineffective when guest categories or guest files are spread across drives.
Tip: test your VMware backups with the upcoming release of Vinchin 7.0 in an independent virtual lab effectively.
9. Separate system and visitor data on different volumes.
Hyper-V guest data shouldn't be kept on the disk that Microsoft Hyper-V Server is installed on or the volume that houses the actual server's operating system (VHDs). For instance, your Hyper-V visitors shouldn't use C: drive if your real server does. They should have separate volumes, and those volumes shouldn't include system files like the swap file for the actual server.
This is crucial to remove conflicts and improving performance. Additionally, it's crucial for backups because you need to be able to use entire volumes for "guest only" backups.
10. Employ static virtual drives
The performance and data integrity of your Hyper-V host server, both of which are crucial for backups, might be affected by the types of disks you employ. Your Hyper-V host server ought to employ fixed virtual disks as a result. Pass-through disks are more complicated, prevent VM snapshots and Hyper-V replicas, and have a performance and storage overhead. Dynamic and differencing disks further add complexity. Better performance and data integrity are made possible by fixed disks. Better backups are the result.
Hyper-V backups with Vinchin Backup & Recovery
Visit our Hyper-V documentation pages to find out more about Vinchin Backup & Recovery's Hyper-V backups! With Add-ons, Vinchin can conduct granular restores of data within virtual machines as well as granular restores of mail items from Exchange Servers, and it already supports Hyper-V out of the box.
No comments yet