This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
public:vmware [2019/08/16 15:54] ronnie.chan [Run Direct Requirements] |
public:vmware [2019/08/16 16:56] ronnie.chan |
||
---|---|---|---|
Line 119: | Line 119: | ||
For backup of virtual machines on vCenter / ESXi servers, make sure the following requirements are met. | For backup of virtual machines on vCenter / ESXi servers, make sure the following requirements are met. | ||
+ | <WRAP indent> | ||
=== ESXi / vCenter Patch Release === | === ESXi / vCenter Patch Release === | ||
Make sure that the latest supported patch release is installed on the vCenter / ESXi hosts to prevent critical issue, such as [[https://kb.vmware.com/kb/2090639|corruption to change tracking data in certain situation]]. | Make sure that the latest supported patch release is installed on the vCenter / ESXi hosts to prevent critical issue, such as [[https://kb.vmware.com/kb/2090639|corruption to change tracking data in certain situation]]. | ||
Line 175: | Line 176: | ||
Refer to this link for information on the supported and compatible virtual machine hardware versions in VMware vSphere: | Refer to this link for information on the supported and compatible virtual machine hardware versions in VMware vSphere: | ||
[[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007240|ESXi/ESX hosts and compatible virtual machine hardware versions list (2007240)]] | [[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007240|ESXi/ESX hosts and compatible virtual machine hardware versions list (2007240)]] | ||
+ | </WRAP> | ||
==== Backup Client Computer Requirements ==== | ==== Backup Client Computer Requirements ==== | ||
Line 194: | Line 196: | ||
Ensure that the following requirements are met by the Backup Client Computer or the vCenter computer: | Ensure that the following requirements are met by the Backup Client Computer or the vCenter computer: | ||
+ | <WRAP indent> | ||
=== Hardware Requirement === | === Hardware Requirement === | ||
* Refer to this [[public:8000_faq:ahsay_hardware_requirement_list_hrl_for_version_8.1_or_above|Hardware Requirement List]] for the list of hardware requirements for AhsayOBM. | * Refer to this [[public:8000_faq:ahsay_hardware_requirement_list_hrl_for_version_8.1_or_above|Hardware Requirement List]] for the list of hardware requirements for AhsayOBM. | ||
Line 261: | Line 264: | ||
=== Backup Quota Requirement === | === Backup Quota Requirement === | ||
Make sure that your AhsayOBM user account has sufficient quota assigned to accommodate the storage for the guest virtual machines. Contact your backup service provider for details. | Make sure that your AhsayOBM user account has sufficient quota assigned to accommodate the storage for the guest virtual machines. Contact your backup service provider for details. | ||
+ | </WRAP> | ||
==== Run Direct Requirements ==== | ==== Run Direct Requirements ==== | ||
Run Direct is a feature that helps reduce disruption and downtime of your production VMs. To utilize the Run Direct feature, ensure that the following requirements are met: | Run Direct is a feature that helps reduce disruption and downtime of your production VMs. To utilize the Run Direct feature, ensure that the following requirements are met: | ||
+ | <WRAP indent> | ||
=== VDDK Backup Mode === | === VDDK Backup Mode === | ||
Run Direct restore is only supported for virtual machine that is backed up in VDDK mode (Virtual Disk Development Kit) for ESX/ESXi and vCenter setup. With VDDK mode, the backup speed is enhanced because the generation of the delta file of the VM are performed directly by the ESX/ESXi or vCenter itself. For being able to backup in VDDK mode, AhsayOBM must be installed on a supported Windows operating system platform. | Run Direct restore is only supported for virtual machine that is backed up in VDDK mode (Virtual Disk Development Kit) for ESX/ESXi and vCenter setup. With VDDK mode, the backup speed is enhanced because the generation of the delta file of the VM are performed directly by the ESX/ESXi or vCenter itself. For being able to backup in VDDK mode, AhsayOBM must be installed on a supported Windows operating system platform. | ||
+ | <WRAP indent> | ||
== License Requirement == | == License Requirement == | ||
The VMware vSphere Storage APIs, which are essential for VDDK backup mode, are included with the VMware vSphere Enterprise Standard, Enterprise and Enterprise Plus Edition. Ensure that the license requirement is met. | The VMware vSphere Storage APIs, which are essential for VDDK backup mode, are included with the VMware vSphere Enterprise Standard, Enterprise and Enterprise Plus Edition. Ensure that the license requirement is met. | ||
Line 306: | Line 312: | ||
This is due to the percent-encoding specified in the URL standard is not supported for ESXi based HTTP(S) file access. To resolve the issue, please rename the corresponding file to avoid special characters. For instructions on renaming a virtual machine, please refer to the following knowledge base article from VMware: https://kb.vmware.com/s/article/2031763 | This is due to the percent-encoding specified in the URL standard is not supported for ESXi based HTTP(S) file access. To resolve the issue, please rename the corresponding file to avoid special characters. For instructions on renaming a virtual machine, please refer to the following knowledge base article from VMware: https://kb.vmware.com/s/article/2031763 | ||
+ | </WRAP> | ||
=== Backup Destination === | === Backup Destination === | ||
Line 333: | Line 340: | ||
- Enter the login credentials of an account with sufficient permission. | - Enter the login credentials of an account with sufficient permission. | ||
- Restart the service afterward. | - Restart the service afterward. | ||
+ | |||
+ | </WRAP> | ||
+ | |||
+ | ==== Non-VDDK Backup Mode Requirements ==== | ||
+ | For VM that cannot be backed up in VDDK mode, non-VDDK backup mode will be used instead. | ||
+ | * Independent Disk (Persistent or Non-persistent) | ||
+ | * Independent disk can only be backed up if the VM is shutdown during a backup. If the VM is started up during the backup, all independent disks selected for backup cannot be backed up. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ===== Best Practices and Recommendations ===== | ||
+ | Please consider the following recommendations for running VMware backup: | ||
+ | |||
+ | ==== Use the latest version of AhsayOBM ==== | ||
+ | Install the latest version of AhsayOBM on the staging machine or Backup Client Computer for backup of VM hosted on a VMware ESX/ESXi server, or on the vCenter server. | ||
+ | |||
+ | Always stay up-to-date when newer version of AhsayOBM is released. To get our latest product and company news through email, please subscribe to our newsletter: https://www.ahsay.com/jsp/en/contact/ahsay-contact.jsp | ||
+ | |||
+ | ==== Install AhsayOBM on a physical staging machine ==== | ||
+ | For best backup and restore performance, it is highly recommended that AhsayOBM is installed on a server grade staging machine or backup client computer with sufficient memory and processing power. As guest VM can be very large, during backups and restore this may involve the compression & encryption of large amounts of data, which can be very resource intensive. | ||
+ | |||
+ | ==== VMware Tools ==== | ||
+ | Make sure the latest version of VMware Tools is installed on each guest VM selected for backup. VMware Tools is used by AhsayOBM to quiesce the guest VMs prior to backing them up to create consistent backup for your VMs. | ||
+ | |||
+ | Quiescing is a process that ensures that the disk data is in a state suitable for backups to reduce the possibility of data corruption upon restore. This is especially important for transaction-based applications running on VMs like MS SQL Server, MS Exchange etc. There are different types of quiescing mechanisms, according to the guest operating systems (e.g. Crash-consistent, File-system-consistent and Application-consistent quiescing). | ||
+ | |||
+ | ==== Do not use a guest VM as a staging machine ==== | ||
+ | Although installing AhsayOBM on a guest VM as a staging machine is possible, the backup and restore will work as on a physical staging machine. This setup is actually inefficient and can lead to possible performance bottlenecks on the VMware host server, as in a VMware host the virtualization layer separates guest VM OS layer and the VMware host physical hardware layer. | ||
+ | As the guest VM operating system does not have direct access to physical hardware where the data resides, a backup agent installed inside the guest VM must go through the virtualization layer to access the guest virtual machine data. | ||
+ | |||
+ | ==== Use the VDDK backup mode / CBT feature ==== | ||
+ | The CBT (Change Block Tracking) feature, which is required for backup in VDDK mode, is supported by VM host with VMware Essentials License (or other paid licenses). The CBT feature, which is utilized for tracking changes of data blocks since the last backup can be done quickly and directly on the VM host. Therefore, the performance of incremental backups is much faster with VDDK backup mode. | ||
+ | |||
+ | Another advantage of VDDK mode is the amount of data backed up is relatively smaller. The used data size of the guest VM is backed up instead of the provisioned size, so the storage cost of these backups will be less. | ||
+ | |||
+ | ==== Proper use of Temporary Directory ==== | ||
+ | The temporary directory of a VMware VM backup set is set to a local volume, and not to a network volume (e.g. to improve I/O performance). | ||
+ | However, the temporary directory should not be set to the system volume (e.g. where the operating system is installed). | ||
+ | Refer to this article for {{public:5247_faq:tips_on_how_to_setup_the_temporary_directory_for_your_backup_set|how to setup the temporary directory}} for your VMware backup set. | ||
+ | |||
+ | ==== Plan your backup schedules carefully to minimize any performance impact on the VMware host ==== | ||
+ | To avoid concentrated disk I/O on the VMware host datastores which will have a negative performance impact on the guest VMs residing on these datastores, you should schedule your backups to limit the number of concurrent VM backups on a host and shared datastores. Hosts typically share the same datastores in virtual environments, and bottlenecks caused by too many simultaneous VM backups on a single datastore will affect all hosts that have VMs running on that datastore. | ||
+ | |||
+ | ==== Backup the guest VMs to more than one destination ==== | ||
+ | To provide maximum data protection and recovery flexibility you should consider to store your guest VM backups in multiple backup destinations, ideally both onsite and offsite locations. Onsite locations on local or network drives will enable very quick recovery even for large guest VMs. While offsite locations will ensure that if there is a site outage, the guest can be restored from another location. | ||
+ | |||
+ | ==== Proper Java memory allocation ==== | ||
+ | Consider to increase the Java memory allocation setting for AhsayOBM (Java heap space) if you are using non-VDDK backup mode. If you are using non-VDDK mode and or Granular restore, it is recommended to increase the Java heap size space to at least 2GB or above for optimal performance. Refer to this KB article for {{8011_faq:how_to_modify_the_java_heap_size_of_ahsayobc|how to modify Java heap size}} for your AhsayOBM client. | ||
+ | |||
+ | ==== Backup whole VM ==== | ||
+ | It is highly recommended to backup the whole VM instead of individual disk for backup of virtual machine with snapshot. | ||
+ | |||
+ | ==== Routine recovery test ==== | ||
+ | Consider to perform routine recovery test to ensure your backup is setup and performed properly. | ||
+ | |||
+ | ==== Disable the memory snapshot or quiesce guest options ==== | ||
+ | Consider to disable the memory snapshot or quiesce guest options when taking snapshot for VMware VM backup, to shorten the time required for the process. | ||
+ | * Snapshot the virtual machine's memory | ||
+ | * Quiesce guest file system (Needs VMware Tools installed) | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ===== Granular Restore Technology ===== | ||
+ | |||
+ | ==== What is Granular Restore Technology ==== | ||
+ | AhsayOBM granular restore technology enables the recovery of individual files from a guest VM without booting up or restoring the whole guest VM first. | ||
+ | |||
+ | Granular restore is one of the available restore options for VMware ESXi/vCenter backup sets from AhsayOBM v8.1.0.0 or above. AhsayOBM makes use of granular restore technology to enable a file level restore from a virtual disk file (VDDK) of guest VM backup possible. It is particularly useful if you only need to restore individual file(s) from a guest VM which would normally take a long time to restore and then startup before you can gain access to the files on the virtual disks. Granular restore gives you a fast and convenient way to recover individual files on a guest VM. | ||
+ | |||
+ | During the granular restore process, the virtual disks of the guest VM can be mounted on the Windows machine as a local drive. This will allow the individual files on the virtual disks to be viewed via the file explorer within AhsayOBM or from the Windows File Explorer on the Windows machine you are performing the restore on, without having to restore the entire virtual machine. Granular restore can only mount virtual disks if the guest VM is running on a Windows Platform and it is supported for all backup destinations, i.e. AhsayCBS, Cloud storage, or Local/Network drives. The mounting of Linux/Unix file systems from virtual disk file is currently not available due to limitations of the file system drivers. | ||
+ | |||
+ | <WRAP prewrap> | ||
+ | <code> | ||
+ | IMPORTANT | ||
+ | Granular Restore requires an additional OpenDirect / Granular Restore add-on module license to work. Contact your backup service provider for further details. | ||
+ | </code> | ||
+ | </WRAP> | ||
+ | |||
+ | ==== How does Granular Restore work ==== | ||
+ | |||
+ | {{public:ahsay_wiki_module_vmware_granular_restore.png?800}} | ||
+ | |||
+ | ==== Benefits of using Granular Restore ==== | ||
+ | |||
+ | Granular restore allows you to quickly mount virtual disk(s) directly from the backup file of a guest VM, so that individual files from virtual disk(s) can be exposed via the file explorer on AhsayOBM, or to be copied from the file explorer on to a 64 bit Windows machine you are performing the restore. | ||
+ | |||
+ | <WRAP indent> | ||
+ | |||
+ | === Granular Restore === | ||
+ | ^ Pro ^ Con ^ | ||
+ | | **Restore of Entire Guest VM Not Required**\\ Compared to a traditional restore where you have to restore the entire guest VM first, before you can access any individual files/folders, granular restore allows you to view and download individual files, without having to restore the entire guest VM first.\\ \\ **Ability to Restore Selected Files**\\ In some cases, you may only need to restore a few individual file(s) from the guest VM, therefore, granular restore gives you a fast, convenient, and flexible tool to restore selected file(s) from a guest VM quickly.\\ \\ **Only One Backup Set Required**\\ With traditional restore methods, if you wish to restore individual file(s) from a guest VM, you will have to create two different backup sets; a VMware guest VM backup set and a separate file backup set for the file(s) you wish to restore. You will require an additional AhsayOBM installation on the guest VM environment, with Granular Restore feature, only one backup set is required.\\ * Fewer CAL (Client Access License) required - you will only need one AhsayOBM CAL to perform guest VM, Run Direct, and Granular restore. \\ * Less storage space required - as you only need to provision storage for one backup set.\\ * Less backup time required - As only one backup job needs to run. \\ * Less time spent on administration - As there are fewer backup sets to maintain. | **No Encryption and Compression**\\ To ensure optimal restore performance, the backup of the guest VM will NOT be encrypted and compressed, therefore, you may have to take this factor in consideration when using this restore method. | | ||
+ | |||
+ | === Traditional Restore === | ||
+ | The traditional restore method for guest VMs, restores the entire backup files to either the original VM location or another standby location. The files or data on the guest VM can only be accessed once the guest VM has been fully recovered and booted up. | ||
+ | |||
+ | ^ Pro ^ Con ^ | ||
+ | | **Backup with Compression and Encryption**\\ Guest VM is encrypted and compressed, therefore is in smaller file size, and encrypted before being uploaded to the backup destination. | **Slower recovery**\\ As the entire guest VM has to be restored before you can access any of its file(s) or data, the restore time could be long if the guest VM size is large.\\ \\ **Two Backup Sets and CALs Required**\\ If you only wish to restore individual files from VM, two separate backup sets are required, one for the VM image and the other for the individual files, and therefore two CAL (client access licenses) are required. | | ||
+ | </WRAP> | ||
+ | |||
+ | ==== Requirements ==== | ||
+ | |||
+ | <WRAP indent> | ||
+ | === Supported Backup Modules === | ||
+ | Granular restore is supported on VMware backup sets created and backed up using AhsayOBM v8.1.0.0 or above installed on a Windows platform with the Granular Restore feature enabled on the backup set. | ||
+ | |||
+ | === License Requirements === | ||
+ | An OpenDirect / Granular restore add-on module license is required per backup set for this feature to work. Contact your backup service provider for more details. | ||
+ | |||
+ | === Backup Quota Storage === | ||
+ | As compression is not enabled for Granular backup sets, to optimize restore performance, the storage quota required will be higher than non-Granular backup sets. Contact your backup service provider for details. | ||
+ | |||
+ | === Operating System === | ||
+ | AhsayOBM must be installed on a 64 bit Windows machine as libraries for Granular only supports 64 bit Windows operating system for VMware ESXi/VCenter. AhsayOBM must be installed on the following Windows Operating Systems: | ||
+ | | Windows 2008 R2 SP1 or above | Windows 2012 | Windows 2012 R2 | | ||
+ | | Windows 2016 | Windows 7 SP1 or above | Windows 8 | | ||
+ | | Windows 8.1 | Windows 10 | | | ||
+ | |||
+ | === Temporary Directory Requirement === | ||
+ | Temporary Directory Folder should have at least the same available size as the guest VM to be restored and should be located on a local drive to ensure optimal performance. | ||
+ | |||
+ | === Available Spare Drive Letter === | ||
+ | One spare drive letter must be available on the Windows machine for the granular restore process, as the VDDK virtual disk is mounted on Windows as a logical drive. AhsayOBM will automatically take the next available drive letter in alphabetical order for the mounted virtual disk. | ||
+ | |||
+ | <WRAP prewrap> | ||
+ | <code> | ||
+ | NOTE | ||
+ | The Windows drive letters A, B, and C are not used by granular restore. | ||
+ | The granular restore assigned drive letter(s) will be released once you exit from AhsayOBM UI. | ||
+ | </code> | ||
+ | </WRAP> | ||
+ | |||
+ | === Network Requirements === | ||
+ | Recommended minimum network speed is at least 100Mbps download speed. | ||
+ | |||
+ | The network bandwidth requirements will increase in proportion to the size of the guest VM 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 network speed test website (e.g. [[http://www.speedtest.net]]) to get an idea of the actual bandwidth of the machine. | ||
+ | |||
+ | === Permissions === | ||
+ | * The Windows login account used for installation and operation of the AhsayOBM client machine requires Administrator privileges. | ||
+ | * For Granular Restore, Windows User Account Control (UAC) must be disabled. | ||
+ | |||
+ | === Other Dependencies === | ||
+ | The following dependencies are restore related and therefore they will be checked by AhsayOBM only when granular restore is performed. Absence of these elements will not affect the backup job but would cause the restore to fail. | ||
+ | |||
+ | * [[https://www.microsoft.com/en-us/download/details.aspx?id=48145|Microsoft Visual C++ 2015 Redistributable (x86) / (x64)]] | ||
+ | * [[https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows|Update for Universal C Runtime in Windows]] | ||
+ | * [[https://docs.microsoft.com/en-us/security-updates/securityadvisories/2015/3033929|Microsoft Security Advisory 3033929 (For Windows 7 and Windows Server 2008 R2 only)]] | ||
+ | |||
+ | |||
+ | </WRAP> | ||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
===== Documentation ===== | ===== Documentation ===== | ||