Enterprise Workloads Editions: ✅ Business | ✅ Enterprise | ✅ Elite

Overview

To recover a database to a different server, an administrator would download the required database files and manually recover them on the destination server.
This was a costly operation in terms of storage, especially for databases on cloud virtual machines.
Now you can restore your database automatically to any server other than the source server. The restoration of a database to an alternate server is also known as database cloning or redirected restore. You can perform redirected restores by using the backed up recovery points directly from the cloud.

What are the benefits of this feature?

You can perform an automated restore of your Oracle database to an alternate server so that you can:

Create a copy of your production database for development or testing
Recover your production databases in case of a disaster
Perform periodic backup validations of your database
Migrate database from one machine or storage to another, or to Cloud.

Key considerations

Consider the following points before performing an automated restore of database to an alternate server:

You can perform redirected restores on agent version 6.1.0 or later.
To restore the database to an alternate server, make sure the DB user is the same on the source and destination servers.
By default, the database is restored to a File System.
You can restore a standalone database to an alternate server using the ASM location. For this, you must set custom spfile parameters on the Restore wizard on the console.For more information, see Restore an Oracle database from a recovery point.
If you select the Restore SP File check box, make sure that the source and the target server are identical in terms of the directory structure, memory configuration, and so on. If not, you can specify values for fields such as Oracle Home, Oracle Base, custom SP file parameters, and restore location from the Console. In this case, these values overwrite the values mentioned in the original SP file, while retaining all other values.
You can perform an automated restore of a standalone database to a standalone database.
You can perform an automated restore of a standby database to a standalone database as the primary database.
You can perform a redirected restore of a RAC database to a standalone database. Automated restore from RAC database to RAC database is not supported.
You can perform redirected restores using both Recovery point and Point-in-time restore methods.
If the database with the same name as that of the source exists on the restore location, it will be overwritten by the restored database. For more information, see the Source Database Check precheck in Restore prechecks.

📝 Note
For automated restore to an alternate server, Druva first restores the database to an alternate server with the source database name. Once the database is successfully recovered and opened, Druva changes its name to the target database name.

Use cases

The following table describes the different use cases supported for cloning a database to an alternate server. Perform the actions mentioned in the Recommended action column for successful restores.

The following use cases are applicable to both, Recovery point and Point-in-time restore.

❗ Important

If the database with the same name as that of the source exists on the restore location, it will be overwritten by the restored database.

Scenario:Multiple restores to the alternate server with SP File true Cloned database name different from the source and previous restore
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected The cloned database name provided is different from the source.		The database is cloned and started.
Subsequent restores	SP File field selected Cloned database name different from the source and the one provided in the previous restore	Before restoring the database shut down or drop the database cloned in the previous restore.	The database is cloned with the provided name and started.
Scenario: Multiple restores to alternate server with SP File true for first restore and false for subsequent restores Cloned database name different from the source Different restore locations
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected The cloned database name provided is different from the source.	None	The database is cloned with the name provided and started.
Subsequent restores	SP File field not selected. Cloned database name different from the source and the one provided in the previous restore. Different restore locations provided.	None	Databases are cloned with the names provided and started. 📝 Note The database restore fails if you do not select SP File field and provide the same location.
Scenario: Multiple restores to alternate server with SP File false Cloned database name different from the source Different restore locations
Use Case	Conditions	Recommended action	Result
First restore	SP File field not selected Cloned database name provided is different from the source.	None	The database is cloned with the name provided and started.
Subsequent restores	SP File field not selected Cloned database name different from the source and the one provided in the previous restore. Different restore locations provided.	None	Databases are cloned with the names provided and started. 📝 Note The database restore fails if you do not select SP File field and provide the same restore location.
Sceanrio: Multiple restores to alternate server with SP File true for first restore and false for subsequent restores. Cloned database name same as that of the source for the subsequent restores Target storage is on ASM
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected Cloned database name provided is different from the source, and the target storage is on ASM.	None	The database is restored and started on the File system.
Subsequent restores	SP File field not selected Cloned database name same as the one provided in the previous restore. The restore location can be the same or different from the previous restore.	None	The database is restored and started on the File system. 📝 Note We currently do not support restoration from ASM storage to ASM storage. To restore to ASM storage, make sure you select the SP File field. For more information, see Key considerations.
Scenario: Multiple Restore to alternate server with SP File true for first restore and false for subsequent. The cloned database name is same as that of the source and previous restores The restore location is different from the previous restore
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected Cloned database name provided is the same as that of the source.	None	The database is cloned with the name provided and started.
Subsequent restores	SP File field not selected Cloned database name same as the one provided in the previous restore. The restore location is different from the previous restore	None	The database is restored at the provided location and started.
Scenario: Multiple Restore to alternate server with SP File true for all restores The cloned database name is same as that of the source and previous restores
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected The cloned database name provided is same as that of the source.	None	The database is cloned and started.
Subsequent restores	SP File field selected Cloned database name same as the one provided in the previous restore.	None	The database is cloned and started.
Scenario: Multiple Restore to alternate server with SP File true for all restores Cloned database name is different from that of the source and same as that of the previous restores
Use Case	Conditions	Recommended action	Result
First restore	SP File field selected Cloned database name provided is different from the source.	None	The database is cloned and started.
Subsequent restores	SP File field selected Cloned database name same as the one provided in the previous restore.	None	The database is cloned and started.

Restore prechecks

The Phoenix agent runs a few checks before restoring a database. These checks look for issues that can cause your restore job to fail before the restore has started. You must fix any identified issues before restoring your database. The following sections describe the restore pre-checks and remedial actions you must take in case of pre-check failures.

Pre-check	Description	Action to take if the pre-check fails
Client connection status Check	Verifies if the client is in the connected state.	Make sure the client is in the connected state.
Oracle Home Check	Verifies if the provided Oracle Home is valid.	Make sure you provide a valid Oracle Home.
Oracle Base Check	Verifies if the provided Oracle Base is valid.	Make sure you provide a valid Oracle Base.
Source Database Check	Verifies if a database with the same name as that of the source already exists on the destination server.	Make sure that you move the existing database that exists on the destination server to another location and then perform the restore.
OS Version Check	Verifies if the OS version of the destination server is compatible with the source OS version.	Make sure that the OS version of the destination server is compatible with the source OS version.
Oracle Database Version Check	Verifies if the Oracle version of the destination server is compatible with the source OS version.	Make sure that the OS version of the destination server is compatible with the source OS version.
Storage Space Availability	Verifies if sufficient space is available on the destination server for performing restore.	Make sure that sufficient space is available on the destination server for performing restore.
Restore Location Check	Verifies if the specified restore location exists on the destination server and the oracle user has the required permissions to perform restore on that location.	Make sure that the specified restore location exists on the destination server and the oracle user has the required permissions to perform restore on that location.
Memory Availability Check	Verifies if the required memory is available on the destination server.	Make sure that the required memory is available on the destination server.
Restored database name check	Verifies if a database with the same name exists at the selected location.	Make sure that you provide a different name to the database while restoring it to an alternate server. Else the existing database will be overwritten with the restored database.
SPFile Parameters Check	Verifies if the provided SPFile parameters are valid.	Make sure that you provide valid SPFile parameters and their values in the `<parameter=value>` format. In case of multiple parameters, make sure you specify each parameter on a new line.

Oracle database restore workflow

Restore an Oracle database from a recovery point

Restore an Oracle database to a point-in-time

View Oracle job details page

Restore databases using PBS