BS_Create_hyperv

in Tips

How to Create Hyper-V Backup Set







Backup Requirements

AhsayOBM Requirements

Please ensure that the following requirements are met by the AhsayOBM



  1. AhsayOBM is installed on the Hyper-V server. For Hyper-V Cluster environments AhsayOBM is installed on all Cluster nodes.

  2. 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).

  3. AhsayOBM user account has sufficient Hyper-V add-on modules or CPU sockets assigned. Hyper-V Cluster backup sets will require one %edition_name% license per node.

  4. Storage destination has sufficient quota assigned to accommodate the storage of the guest virtual machines.

    Hyper-V guest virtual machines contain three types of virtual disks:

    • Fixed Hard Disk.

    • Dynamic Hard Disk.

    • Differencing Hard Disk.


    When AhsayOBM backs up a Hyper-V guest virtual machines for an initial or subsequent full backup jobs:

    • Using Fixed Hard Disks will back up the provisioned size, i.e. for a 500GB fixed virtual hard disk, 500GB will be backed up to the storage designation.

    • Using Dynamic Hard Disk or Differencing Hard Disk will back up the used size, i.e. for a 500GB dynamic virtual hard disk, 20GB will be backed up to the storage designation if only 20GB is used.


  5. The default Java heap size setting on %edition_name% 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 file is a memory intensive process, therefore, it is recommended to increase the Java heap size to be at least 4096MB. The actual required Java heap size is subject to various factors including files size, delta mode, backup frequency, etc.

  6. The temporary directory folder is used by AhsayOBM 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 is recommended to be located on a local drive with plenty of free disk space but not on the Windows system C:\ drive.
    For Hyper-V 2008 R2, 2012, and 2012 R2, the temporary directory folder can only be set to local drive, and neither network or CSV path can be supported which is determined by the limitation of AhsayOBM CBT service. Only Hyper-V 2016 supports local, network and CSV volumes for temporary directory folder.

  7. AhsayOBM UI must be running when a guest virtual machine is started using Run Direct Restore or when migration process is running.

  8. 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 compression type and data encryption settings of backup set will only be applied to AhsayCBS, SFTP/FTP, or Cloud storage destinations.

  9. For ease of restore, it is recommended to back up the whole guest machine (all the virtual disks) rather than individual virtual disks.

  10. MS Windows system Backup is unable to create image of drives that are greater than 2TB on Windows 2008, 2008 R2 & 2011, due to the limitation of MS wbadmin using VHD format that is used in creating the image. The limitation in Windows 2012 has been increased to 64TB.

    For details, please refer to:
    https://support.microsoft.com/en-us/help/2696906/backup-fails-in-windows-7-when-trying-to-create-a-system-image

  11. Make sure NFS service has started for Run Direct to operate. If Run Direct is running on network drive, the login must have sufficient permission to access the network resources.

Hyper-V Server Requirements

Please ensure that the following requirements are met by the Hyper-V server



  1. 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.

  2. The Hyper-V services are started on the server. For Hyper-V Cluster environments the Hyper-V services are started on all Cluster nodes.

  3. 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.

    vssadmin list writers

    Look for the script:

    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


  4. If Integration services is not installed / updated on a guest virtual machine or the guest operating system is not supported by Integration Services, the corresponding virtual machine will be paused or go into a saved state during the snapshot process for both backup and restore, and resume when the snapshot is completed. Furthermore, the corresponding virtual machine uptime will also be reset to 00:00:00 in the Hyper-V Manager.

  5. Installing or updating Integration Services guest virtual machine(s) may require a restart of the guest virtual machine to complete the installation.

  6. For Hyper-V 2008 R2 server in order to use Run Direct restore feature, the “Microsoft Security Advisory 3033929″ security update must be installed.

    For details, please refer to:
    https://support.microsoft.com/en-us/kb/3033929

  7. For Run Direct Hyper-V Cluster backup sets, the storage destination must be accessible by all Hyper-V nodes.

  8. For Hyper-V Cluster backup sets, the guest virtual machines must be created and managed by the Failover Cluster Manager.

Hyper-V Backup Methods

