public:vmware
Differences
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 16:32] ronnie.chan [Table] |
public:vmware [2019/08/16 16:44] ronnie.chan |
||
|---|---|---|---|
| Line 427: | Line 427: | ||
| <WRAP indent> | <WRAP indent> | ||
| + | |||
| + | === Granular Restore === | ||
| ^ Pro ^ Con ^ | ^ 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. | | | **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 for Granular Restore ===== | ||
| + | |||
| + | <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 | | | ||
| + | |||
| </WRAP> | </WRAP> | ||
public/vmware.txt · Last modified: 2022/11/28 11:11 by kirk.lim