Chat now with support
Chat with Support

Rapid Recovery 6.1.3 - User Guide

Introduction to Rapid Recovery Core Console Core settings Repositories Encryption keys Protecting machines
About protecting machines with Rapid Recovery Support for dynamic and basic volumes Understanding the Rapid Recovery Agent software installer Deploying Agent to multiple machines simultaneously from the Core Console Using the Deploy Agent Software Wizard to deploy to one or more machines Modifying deploy settings Understanding protection schedules Protecting a machine About protecting multiple machines Settings and functions for protected Exchange servers Settings and functions for protected SQL servers
Managing protected machines Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
Bare metal restore for Windows machines Understanding boot CD creation for Windows machines Using the Universal Recovery Console for a BMR Performing a bare metal restore for Linux machines Viewing the recovery progress Starting a restored target server Troubleshooting connections to the Universal Recovery Console Repairing boot problems Performing a file system check on the restored volume
Managing aging data Archiving Cloud storage accounts The Local Mount Utility The Central Management Console Core Console references Command Line Management utility PowerShell module
Prerequisites for using PowerShell Working with commands and cmdlets Rapid Recovery PowerShell module cmdlets Localization Qualifiers
Scripting REST APIs About us Glossary

Settings and functions for protected SQL servers

Setting credentials for a SQL Server machine
Forcing log truncation for a SQL machine
About SQL attachability
Forcing a SQL Server attachability check

If you are protecting a Microsoft SQL Server in your Core, there are additional settings you can configure in the Rapid Recovery Core Console, and there are additional functions you can perform.

A single setting, Attachability, is available in the Core Console related to SQL Server.

Rapid Recovery Core lets you perform a SQL attachability check to verify the integrity of recovery points containing SQL databases. This action checks the consistency of SQL databases and ensures that all supporting MDF (data) and LDF (log) files are available in the backup snapshot.

In previous releases, SQL attachability checks have historically required a licensed version of SQL Server on the Core machine. Rapid Recovery Core now provides the ability to perform SQL attachability checks from an instance of SQL Server on the Core, or from a licensed version of SQL Server on a protected SQL Server machine.

The attachability settings let you specify which licensed version of SQL Server is used to perform this check. For more information about configuring attachability settings, see Managing Core SQL attachability settings.

For more information on SQL attachability, see About SQL attachability.

Following are functions you can perform for a SQL server protected by the Core.

•
Specify SQL Server credentials. Rapid Recovery Core lets you set credentials so the Core can authenticate to the SQL server to obtain information. You can set credentials for a single protected SQL Server machine, or set default credentials for all protected SQL Servers.

For more information about setting credentials for SQL servers, see Setting credentials for a SQL Server machine.

•
Truncate SQL logs. When you force log truncation of SQL Server logs, this process identifies the available space on the protected server. This process does not reclaim any space.

For more information about truncating SQL Server logs on demand, see Forcing log truncation for a SQL machine.

•
Force an attachability check of a SQL Server. This function checks the consistency of SQL databases and ensures that all supporting MDF (data) and LDF (log) files are available in the backup snapshot.

For more information about forcing an attachability check for SQL servers on demand, see Forcing a SQL Server attachability check.

Other than specifying credentials, each of the functions described in the preceding list can be accomplished on demand, and can also be configured to occur as part of the nightly jobs performed for the Core. For more information about the tasks you can schedule as nightly jobs, see Understanding nightly jobs. For information on configuring nightly jobs, see Configuring nightly jobs for the Core.

Setting credentials for a SQL Server machine

You must add the SQL Server machine to protection on the Rapid Recovery Core before performing this procedure. For more information about protecting machines, see Protecting a machine.

Once you protect data on a Microsoft SQL Server machine, you can set login credentials for a single instance, or for all SQL Servers, in the Rapid Recovery Core Console.

Complete the steps in this procedure to set credentials for each SQL Server.

1.
In the left navigation area of the Rapid Recovery Core Console, select the protected SQL Server machine for which you want set credentials.
The Summary page displays for the protected SQL Server.
2.
On the Summary page, from the links at the top of the page, click the downward-facing arrow [Expand] to the right of the SQL menu, and then from the resulting drop-down menu, do one of the following:
◦
If you want to set default credentials for all SQL Server database instances, click Set Default Credentials for All Instances, and in the Edit Default Credentials dialog box, do the following:
1.
In the User name text field, enter the user name for a user with permissions to all associated SQL servers; for example, Administrator (or, if the machine is in a domain, [domain name]\Administrator).
2.
In the Password text field, enter the password associated with the user name you specified to connect to the SQL server.
3.
Click OK to confirm the settings and close the dialog box.
◦
If you want to set credentials for a single SQL Server database instance, click the display name of the protected SQL Server machine, and then in the Edit Instance Credentials dialog box, do the following:
1.
Select the credential type (Default, Windows, or SQL)
2.
In the User name text field, enter the user name for a user with permissions to the SQL server; for example, Administrator (or, if the machine is in a domain, [domain name]\Administrator).
3.
In the Password text field, enter the password associated with the user name you specified to connect to the SQL server.
4.
Click OK to confirm the settings and close the dialog box.

Forcing log truncation for a SQL machine

Log truncation is available for machines that use SQL Server. Complete the steps in this procedure to force log truncation.

* 
NOTE: When conducted for a SQL machine, truncation identifies the free space on a disk, but does not reduce the size of the logs.
1.
In the left navigation area of the Rapid Recovery Core Console, select the machine for which you want to force log truncation.
The Summary page appears for the protected machine.
2.
From the Summary page (or from any page for this protected machine), at the top of the page, click the SQL drop-down menu and select Force Log Truncation.
3.
Click Yes to confirm that you want to force log truncation.

About SQL attachability

The SQL attachability feature lets the Rapid Recovery Core attach SQL master database files (.MDF files) and log database files (.LDF files) to a snapshot of a protected SQL Server. The snapshot is captured using a local instance of Microsoft SQL Server.

Issues relevant for Rapid Recovery users protecting SQL Server machines include which instance of SQL Server performs attachability, and the method of performing SQL attachability (on demand, or as part of nightly jobs).

The attachability check lets the Core verify the consistency of the SQL databases and ensures that all MDF and LDF files are available in the backup snapshot.

Attachability checks can be run on demand for specific recovery points, or as part of a nightly job.

To perform the SQL attachability check on demand, see Forcing a SQL Server attachability check. To perform SQL attachability once daily, at the time specified for your nightly job operations, enable the option Check attachability for SQL databases in nightly jobs. For more information about setting nightly jobs for the Core, see Configuring nightly jobs for the Core. For more information about setting nightly jobs for a specific machine (in this case, a protected SQL Server), see Customizing nightly jobs for a protected machine.

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.

* 
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 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.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating