After you backup your databases using Phoenix, you can restore them to a consistent state in case of a disaster. Phoenix lets you restore your databases:
- Using snapshots
- Using transaction log backups
However, before you restore your databases, ensure that you go through the restore checklist and considerations.
SQL server restore checklist
- You can perform a standalone 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.
- Ensure that the restore location is not the root of a drive, but a folder within the drive. For example, if you set the restore path to D:\, a restore to this location fails. That is why you should set a restore location to a subfolder, and not the root of the drive, for example, D:\ThisFolder.
- If you restored a database to the original instance at least once and then initiated another restore to the original instance when this database is offline, Phoenix replaces the database files from the previous restore. For example, if you restored database DB once, and you initiated a restore when DB is offline, Phoenix creates the restore dataset as rst_DB. The new rst_DB replaces the existing dataset, thus resulting in overwriting of the database files. To avoid this scenario, ensure that the source database is online at the time of subsequent restores.
- Phoenix does not support a restore of some database attributes, for example, Read-Only, Restrict Access, Owner, and Broker Enabled.
- Phoenix does not support a restore to a compressed folder.
- Restore is not supported for database names that have special characters.
- During an ongoing restore and scheduled backup, if the client machine is restarted then jobs request may not be resent to client machine.
Restore to a different SQL server
For SQL Server agents 4.6.5 and earlier:
- If you select to restore to a different server, ensure that this server is configured as a 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 SQL Server agents 4.6.6 and above:
- You can restore a database directly to any SQL instance on any server. However, ensure that the latest SQL Server agent is installed on all your servers. If the latest agent is not installed, then you cannot restore respective restore points.
- In addition, if you are restoring your database from one version of 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 above).
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 a server group that you manage. Cloud administrators can restore data to servers across server 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 restores from the state in which they were interrupted.
- If you restart or reboot your servers during a restore, the restore operation is aborted.
- The snapshot timestamps are displayed according to the server timezone. For example, for servers located in New York and London, the timestamps are displayed according to EST and UTC timezones respectively.
- Phoenix restores user databases and system databases except 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.
- For mixed workloads, you cannot trigger restore for File Server and MS-SQL Server simultaneously. You need to wait before the restore of a particular workload finishes.
- The restore request to the original location is queued if there is an active backup running for the same agent.