Skip to main content


 

 

druva_logo.pngDruva
|
Documentation

How can we help you?

Trending articles:

 

Druva Documentation

Restore database to an alternate server

  1. Last updated
  2. Save as PDF
Heads up!

We've transitioned to a new documentation portal to serve you better. Access the latest content by clicking here.

Enterprise Workloads Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png 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.

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

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

  

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.