This is an old revision of the document!
AhsayOBM allows you to back up individual Guest virtual machines (VMs) on your VMware hosts with our VMware Backup Set. VMware Guest VM backup module of AhsayOBM provides you with a set of tools to perform hot backup of your running VMs in VMware environment.
When you need to restore a VM, besides restoring the whole VM image, you can also utilize the built-in Run Direct feature to spin-up the VM in minutes without the need to restore the whole VM first. Moreover, our Granular Restore feature allows you to mount the virtual disks in a backed up VM and restore individual files within the VM without the need to spin-up the VM first.
Below is the system architecture diagram illustrating the major elements involved in the backup process among the VMware server, AhsayOBM and AhsayCBS. In this user guide, we will focus on the software installation, as well as the end-to-end backup and restore process using the AhsayOBM as a client backup software.
Run Direct is a feature that helps reduce disruption and downtime of your production VMs. Unlike normal VM restore procedure where a VM is extracted from backup files and copied to the production storage, which can take hours to complete. Restore with Run Direct can instantly power up a VM by running it directly from the backup files in the backup destination and the VM can be put into production.
When a Run Direct restore is performed, the backup destination is mounted as an NFS datastore from the VMware host, where the VM is run directly from the backup files.
The backup destination can either be the AhsayCBS server or a local drive that can connect with AhsayOBM. Initiating a Run Direct from the AhsayCBS (also known as agentless restore) will trigger a connection directly with the VMWare host (ESXi server and the direction shown in orange indicator below), while initiating the same action on the AhsayOBM requires the connection to route through the OBM (shown in green indication below).
The restored virtual machine, at this stage (e.g. before the restore is finalized) is in a read-only state to preserve its integrity. All changes made to the virtual disks (e.g. operation within the guest virtual machine) are stored separately in transaction logs stored on the NFS datastore or the original datastore, depending on the setting selected. These changes are discarded when Run Direct is stopped, where the restored VM will be removed and all changes will be discarded, or the changes will be consolidated with the original virtual machine data when the restore is finalized.
The restored virtual machine, at this stage (e.g. before the restore is finalized) is in a read-only state to preserve its integrity. All changes made to the virtual disks (e.g. operation within the guest virtual machine) are stored separately in transaction logs stored on the NFS datastore or the original datastore, depending on the setting selected. These changes are discarded when Run Direct is stopped, where the restored VM will be removed and all changes will be discarded, or the changes will be consolidated with the original virtual machine data when the restore is finalized.
Run Direct Backup Set | Non-Run Direct Backup Set | |
---|---|---|
Encryption | No | Yes |
Compression | No | Yes |
VDDK (CBT) | Yes | Yes |
AhsayCBS | Yes | Yes |
Local Destination | Yes | Yes |
Cloud Destination | No | Yes |
To finalize recovery of a VM, you will still need to migrate it to a permanent location on the VMware host. The following steps are taken when you finalize a Run Direct restore:
A VMware snapshot is created for the VM
Backup files from the NFS datastore are copied to the production datastore on the VMware host.
Changes made to the VM after the snapshot creation are moved to the new location.
The VM is temporarily suspended to consolidate the changes made after the snapshot creation.
After all changes are consolidated, the VM is resumed.
The NFS datastore is dismounted.
NOTE For vCenter VM backup set, provided that the vMotion feature of the vCenter set is working properly, the VM will not be suspended during the data consolidation.
There are two backup modes available for VM backup:
For VM on VMware host on Enterprise Standard, Enterprise and Enterprise Plus Edition, backup is performed in VDDK mode. Backup in VDDK mode produces a backup chain that consists of a full VDDK file and a set of VDDK incremental files.
During a subsequent backup in VDDK mode, AhsayOBM queries CBT through VADP (vSphere APIs for Data Protection) to request for transmission of all altered blocks since the last backup. As there is no need to stream the VM files to the Backup Client Computer for delta generation, backup in VDDK mode will greatly enhance the speed of subsequent backup.
Pro | Faster backup speed for subsequent backups compared to non-VDDK backup, as a result of backing up only the used size of your VM instead of the entire machine to enhance backup efficiency. This also helps with minimizing the storage size requirement and saving storage cost. |
Con | Require paid license, i.e. VMware Essentials License for usage of vSphere API. |
For VM on VMware host on Enterprise Standard, Enterprise and Enterprise Plus Edition, backup is performed in VDDK mode. Backup in VDDK mode produces a backup chain that consists of a full VDDK file and a set of VDDK incremental files.
During a subsequent backup in non-VDDK mode, VM files are streamed to the Backup Client Computer, for delta generation:
Pro | Free version of ESXi is supported. |
Con | Slower backup speed for subsequent backup compared to VDDK backup, as a result of having the entire VM backed up every time regardless of the actual used size. |
VDDK (CBT) | Non-VDDK | |
---|---|---|
Full Backup | Used data size of guest | Provisioned data size of guest |
Incremental / Differential | Generated by VMware Host using CBT | Generated by AhsayOBM on the staging machine using in-file delta |
Storage Size | Uses less storage quota | Uses more storage quota |
Storage Cost | Lower storage cost | Higher storage cost |
Backup Speed | Faster backup speed due to smaller data size | Slower backup speed due to larger data size |
Run Direct Support | Yes | No |
Restore from VDDK to VMDK format | Yes | No |
Granular Restore | Yes | Yes |
AhsayOBM on Windows Platform | Yes | Yes |
AhsayOBM on Non Windows Platform | No | Yes |
For backup of virtual machines on vCenter / ESXi servers, make sure the following requirements are met.
Make sure that the latest supported patch release is installed on the vCenter / ESXi hosts to prevent critical issue, such as corruption to change tracking data in certain situation.
SSH must be enabled on the hypervisor (ESXi Server). To enable root SSH login on an ESXi host, please follow this instructions from VMware: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=8375637
AhsayOBM requires root account access to the ESXi server to perform backup and restore.
For environment with firewall, the vCenter, ESXi servers and Backup Client Computer must be able to communicate with each other.
Ensure that ports 22, 80, 111, 443 and 902 allow outbound communication on the vCenter and ESXi servers. Refer to the link below for details on port usage: https://kb.vmware.com/s/article/2012773 https://kb.vmware.com/s/article/2106283 https://kb.vmware.com/s/article/2039095 https://kb.vmware.com/s/article/2131180
NOTE Ports 443 and 902 are default ports for VMware. If these have been changed from the default in your VMware environment, the firewall requirements will change accordingly.
Sufficient disk space must be allocated on the datastore (e.g. 1.2 x size of the largest virtual machine selected for backup), where the virtual machine(s) for backup are located.
For VMware ESXi version 5.1 and earlier, the maximum size of a virtual disk to be backup cannot exceed 1.98 TB (or less, depending the block size setting of the datastore). Details - http://kb.vmware.com/kb/1003565
VMware Tools are used to quiesce VMs prior to backing them up. To create consistent backup for your VMs on Windows platforms, ensure that VMware Tools are installed, and up-to-date on all VMs to be backup.
NOTE 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 transactional-based applications running on VMs like MS SQL Server. There are different types of quiescing mechanisms, according to the guest operating systems (e.g. Crash-consistent, File-system-consistent and Application-consist quiescing).
Refer to this link for information on the supported and compatible virtual machine hardware versions in VMware vSphere: ESXi/ESX hosts and compatible virtual machine hardware versions list (2007240)
For backup of virtual machines on ESXi server (with no vCenter setup), a separate Backup Client Computer must be prepared for AhsayOBM to install on.
IMPORTANT AhsayOBM cannot be installed on an ESXi server directly.
For environment with vCenter setup, AhsayOBM is installed on the vCenter computer for best performance.
Ensure that the following requirements are met by the Backup Client Computer or the vCenter computer:
NOTE For AhsayOBM version 8.1 or above, the bJW.exe process is automatically added to Windows Defender exclusion list for Windows 10 and 2016, during installation / upgrade via installer or upgrade via AUA.
For environment with firewall, the vCenter, ESXi hosts and Backup Client Computer must be able to communicate with each other.
Make sure that ports 22, 80, 111, 443 and 902 allow outbound communication on the Backup Client Computer. Refer to the link below for details on port usage: https://kb.vmware.com/s/article/2012773 https://kb.vmware.com/s/article/2106283 https://kb.vmware.com/s/article/2039095 https://kb.vmware.com/s/article/2131180
NOTE Ports 443 and 902 are default ports for VMware. If these have been changed from the default in your VMware environment, the firewall requirements will change accordingly.
For Backup Client Computer running on Linux operating system platform, Graphical User Interface (GUI) environment (e.g. GOME or KDE) must be installed.
IMPORTANT Run Direct restore, VDDK backup mode and Granular Restore is not supported for Backup Client Computer on Linux / Mac OS X platforms.
Sufficient disk space must be allocated on the Backup Client Computer (or the vCenter computer) for the temporary directory configured for the backup set, and the formula for calculation of disk space is like the following:
(Total File Size * Delta Ratio) * number of backup destinations = Maximum Free Space Required
NOTE The calculation is based on the current guest VM size, and it does not take into account guest VM growth over time. It is recommended for fast growing guest VM the maximum free space required should be reviewed on a regular basis to avoid potential backup problems.
Refer to the details of the maximum free space required for temporary directory.
Make sure AhsayOBM is installed on:
Make sure that the VMware VM backup add-on module is enabled for your AhsayOBM user account, and that sufficient number of guest / socket is assigned. Contact your backup service provider for more 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.
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 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.
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.
NOTE For VM on free version of ESXi without a Run Direct backup destination, backup will be performed in non-VDDK mode. For VM on free version of ESXi with a Run Direct backup destination, the following error message would be returned during a backup: ”Skip backing up Virtual Machine “name". Reason = "Run Direct is only support to VDDK backup mode"”.
CBT must be enabled for the VM to be backed up in VDDK mode. Make sure that the following requirements are met:
NOTE For virtual disk on VMFS, the initial backup (e.g. full file backup) will be of size similar to used size; while for virtual disk on NFS, the initial backup will be of the provisioned size.
NOTE Once the backup job executed on a VM with change block tracking option enabled by the VDDK, please do not turn off this option in the VM for consequent backup jobs. If you need to disable this option, you are suggested to create a new backup set with this option disabled.
VDDK backup mode does not support backup of virtual machine snapshot. 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.
VDDK backup mode does not support backup of virtual machine state (e.g. power on state / suspend state).
If the file name of the virtual machine contains the following special characters, https access to the virtual machine’s files will fail:
` ^ ~ = ; ! / ( [ ] { } @ $ \ & # % +
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
When a Run Direct restore is performed, the backup destination containing the guest VM files is mounted on the VMware host as NFS datastore.
Ensure that the following requirements are met by the backup destination of the VMware VM backup set:
No Compression and Encryption - Data backed up to a Run Direct enabled destination is not compressed or encrypted to optimize restore performance as Run Direct will make the VM restored by running the data directly form the backup files in the backup destination.
Operation System of the Backup Client Computer
Restore to Alternate Location
Dedicated NFS Service - A dedicated AhsayOBM NFS Windows service is introduced to allow Run Direct session to continue even if the AhsayOBM user interface is closed. By default, the AhsayOBM NFS service is started as Local System, which does not have sufficient permission to access any network resources (e.g. the AhsayOBM NFS service does not have sufficient permission to access the VM backup files on network drive). Make sure that the Log on setting of the Ahsay Online Backup Manager NFS Service is configured with an account with sufficient permission to access the network backup destination where the backed up VM data are stored.