This is an old revision of the document!
AhsayOBM allows you to back up individual Guest VMs in your Microsoft Hyper-V Host with the MS Exchange Mail Level Backup Set.
The following high level system architecture diagram illustrates the major elements involved in the backup process of a Hyper-V host with AhsayOBM and AhsayCBS.
The latest version of AhsayOBM must be installed on the Hyper-V server. For Hyper-V Cluster environment the latest version of AhsayOBM must be installed on all Cluster nodes.
AhsayOBM user account created on AhsayCBS must have sufficient Hyper-V add-on modules or CPU sockets assigned. Hyper-V Cluster backup sets will require one AhsayOBM license per node.
AhsayOBM user account has sufficient quota assigned to accommodate the storage of the guest virtual machines. (Please contact your backup service provider for details).
Hyper-V guest virtual machines contain three types of virtual disks:
When AhsayOBM backs up a Hyper-V guest virtual machines for an initial or subsequent full backup jobs:
The default Java heap size setting on AhsayOBM is 2048MB, for Hyper-V backups it is highly recommended to increase the Java heap size setting to improve backup and restore performance. (The actual heap size is dependent on amount of free memory available on your Hyper-V server).
Delta generation of large VHD files is a memory intensive process; therefore, it is recommended that the Java heap size to be at least 2048MB - 4096MB. The actual required Java heap size is subject to various factors including files size, delta mode, backup frequency, etc.
Refer to this KB article for how to configure Java heap size on your AhsayOBM.
For stand-alone Hyper-V server, AhsayOBM uses the temporary folder for storing backup set index files and any incremental or differential delta files generated during a backup job. To ensure optimal backup / restore performance, it should be located on a local drive with plenty of free disk space. It should not be on the Windows system C:\ drive.
NOTE For Hyper-V server in Failover Cluster environment, the temporary folder must be set to a network shared path accessible to all cluster nodes, or a Cluster Shared Volume.
AhsayOBM UI must be running when a guest virtual machine is started using Run Direct Restore or when migration process is running.
Make sure NFS service has started for Run Direct to operate. If the backup destination is located on network drive, the logon account must have sufficient permission to access the network resources.
The operating system account for setting up the Hyper-V / Hyper-V Cluster backup set must have administrator permission (e.g. administrative to access the cluster storage).
For Granular Restore, Windows User Account Control (UAC) must be disabled.
For local, mapped drive, or removable drive storage destinations with Run Direct enabled, the compression type will always be set to No Compression and data encryption is disabled to ensure optimal backup and restore performance. The backup set compression type and data encryption settings will only be applied to CBS, SFTP/FTP, or Cloud storage destinations.
For ease of restore it is recommended to back up the whole guest machine (all the virtual disks) rather than individual virtual disks.
The Hyper-V management tools are installed on the server. For Hyper-V Cluster environments Hyper-V management tools is installed on all Cluster nodes.
The Hyper-V services are started on the server. For Hyper-V Cluster environments the Hyper-V services are started on all Cluster nodes.
Example: Windows 2008 R2 Hyper-V
The Microsoft Hyper-V VSS Writer is installed and running on the Hyper-V server and the writer state is Stable. This can be verified by running the vssadmin list writers command.
Example:
C:\Users\Administrator>vssadmin list writers vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2005 Microsoft Corp. Writer name: 'Task Scheduler Writer' Writer Id: {d61d61c8-d73a-4eee-8cdd-f6f9786b7124} Writer Instance Id: {1bddd48e-5052-49db-9b07-b96f96727e6b} State: [1] Stable Last error: No error Writer name: 'VSS Metadata Store Writer' Writer Id: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06} Writer Instance Id: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93} State: [1] Stable Last error: No error Writer name: 'Performance Counters Writer' Writer Id: {0bada1de-01a9-4625-8278-69e735f39dd2} Writer Instance Id: {f0086dda-9efc-47c5-8eb6-a944c3d09381} State: [1] Stable Last error: No error Writer name: 'System Writer' Writer Id: {e8132975-6f93-4464-a53e-1050253ae220} Writer Instance Id: {8de7ed2b-8d69-43dd-beec-5bfb79b9691c} State: [1] Stable Last error: No error Writer name: 'SqlServerWriter' Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a} Writer Instance Id: {1f668bf9-38d6-48e8-81c4-2df60a3fab57} State: [1] Stable Last error: No error Writer name: 'ASR Writer' Writer Id: {be000cbe-11fe-4426-9c58-531aa6355fc4} Writer Instance Id: {01499d55-61da-45bc-9a1e-76161065630f} State: [1] Stable Last error: No error Writer name: 'Microsoft Hyper-V VSS Writer' Writer Id: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de} Writer Instance Id: {a51919e3-0256-4ecf-8530-2f600de6ea68} State: [1] Stable Last error: No error Writer name: 'COM+ REGDB Writer' Writer Id: {542da469-d3e1-473c-9f4f-7847f01fc64f} Writer Instance Id: {7303813b-b22e-4967-87a3-4c6a42f861c4} State: [1] Stable Last error: No error Writer name: 'Shadow Copy Optimization Writer' Writer Id: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f} Writer Instance Id: {d3199397-ec58-4e57-ad04-e0df345b5e68} State: [1] Stable Last error: No error Writer name: 'Registry Writer' Writer Id: {afbab4a2-367d-4d15-a586-71dbb18f8485} Writer Instance Id: {25428453-2ded-4204-800f-e87204f2508a} State: [1] Stable Last error: No error Writer name: 'BITS Writer' Writer Id: {4969d978-be47-48b0-b100-f328f07ac1e0} Writer Instance Id: {78fa3f1e-d706-4982-a826-32523ec9a305} State: [1] Stable Last error: No error Writer name: 'WMI Writer' Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0} Writer Instance Id: {3efcf721-d590-4e50-9a37-845939ca51e0} State: [1] Stable Last error: No error
# lsmod | grep hv hv_netvsc 23667 0 hv_utils 7012 0 hv_storvsc 10022 2 hv_vmbus 91567 4 hv_netvsc,hv_utils,hid_hyperv,hv_storvsc # ps -ef|grep hv root 267 2 0 18:07 ? 00:00:00 [hv_vmbus_con/0] root 268 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 269 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 270 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 271 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 272 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 273 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 274 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 275 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 276 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 277 2 0 18:07 ? 00:00:00 [hv_vmbus_ctl/0] root 1174 1 0 18:07 ? 00:00:00 /usr/sbin/hv_kvp_daemon root 1185 1 0 18:07 ? 00:00:00 /usr/sbin/hv_vss_daemon root 1332 1316 0 18:11 pts/0 00:00:00 grep hv
For Hyper-V 2008 R2 server in order to use Run Direct restore feature the “Microsoft Security Advisory 3033929” security update must be installed.
Please refer to the following KB article from Microsoft for further details: https://support.microsoft.com/en-us/kb/3033929
For Run Direct Hyper-V Cluster backup sets the storage destination must be accessible by all Hyper-V nodes.
For Hyper-V Cluster backup sets the guest virtual machines must be created and managed by the Failover Cluster Manager.