AhsayOBM v7 supports two methods for Hyper-V guest VM backup, VM Snapshot and Saved State.



  1. VM Snapshot
  2. The VM snapshot method is the preferred backup option, as it supports live guest VM backups. This means guest VM will not be put into a saved state when a VSS snapshot is taken during a backup job. So it will not affect the availability of any application or services running on the guest VM every time a backup job is performed.

    !

    If the VM Snapshot method cannot be used, %edition_name% will automatically use the Saved State method.

    VM Snapshot Method Requirements


    • The guest VM must be running.

    • Integration services must be enabled on the guest VM.

    • The Hyper-V Volume Shadow Copy Requestor service is running on the guest VM installed with Windows operating system.

      For details, please refer to:
      https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/integration-services#hyper-v-volume-shadow-copy-requestor

    • For guest VMs installed with Linux/FreeBSD operating systems, the VSS Snapshot daemon is required for live backups, not all Linux/FreeBSD versions support live backup on Hyper-V. For example, only FreeBSD 11.1 supports live backup; while for Ubuntu, version 14.04 LTS to 17.04 LTS supports live backups.

      For details, please refer to:
      https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-linux-and-freebsd-virtual-machines-for-hyper-v-on-windows

    • The guest VM volumes must use a file system which supports the use of VSS snapshots, for example NTFS.

    • The guest VMs snapshot file location must be set to the same volume in the Hyper-V as the VHD file(s).

    • The guest VM volumes have to reside on basic disks. Dynamic disks cannot be used within the guest VM.
    • !

      Some older Windows operating systems installed on guest VM’s which do not support either Integration Services or the Hyper-V Volume Shadow Copy Requestor Service, will not support VM snapshot method, for example, Microsoft Windows 2000, Windows XP, or older Linux/FreeBSD versions.


  3. Saved State
  4. When the Saved State method is used, the guest VM is placed into a saved state while the VSS snapshot is created (effectively shut down), and the duration depends on the size of guest VM. The downside is it may affect the availability of any application or services running on the guest VM every time a backup job is performed.

CBT Requirement

Since AhsayOBM version 7.9, a new service CBT Cluster Services (Ahsay Online Backup Manager) is installed and enabled upon installation / upgrade to version AhsayOBM v7.9.0.0 or above.

Since AhsayOBM v3.1.0.0, a new service CBT Cluster Services (CloudBacko Pro) is installed and enabled upon installation / upgrade to AhsayOBM v3.1.0.0 or above.


  1. CBT (Changed Block Tracking) is used to optimize incremental backups of virtual machines by keeping a log of the blocks of data that have changed since the previous snapshot. When AhsayOBM performs a backup, CBT feature can request transmissions of only the blocks that changed since the last backup, or the blocks in use.
  2. !

    From version 7.15.0.0 onwards, CBT service is supported on all the backup destinations for AhsayOBM instead of only RunDirect related local destination.

  3. CBT cluster service is only installed on Windows x64 machine.

  4. Check if CBTFilter is enabled. This can be verified by running the net start CBTFilter command.

    C:\Users\Administrator>net start CBTFilter
    The requested service has already been started.
    More help is available by typing NET HELPMSG 2182.


  5. CBT Cluster Service and CBTFilter will NOT be installed on Windows Server 2016 where a built-in system called Resilient Change Tracking (RCT) will be used instead.

Windows Server 2016 Requirement


  1. RCT Requirement


  2. Guest VM Dependencies Requirements
  3. To get full use of Hyper-V, install the appropriate linux-tools and linux-cloud-tools packages to install tools and daemons, i.e. VSS Snapshot Daemon, for use with virtual machines.

    For details, please refer to: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-linux-and-freebsd-virtual-machines-for-hyper-v-on-windows

Limitations

The followings are the limitations of the MS Hyper-V backup module:



  1. Backup of guest machines located on a SMB 3.0 shares is not supported.

  2. Backup of virtual machine with pass through disk (directly attached physical disk) is not supported.

  3. For backup of individual virtual disk, the restored virtual machine does not support the reversion of previous snapshots, if the snapshot contains disks which are not previously backed up by AhsayOBM.

  4. A guest virtual machine can only be restored to the Hyper-V server with the same version, i.e. backup of a guest on Hyper-V 2012 R2 server cannot be restored to Hyper-V 2008 R2 Server, and vice versa.

  5. The guest virtual machine will not start up if the virtual disk containing the guest operating system that is not restored.

  6. Restore of individual virtual disks is only supported using the Restore raw file option for a virtual disk with no snapshots.

    !

    This will require modification of Hyper-V guest configuration files, and this only should be done if you have in-depth knowledge and understanding of Hyper-V, otherwise the guest virtual machine may not startup properly.


  7. Restore to an Alternate location can only be performed on one guest virtual machine at a time.

  8. Restored guest virtual machines using Run Direct containing a saved state will not automatically power on. The saved state must be manually deleted in Hyper-V Manager and the guest must be powered on manually.

  9. For Run Direct enabled backup sets, the storage destination is restricted to Local, Mapped, or Removable Drive.

  10. When a guest virtual machine is started in a Run Direct instance being stopped, any changes made within the guest environment will be lost, if the guest virtual is not migrated to the Hyper-V Server using the “Auto migrate after Run Direct is running” option.

  11. When a guest virtual machine is started using Run Direct Restore, all backup jobs (manual, scheduled, and continuous) for the related backup set will be skipped.

  12. When a guest virtual machine is started using Run Direct Restore, the following features are not available for the backup set: Data Integrity Check, Space Freeing Up, or Delete Backup Data.

  13. Granular Restore is NOT supported on “Windows 7 SP1″ or “Windows Server 2008 R2 SP1″.

