Rapid Recovery Local Mount Utility software requirements
The Local Mount Utility (LMU) is included with Rapid Recovery. You can obtain the LMU installer from the Downloads page from either the Rapid Recovery Core Console, the QorePortal (at https://qoreportal.quest.com), or the Rapid Recovery License Portal (at https://licenseportal.com/Downloads).
| Requirement | Details | ||
|---|---|---|---|
| Operating system | The Rapid Recovery Local Mount Utility software supports 32-bit and 64-bit Windows operating systems, including the following:
| ||
|
1 Requires the ASP .NET 4.6.2. role or feature. When installing or upgrading the LMU, the installer checks for the ASP .NET 4.6.2. role or feature. If required, the installer installs or activates this component and then reboots. If any operating system listed specifies a service pack (for example, Windows Server 2008 R2 SP1), then the OS with the specified service pack is the minimum requirement. If an operating system is listed without a service pack (for example, Windows 8.1), then the base operating system is supported. Any subsequent SP for a listed OS is also supported, unless explicitly excluded. The LMU software supports Windows Server Core edition installations for Windows Server versions 2012, 2012 R2, 2016 and 2019. Windows Server 2008 R2 Core edition is not supported. | |||
| Architecture | 32-bit or 64-bit | ||
| Memory | 4GB or higher | ||
|
Processor |
Single processor or higher | ||
| Network |
1 gigabit Ethernet (GbE) minimum
Quest does not recommend protecting machines over a wide-area network (WAN). If you have multiple networked sites, Quest recommends installing a Core at each site. To share information, you can replicate between the Cores located at different sites. Replication between Cores is WAN-optimized. The data transmitted is compressed, deduplicated, and encrypted during transfer. | ||
| Network hardware |
Use network cables with the appropriate rating to obtain the expected bandwidth.
|
Rapid Snap for Virtual agentless protection
The Rapid Snap for Virtual feature of Rapid Recovery lets you protect virtual machines (VMs) on specific hypervisor platforms without installing the Rapid Recovery Agent software on each guest machine.
When using this feature on the Hyper-V hypervisor platform, you only install Agent on the Hyper-V host. When using this feature on VMware ESXi, the ESXi host uses native APIs to extend protection to its guest machines.
Since the Agent software is not required to be installed on every VM, this feature is known in the industry as agentless protection. On Hyper-V, we also refer to this as host-based protection.
Rapid Snap for Virtual offers several benefits, and also some restrictions. As an example, you cannot capture snapshots of dynamic volumes (such as spanned, striped, mirrored, or RAID volumes) at the volume level. You can, however, capture snapshots on dynamic volumes at the disk level. Ensure that you understand both the benefits and restrictions before using this feature. For more information, see the topic "Understanding Rapid Snap for Virtual " in the Rapid Recovery 6.4 User Guide .
When using agentless or host-based protection, your VMs have the same minimum requirements for base operating system, RAM, storage, and network infrastructure as machines protected with the Rapid Recovery Agent software. For details, see the topic Rapid Recovery Agent software requirements.
Agentless protection of SQL Server machines
Rapid Recovery supports agentless protection for all supported SQL Server versions. As of release 6.3, this includes agentless support of SQL Server 2017.
Protecting older operating systems with older Agent versions or Agentlessly
Quest does not support software that has reached end of life (EOL). Agent-based protection in release 6.2 and later requires the OS of the protected machine to support Microsoft .NET Framework version 4.6.2 and SHA-2.
To protect machines in a Core running older operating systems, consider running an older supported version of Rapid Recovery Agent. For example, Rapid Recovery Agent release 6.1.3 runs Microsoft .NET Framework version 4.5.2, which supports some older Microsoft operating systems. You can protect machines running Agent version 6.1.3 in a Rapid Recovery 6.3 Core. For details on versions supported, see Quest Support policy.
Protected machines with these operating systems cannot be upgraded past release 6.2. Additionally, support for other operating systems have been discontinued in Core 6.4.0. For information on supported operating systems, see Rapid Recovery OS installation and compatibility matrix. For information on which platforms have been discontinued, refer to the Deprecations section of Rapid Recovery 6.4 Release Notes.
Another option is to protect machines agentlessly on Hyper-V or VMware ESXi. For more information, see Hypervisor requirements.
For machines running unsupported operating systems, proceed with agentless protection at your own risk. While Quest Data Protection Support can attempt to answer questions for releases under limited support, any required software corrections or patches can only be applied to fully supported software releases, respectively.
Rapid Snap for Virtual (agentless protection) support limitations
For a list of supported operating systems and the Rapid Recovery components supported for each, see Rapid Recovery release 6.4 operating system installation and compatibility matrix. Any known limitations are included in these matrices, or as notes to the software requirements tables for the Core or the Agent, respectively. If a defect precludes the use of specific features temporarily, this information is typically reported in the release notes for any specific release. Quest strongly encourages users to review system requirements and release notes prior to installing any software version.
For a list of features that have recently been deprecated or are now only under limited support, see the latest edition of Rapid Recovery 6.4 Release Notes.
Quest does not fully test with unsupported operating systems. If using agentless protection to protect virtual machines with an OS not supported by the Rapid Recovery Agent software, do so at your own risk. Users are cautioned that some restrictions or limitations may apply. These restrictions may include:
- An inability to perform virtual export (one-time or continual)
- An inability to save to an archive or restore from an archive
- An inability to restore to a system volume using bare metal restore
For example, if agentlessly protecting a machine with Windows 95, attempts at virtual export to Hyper-V will fail. This failure is due to restrictions in Hyper-V support of that older operating system.
To report specific difficulties, you can contact your Quest Data Protection Support representative. Reporting such difficulties lets Quest potentially include specific incompatibilities in knowledge base articles or future editions of release notes.
Hypervisor requirements
A hypervisor creates and runs virtual machines (guests) on a host machine. Each guest has its own operating system, which can differ from the OS of the host machine.
Two main integration points between Rapid Recovery and hypervisors relate to virtual export, and agentless protection.
Virtual export. Using the virtual export feature of Rapid Recovery, you can perform a one-time virtual export, or define requirements for continual virtual export (this feature is also called "virtual standby"). This process can be performed from any protected machine, physical or virtual. If a protected machine goes down, you can boot up the virtual machine and use it to continue day-to-day operations.
When exporting to ESXi, Hyper-V, or VMware Workstation, you must use the full licensed versions of those hypervisors, not free versions.
Rapid Recovery lets you perform virtual export to VM hosts described in the matrices below.
Agentless protection. Agentless protection for hypervisors is supported as described in the matrices below.
Rapid Recovery explicitly supports the following hypervisors:
VMware Workstation
Rapid Recovery lets you perform virtual export to the following VMware Workstation hosts. There is no agentless support for VMware Workstation.
| VMware Workstation Version | Rapid Recovery Support (as VM Export Target) | End of General Support by VMware |
|---|---|---|
|
VMware Workstation 111 |
Not supported |
June 2, 2016 |
|
VMware Workstation 121 |
Limited support |
February 25, 2018 |
|
VMware Workstation 141 |
Limited support |
March 26, 2019 |
|
VMware Workstation 152 |
Full support |
December 19, 2020 |
1 These Workstation versions have passed the end of general support with VMware. Rapid Recovery support for these versions is listed above.
2 Full support provided until end of general support date listed; thereafter, only limited support is provided in that Rapid Recovery release.
Quest strongly recommends running on the most recent supported VMware product version.
VMware vCenter/ESXiMicrosoft Hyper-V
Rapid Recovery lets you perform virtual export to supported VMware vCenter/ESXi hosts, and supports protection in a Rapid Recovery Core of vCenter/ESXi guest VMs. The following vCenter/ESXi versions are supported:
| ESXi Version | Rapid Recovery Support (as VM Export Target) | Rapid Recovery Support (Agentless Protection) | End of General Support by VMware |
|---|---|---|---|
|
vCenter/ESXi 5.5 |
Not supported |
Limited support |
September 19, 2018 |
|
vCenter/ESXi 6.0 |
Full support |
Full support1 |
March 12, 2020 |
|
vCenter/ESXi 6.5 |
Full support |
Full support |
November 15, 2021 |
|
vCenter/ESXi 6.7 |
Full support |
Full support |
November 15, 2021 |
1 Full support provided until end of general support date listed; thereafter, only limited support is provided in that Rapid Recovery release.
Quest strongly recommends running on the most recent supported VMware product version.
Quest recommends installing the most recent version of VMware Tools on protected VMs on vSphere or ESXi hosts.
Rapid Recovery supports only licensed versions of ESXi for agentless protection. Users of ESXi Free edition must use Agent-based protection and Agent-based licensing (socket-based licensing is not available to users of ESXi Free).
Microsoft Hyper-V
Rapid Recovery lets you perform virtual export to Microsoft Hyper-V hosts, and supports protection in a Rapid Recovery Core of Hyper-V guests on the following Hyper-V operating systems:
| Hyper-V Operating System | Rapid Recovery Support (as VM Export Target)1 | Rapid Recovery Support (Agentless Protection)2 | End of Mainstream Support by Microsoft |
|---|---|---|---|
|
Windows Server 20123 |
Limited support |
Limited support |
January 9, 2018 |
|
Windows Server 2012 R23 |
Limited support |
Full support |
January 9, 2018 |
|
Windows Server 2016 |
Full support |
Full support |
January 11, 2022 |
|
Windows Server 2019 |
Full support |
Full support |
January 9, 2024 |
|
Windows 83 |
Limited support |
Limited support |
January 14, 2014 |
|
Windows 8.13 |
Limited support |
Full support |
January 14, 2014 |
|
Windows 10 |
Full support |
Full support |
Octoberr 13, 2020 |
1 For virtual export to any Hyper-V host, .NET v.4.6.2 or later and .NET 2.0 or later are required on the Hyper-V host. If experiencing crashes of the Rapid Recovery Core with System.AccessViolationException, try upgrading the .NET Framework to version 4.7.2 or later.
2 Since Rapid Recovery Agent software must be installed on the Hyper-V host, but not on Hyper-V guest VMs, Quest also refers to this type of agentless support as host-based support.
2 These operating systems have passed the end of mainstream support with Microsoft. Rapid Recovery support for these versions is listed above.
Quest recommends installing Hyper-V Integration Services on VMs you want to protect on Hyper-V hosts.
Protected machines with Unified Extensible Firmware Interface (UEFI) operating systems support virtual export to Hyper-V second-generation hosts.
Oracle VM VirtualBox
Rapid Recovery lets you perform virtual export to the following Oracle VM VirtualBox versions, on both Windows and Linux platforms. There is no agentless support for VirtualBox .
| VirtualBox Version | Rapid Recovery Support (as VM Export Target)1 | End of Mainstream Support by Microsoft |
|---|---|---|
|
VirtualBox 5.13 |
Limited support |
April 2018 |
|
VirtualBox 5.23 |
Limited support |
July 2020 |
|
VirtualBox 6.0 |
Full support |
December 2023 |
DVM repository requirements
When you create a Deduplication Volume Manager (DVM) repository, you can specify its location on a local storage volume or on a storage volume on a Common Internet File System (CIFS) shared location. If creating the repository locally on the Core server, you must allocate resources accordingly.
DVM repositories must be stored on primary storage devices. Archival storage devices such as Data Domain are not supported due to performance limitations. Similarly, repositories should not be stored on NAS filers that tier to the cloud, as these devices tend to have performance limitations when used as primary storage.
Questrecommends locating your repository on direct attached storage (DAS), storage area network (SAN), or network attached storage (NAS) devices. These are listed in order of preference. If installing on a NAS, Quest recommends limiting the repository size to 6TB when using the CIFS protocol, since CIFS is not designed as a high-I/O storage protocol. Any storage device must meet the minimum input/output requirements. For these requirements, and for additional guidance for sizing your hardware, software, memory, storage, and network requirements, see the Rapid Recovery Sizing Guide referenced below.
When creating a DVM repository, you are required to specify the repository size on a volume. Each DVM repository supports up to 4096 repository extents (additional storage volumes).
Questdoes not support installing a Rapid Recovery Core or a repository for a Core on a cluster shared volume (CSV).
You can install multiple DVM repositories on any volume on a supported physical or virtual host. The installer lets you determine the size of a DVM repository.
|
|
NOTE: You can generate an on-demand or scheduled report to monitor the size and health of your repository. For more information on generating a Repository report, see the topic "Generating a report from the Core Console" in the Rapid Recovery 6.4 User Guide. |
Always create your repository in a dedicated folder or directory, not the root folder on a volume. For example, if installing on a local path, use D:\Repository\ instead of D:\. The best practice is to create separate directories for data and metadata. For example, D:\Repository\Data and D:\Repository\Metadata.
For more information about using Rapid Recovery, see the Rapid Recovery 6.4 User Guide. For more information about managing Rapid Recovery licenses from the Core Console, see the "Managing licenses" topic in the Rapid Recovery 6.4 Installation and Upgrade Guide. For more information about administering license groups or licenses on the license portal, see the Rapid Recovery License Portal User Guide. For more information on sizing your hardware, software, memory, storage, and network requirements, see the Rapid Recovery Sizing Guide referenced in knowledge base article 185962, “Sizing Rapid Recovery Deployments.”