Skip to main content
Restore database to an alternate server
Updated this week

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 cannot perform an automated redirected restore of a standby database to a standalone database. To perform a redirected restore of a standby database to a standalone database, you must download the database files and recover them manually.

  • 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.

Did this answer your question?