After you back up your databases using Phoenix, you can restore them to a consistent state. Phoenix lets you restore the databases:
- Using snapshots
- Using transaction log backups
However, before you restore the databases, ensure that you go through the restore checklist and considerations.
MS-SQL database restore checklist
- 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.
- Phoenix does not support a restore of some database attributes, for example, Restrict Access, Owner, and Broker Enabled.
- Phoenix does not support a restore to a compressed folder.
- Phoenix 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.
Restore to a different SQL server
For MS-SQL server agents 4.6.5 and earlier:
- 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, Phoenix 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.
For MS-SQL server agents 4.6.6 and later:
- 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 restore points.
- Phoenix 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 ALTER DATABASE Compatibility Level (Transact-SQL). Altering database compatibility works with the Phoenix agents released on and after January 16, 2016 (4.6.6 and later).
Considerations for restores
- Hot snapshots reside on Phoenix CloudCache for a period that you specified at the time of configuring Phoenix 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, Phoenix agents attempt to connect to Phoenix Cloud. After the restoration of connectivity, Phoenix agents restart the restores from the state in which they were interrupted.
- The snapshot 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 snapshot timestamps for backup sets of the AGs are displayed according to the time zone configured during creation of the backup set.
- Phoenix 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, Phoenix appends an incremental counter to the dataset name. For example, at the time of restoring database DB, if Phoenix 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, Phoenix writes the data to: <destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file>. You must provide <destination_path>, to which Phoenix 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.
- Phoenix 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 Phoenix created. The naming convention ensures that multiple copies of the master database do not exist simultaneously.
- Phoenix 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.
- The snapshot count for SQL backup set comprises snapshots created by full, differential, and transaction log backups. The Restore Data page does not display snapshots created by the transaction log backups. Therefore, the number of snapshots shown for SQL backup set on the Restore Data page is lesser than the count of snapshots displayed 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 Phoenix displays the Successful with Errors status on the Jobs page.