Using recovery points

Using transaction log backups

You can perform a restore of the master database only by using the Restore database files option. This is to avoid scenarios where the master database might become corrupt.

A restore of databases with the status "Restoring" might fail. Ensure that the databases that you want to restore are not in the Restoring state.

Ensure that the drive to which you plan to restore databases has sufficient space to accommodate the restored databases.

Druva does not support a restore of some database attributes, for example, Restrict Access, Owner, and Broker Enabled.

Druva does not support a restore to a compressed folder.

Druva does not support a restore for database names that have special characters.

During an ongoing restore and scheduled backup, if the client machine is restarted, the jobs request may not be resent to the client machine.

If you select to restore to a different server, ensure that this server is configured as an MS-SQL server.

During a restore of database files, Druva creates the database_files.txt file at <Drive>\restore\<snapshot>\<Request ID>. This file contains details of how the database files are mapped to the database, and how the database is mapped to its instance in a Unicode format. You require this file to manually attach the database to an instance at the time of restoring to a different server.

You can restore a database directly to any MS-SQL instance on any server. However, ensure that the latest MS-SQL server agent is installed on all your servers. If the latest agent is not installed, then you cannot restore respective recovery points.

Druva does not support the restore of AG databases on the clients older than version 4.7.1.

In addition, if you are restoring the database from one version of MS-SQL server to another, you have to alter the compatibility of the database. For more information, see System Requirements for MS-SQL servers and ALTER DATABASE Compatibility Level (Transact-SQL). Altering database compatibility works with the Hybrid Workloads agents released on and after January 16, 2016 (4.6.6 and later).

Ensure that the certificate and key that is used to encrypt the database is present on the SQL server to which you restore the database.

Hot recovery points reside on CloudCache for a period that you specified at the time of configuring CloudCache.

If you are a group administrator, you can only restore data to a server that belongs to an administrative group that you manage. Cloud administrators and data protection officers can restore data to servers across all administrative groups.

In the event of a network connection failure at the time of restores, Hybrid Workloads agents attempt to connect to Druva Cloud. After the restoration of connectivity, Hybrid Workloads agents restart the restores from the state in which they were interrupted.

The recovery point timestamps for backup sets of the standalone instances are displayed according to the server time zone. For example, for servers located in New York and London, the timestamps are displayed according to EST and UTC time zones, respectively.

The recovery point timestamps for backup sets of the AGs are displayed according to the time zone configured during creation of the backup set.

Druva restores user databases and system databases except for master as rst_<Database Name>. However, if rst_<Database Name> is already created during a previous restore, Druva appends an incremental counter to the dataset name. For example, at the time of restoring database DB, if Druva encounters rst_DB, the database DB is restored as rst_DB_1. The counter increments by 1 for every occurrence of an existing restore dataset.

At the time of restore, Druva writes the data to: <destination path> \ <snapshot> \ <Request ID> \ <Fileset> \ <Actual file>. You must provide <destination_path>, to which Druva appends <snapshot> \ <Request ID> \ <Fileset> \ <Actual file>.
An example restore path might look like this: F:\restore\Fri_Feb__6_04_01_59_2015\265\77690254254833a0544ac677149152a92cc3d03a

The <Request ID> folder uniquely identifies each restore request. We recommend that you do not modify <Request ID> or the subfolder names from earlier restores.

Ensure that the <destination path> is such that the complete path ( <destination path> \ <snapshot> \ <Request ID> \ <Fileset> \ <Actual file>) is no more than 260 characters long.

Druva restores the master database as master. To initiate a restore, use the Restore database files option. Thereafter, you must replace the current master database using the master file that Druva created. The naming convention ensures that multiple copies of the master database do not exist simultaneously.

Druva backs up datasets created during restores (rst_<Database Name>_<counter>) unless you explicitly exclude these datasets from backup. To know how you can exclude databases, see Create a backup policy.

The restore request to the original location is queued, if there is an active backup running for the same agent.

Therecovery pointcount for SQL backup set comprisesrecovery pointscreated by full, differential, and transaction log backups. The Restore Data page does not displayrecovery pointscreated by the transaction log backups. Therefore, the number ofrecovery pointsshown for SQL backup set on the Restore Data page is lesser than the count ofrecovery pointsdisplayed on the Availability group and instance details (Server details) page.

The backup of a database with Unicode characters (UTF-8) succeeds on all the nodes of an Availability Group (AG). The restore of the database with Unicode characters to an AG fails to add the database to the AG. However, the restore of the database succeeds on the primary node and Druva displays the Successful with Errors status on the Jobs page.

During restore, the Druva MS-SQL server agent keeps the Hybrid Workloads agent service account (which is the SQL Windows Login account) as the DB owner for that specific restored database. By default, the service will have a Local System Account, which is the built-in administrator account, also called as NT AUTHORITY/SYSTEM in the SQL Login section. Else, it can be a different service account used for Druva services.