Users Guide

In previous versions, SQL attachability required a local instance of Microsoft SQL Server to be installed and configured on the
Core machine. Rapid Recovery Core now lets you choose to perform the attachability check from a SQL Server instance on the
Core, or from a SQL Server instance on a protected SQL Server machine. The instance you select must be a fully licensed
version of SQL Server, procured from Microsoft or through a licensed reseller. Microsoft does not allow the use of passive SQL
licenses.
Whichever SQL Server instance you specify is then used for all attachability checks. Attachability is synchronized between Core
settings and nightly jobs. For example, if you specify using the Core instance of SQL Server for nightly jobs, on-demand
attachability checks then also use the Core. Conversely, if you specify using a SQL Server instance on a specific protected
machine, all on-demand and nightly attachability checks then use the local instance on the protected machine.
Select the SQL Server instance to use as part of global Core settings. For more information, see Managing Core SQL
attachability settings on page 46.
NOTE: Performing the attachability check from a protected SQL Server machine requires the Rapid Recovery Agent
software to be installed on that server. Agentless protection is not supported for SQL attachability.
Attachability in Rapid Recovery Core supports SQL Server 2005, 2008, 2008 R2, 2012, and 2014. The account used to perform
the test must be granted the sysadmin role on the SQL Server instance.
The SQL Server on-disk storage format is the same in both 64-bit and 32-bit environments and attachability works across both
versions. A database that is detached from a server instance that is running in one environment can be attached on a server
instance that runs in another environment.
NOTE: The version of SQL Server on the Core must be equal to or newer than the SQL Server version on all of the
protected machines with SQL Server installed.
Forcing a SQL Server attachability check
In order to force an attachability check, a SQL database must be present on a protected volume. If Rapid Recovery does not
detect the presence of a database, the attachability check function does not appear in the Core Console.
Complete the steps in this procedure to force the system to perform an attachability check for a specific SQL server recovery
point.
1. In the left navigation area of the Rapid Recovery Core Console, select the protected SQL Server machine for which you
want to force the attachability check, and then click the Recovery Points menu.
2. Scroll down to the Recovery Points pane.
3. Navigate through the recovery points to find the desired recovery point. Optionally, click the
arrow to the right of a
recovery point in the list to expand the view.
In the expanded recovery point information, you can see volumes included in the recovery point.
4. In the Recovery Points pane, from the row representing the correct recovery point, click , and from the drop-down
menu, select Force Attachability Check.
5. In the resulting dialog box, click to confirm that you want to force an attachability check.
The dialog box closes. The system performs the attachability check.
For instructions on how to view the status of the attachability check, see Viewing events using tasks, alerts, and journal on page
90.
Understanding Rapid Snap for Virtual
By installing the Rapid Recovery Agent software, you can protect physical or virtual machines on the Rapid Recovery Core. The
supported operating systems are indicated in system requirements in the topic "Rapid Recovery Agent software requirements."
Rapid Recovery now offers another approach for protecting machines.
The Rapid Snap for Virtual feature — also known as agentless protection — of Rapid Recovery lets you protect virtual
machines (VMs) on a VMware ESXi or Hyper-V host without installing the Rapid Recovery Agent on every VM.
CAUTION:
Dell recommends that you limit agentless protection to no more than 200 VMs at once. For example,
do not select more than 200 VMs when using the Protect Multiple Machines Wizard. Protecting more than 200
VMs results in slow performance. There is no limit to how many VMs a Core can agentlessly protect over time.
For example, you could protect 200 VMs today and another 200 VMs tomorrow.
162 Protecting workstations and servers