Active Block Mapping (ABM) is a patent-pending technology that filters out inactive blocks of data from managed images, thereby letting Rapid Recovery protect only the active blocks, which optimizes function and performance. This feature is only available for agentless (Rapid Snap for Virtual) protection of ESXi or vCenter virtual machines (VMs) and Hyper-V servers and clusters.
ABM delivers a query to the file system header of a volume. The query returns a list of active blocks within the image. For this reason, ABM only works with NTFS file systems. When protecting ESXi and vCenter VMs, ABM can be combined with Changed Block Tracking (CBT), to read only active and changed blocks when taking incremental or differential snapshots.
When configuring agentless protection of a VM with the Protect Multiple Machines wizard, you have the option to enable ABM. If you opt to automatically protect new VMs added to the specified host, then the ABM rule also applies to any new VMs subsequently added to protection on the host.
You can change your ABM choice at any time in the Settings page for the host or VM. For more information, see Changing ABM settings.
To change the Active Block Mapping (ABM) settings for a supported hypervisor host or virtual machine (VM), complete the following steps.
|
NOTE: For more information, see Understanding Active Block Mapping. |
Option | Description | ||
---|---|---|---|
Enable Active Block Mapping | Lets you enable or disable the ABM feature. | ||
Enable swap file blocks exclusion |
Excludes the content of system files, such as pagefile.sys, hyberfill.sys, and swapfile.sys, from the backup. | ||
Exclude subdirectories |
Lets you exclude specific files by specifying '<file name>' or '<folder>\<subfolder>\<file name>'. Only the files will be excluded. The folders or subfolders that contained excluded files are included in the mount point, with no contents.
| ||
+ Add |
If you opted to exclude subdirectories, click Add and enter the location in the Path table for each item you want to exclude. |
In Rapid Recovery, you can modify the settings to manage the data transfer processes for a protected machine. The transfer settings described in this section are set at the protected machine level. To affect transfer at the Core level, see Modifying transfer queue settings.
There are three types of transfers in Rapid Recovery:
NOTE: The entire volume is always rewritten during restore of Windows systems using EFI system partitions. |
Data transfer in Rapid Recovery involves the transmission of a volume of data along a network from protected machines to the Core. In the case of replication, transfer also occurs from the originating or source Core to the target Core.
Data transfer can be optimized for your system through certain performance option settings. These settings control data bandwidth usage during the process of backing up protected machines, performing VM export, or performing a restore. These are some factors that affect data transfer performance:
You can adjust the performance options to best support your business needs and fine-tune the performance based on your environment. For more information, see Throttling transfer speed.
When transferring backup data or replicated recovery points between protected machines and Cores over the network, you can intentionally reduce the speed of the transfer. This process is known as throttling.
When you throttle the transfer speed, you limit the amount of your network bandwidth dedicated to file transfers from Rapid Recovery. When setting up replication, for example, throttling can reduce the likelihood that the transfer of prior recovery points to the replicated Core consumes all of your network bandwidth.
|
Caution: Throttling transfer speed is not always required or recommended. This information is provided to provide insight into a potential solution for performance issues in your Rapid Recovery environment. For example, sometimes, throttling may solve issues related to repeated transfer failures or network slowdowns caused by transferring a substantial amount of data for your protected or replicated Cores. |
There are several factors involved in determining the best approach to throttling. The type of machine being protected is a key factor. For example, a busy Microsoft Exchange server has a much higher change rate than a seldom-used legacy web server.
The input and output capabilities of the storage volumes on your protected machines can also contribute to more or less efficiency.
The speed of your network is another critical factor, with many variables. The network backbone in place (for example, 1GbE versus 10GbE), architecture, configuration, intentional use of NIC teaming, and even the type of cables used can all affect network transfer speed. If your environment has a slower wide area network, and if transfer jobs fail for backup or replication, consider throttling the transfer speed using some of these settings.
Ultimately, the process of network throttling involves trial and error. Quest recommends that you adjust and test your transfer settings, and revisit these settings periodically to ensure that your settings continue to meet your needs.
Adjusting transfer speed should be accomplished on an individual machine basis. In the Core Console, navigate to a specific machine, select Settings, and adjust the Transfer speed. For specific information about viewing and changing these settings, see Viewing and modifying protected machine settings.
That topic also includes descriptions of each of the settings used for throttling transfer. Those descriptions may be useful in determining which settings you should experiment with first.
The four main settings involved in throttling transfer speed are described in the following table:
Machine-Level Setting | Default Setting | Suggested Throttle Setting |
---|---|---|
Maximum Concurrent Streams | 8 | 4 |
Maximum Concurrent Writes | 8 | 4 |
Maximum Segment Size | 4194304 | 2097152 |
Outstanding Reads per Stream | 0 | Start at 24 |
Quest recommends adjusting and testing the other settings prior to changing the default setting for outstanding reads per stream, unless directed otherwise by a Quest Support representative. When tuning and testing this setting, start with a value of 24.
When you specify limitations to protected machine transfer parameters, these limitations apply per job. If two transfer jobs occur simultaneously or overlap, twice the bandwidth is used. If four transfer jobs across the network overlap, four times the bandwidth is used; and so on.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center