Granular Restore Requirements

Please ensure that the following requirements are met for Granular Restore to use:


  1. Granular restore is only supported on Hyper-V backup sets created and backed up using AhsayOBM v7.13.0.0 or above on Windows platforms with Granular Restore feature enabled.
  2. Granular restore is only supported on Hyper-V backup sets created and backed up using AhsayOBM v3.1.0.0 or above on Windows platforms with Granular Restore feature enabled.
  3. OpenDirect / Granular Restore add-on module is required per backup set for this feature to work. Contact your backup service provider for more details.
  4. Both compression and encryption are not enabled for Granular restore backup sets. To optimize restore performance the storage quota required will be higher than non-Granular Restore backup sets. Contact your backup service provider for details.

  5. Temporary Directory Folder should have at least the same available size as the backup image to be restored.

  6. One spare drive letter must be available for the Granular restore process as the VHD image is mounted on Windows as a logical drive by AhsayOBM and it will automatically take the next available drive letter in alphabetical order for the mounted volume. (Drive letters A, B, and C will not be used.)

  7. Recommended minimum network speed is at least 100Mbits per second download speed. Network bandwidth should be increased in proportion to the guest virtual machine size and the incremental delta chain length to ensure optimal performance. Working with limited network bandwidth may severely affect the Granular restore performance.
    You can use an online speed connection testing site (e.g. http://www.speedtest.net) to test your connection speed.

  8. The following dependencies are restore related and therefore they will be checked by AhsayOBM only when an Granular restore is performed. Absence of these elements will not affect the backup job but would cause the restore to fail.


  9. The Windows login account used for installation and operation of the %edition_name% client machine requires Administrator privileges
  10. Create a MS Hyper-V Backup Set

    Field Description
    Name This is the name of the backup set. You can create a meaningful name for it.
    Backup Type Select the backup set type from the drop down box.
    Version Select the version of the Hyper-V server.

    Steps:


    1. Type in a meaningful backup set name.

    2. Select the backup set type as MS Hyper-V backup.

    3. Select the correct version of the Hyper-V Server.

    4. Click [Next] button to continue.


    Setup example for MS Hyper-V cluster:

    Assumption:


    1. There are 3 nodes in the Hyper-V cluster setup, in the following example, we called it node1, node2 and node3.

    2. All the 3 nodes are located in the same timezone.

    3. They can connect to the same backup location, eg: a local shared destination with the same access permission.

    Notes:


    1. As the same backup set setting is needed to apply on all the machines when

      • the backup set is created or

      • any changes is applied to the backup set,

        eg:

        • change backup schedule

        • backup source selection

        • backup destination


        It is required to export the settings from the node with the last changes and then import to all other nodes.
        Otherwise, the backup set settings are not synchronized.

        eg:

        If the backup schedule is changed on node1, if the backup set is not synchronized, other nodes will keep running on an old backup schedule and may cause the backup job does not reflect to the actual servers status at the backup moment.



    2. When the settings is imported from other nodes, all the backup set settings on the node will be overwritten.

    Steps:


    1. Create/modify Hyper-V cluster backup set in node1, make sure the schedule backup is turned on.

    2. Export settings from node1 in [Utilities] > [Ex/Import Settings]

    3. Import the node1 settings into node2 in [Utilities] > [Ex/Import Settings]

    4. Enable the Schedule backup in node2.

    5. Export settings from node2 in [Utilities] > [Ex/Import Settings]

    6. Import the node2 settings into node3 in [Utilities] > [Ex/Import Settings]

    7. Enable the Schedule backup in node3.

    8. Export settings from node3 in [Utilities] > [Ex/Import Settings]

    9. Import the node3 settings into node1 and node2 in [Utilities] > [Ex/Import Settings]