Skip to main content

About Pluggable Database-level restore

Updated today

Druva supports granular recovery of Pluggable Databases (PDBs) within a Container Database (CDB). This feature allows administrators to restore specific PDBs without affecting the entire CDB, significantly reducing Recovery Time Objectives (RTO) and storage overhead.

Key Capabilities

  • Selective PDB Restore: Restore one or more specific PDBs from a CDB backup.

  • Point-in-Time Recovery (PITR): Recover PDBs to a specific timestamp using archive logs.

  • Cross-Server Restore: Restore PDBs to a different CDB than the source.

  • Multi-mount Mapping: Restore data across multiple NFS mount locations.

  • Automated cleanup: Temporary resources created during restore are automatically removed

Supported Scenarios

  • Restore to Original Server: Restores and overwrites the existing PDB on the original server. In this scenario, files are restored to their original location. However, if the destination server uses ASM storage, the data files are restored to an auxiliary location on ASM storage.

  • Restore to Alternate Server (New CDB instance): Restores the selected PDB(s) to a different server and converts the auxiliary instance into a new primary CDB instance. If the SP file is set to true, the files are restored to the following location:
    ​<db_create_file_dest or ORACLE_BASE>/<targetDBname_jobid>/oradata/DATAFILE

  • Restore to Alternate Server (Existing CDB): Restores the selected PDB(s) to another running Oracle instance/server. In this scenario, data is restored to the db_create_file_dest directory. If this is not found, then the ORACLE_BASE directory is used. All auxiliary instance paths use this location as the base directory during restore.

  • Cross-CDB Restore: You can restore PDBs to a different CDB than the source.

  • Point-in-Time Recovery (PITR): Supported for PDB restores using archive logs.

Considerations and Limitations

  • This feature is not supported for database instances having versions 12.x or lower

  • When restoring to an alternate server, ensure the destination CDB version is the same as that of the source.

  • Restoring PDBs to a standby database is not supported.

  • If a PDB with the same name exists on the target CDB, the existing PDB is dropped and overwritten.

  • While restoring to an alternate server on a new CDB instance with SP file set to true, the agent restores standard datafiles to the new target location. However, for Oracle-managed files, even if you specify new locations for datafiles, the agent restores the datafiles to the default location defined by db_create_file_dest.

  • Concurrent PDB restores to the same server are not supported for PDBs belonging to different CDBs.

Restore pluggable database

You can restore one or more Pluggable Databases (PDBs) from a Container Database (CDB) backup using selective PDB-level restore. This process recovers only the PDBs you select, reducing restore time and storage requirements.

This article provides step-by-step instructions for restoring PDBs from a CDB backup. Before you begin, review the prerequisites.

Prerequisites

Make sure you have:

  • Oracle Database Enterprise Edition with multitenant architecture (Oracle 19c or later)

  • Druva Oracle Agent 8.0.1-907884 or later

  • Destination servers with version 8.0.1-907884 or later

  • Sufficient storage space for the selected PDBs

  • To restore to an existing CDB, the target CDB must be up and running

  • While restoring to the alternate server, the target CDB must have authentication assigned.

Procedure

  1. Log in to the Management Console.

  2. Click Oracle > Direct to cloud from the Protect menu.


    πŸ“ Note

    If the All Organizations menu is enabled, you have to first select an organization and then click Oracle > Direct to Cloud.


  3. In the left navigation pane, click Configured Databases.

  4. On the Configured Databases page, select the database that you want to restore and click Restore.



    πŸ“ Note
    ​To quickly search and select a database, you can use the search box on the top-right corner of the Configured Databases page to filter the listed database. Type the name of the database, Oracle server, or the availability group in the search tab to narrow down on the database that you want to select.
    ​


  5. On the Restore Database page, select either Recovery Point Restore or Point-in-Time Restore.

  6. To perform a Recovery Point Restore, select the required recovery point from the timestamp drop-down list.
    To perform a Point-in-Time Restore, in the Select Date and Time section, specify a date and time to which you want to restore the databases. Click the Calendar icon to select a date of the recovery point and select the recovery point from the available range of recovery points for the selected date. The timestamps of the archive logs are displayed according to the Oracle server time zone. For example, the timestamps for servers located in New York and London are displayed according to EST and UTC time zones, respectively.
    Databases will be restored to the last available committed transaction before the specified point in time.

  7. In the Database Files section, select the PDB, that you want to restore.
    ​You can also use the search bar to find specific PDBs or files to restore. Simply enter the complete PDB name, filename or a partial string (e.g., PDB1).


    Notes:

    • We currently support a maximum of 500 files per restore operation. We recommend selecting 500 files or fewer for a single restore request. For larger datasets, perform the restore in multiple batches.

    • You cannot restore only the PDB$SEED database. To enable PDB-level restore in the Console, select one or more PDBs.
      ​



      The search results will dynamically display the File Name, Size, and the full Path within the database structure. Select the individual files or folders you wish to restore.​

  8. Click Restore.


    πŸ“ Note

    ​If a backup job for the database selected for recovery point restore is already running, Druva prompts a message to cancel the backup job and trigger restore.


    The following screen is displayed:

    If you choose to restore the complete database in Step.7, you can restore the selected database either automatically or manually. If you choose to restore individual database elements, you can restore them manually only.

  9. To restore the database automatically, select either of the following options:

  10. Provide the necessary information and click Next.
    ​
    On the click of Next, the system executes a set of prechecks for proactively identifying underlying issues, thereby reducing the likelihood of subsequent job failure.

You may either skip the pre-checks and proceed or let the pre-checks run and then click Proceed. We recommend that you run the pre-checks and fix issues, if any, to avoid restore failures. For more information, see Restore prechecks.

Next Steps

​You can view the details of the completed job on the All Jobs page.

Automatically restore and recover the original database

Select this option to restore the complete database automatically to the original Oracle server from where it was backed up. Provide the following details and click Next:
​

  1. #RMAN Channels: Specify the number of channels to be established between RMAN and the databases to be restored. The default value for the number of channels is set to β€˜4’. Druva recommends you to specify a maximum of 32 RMAN channels. For more information about RMAN Channels, see About RMAN Channels.

  2. Restore and recover Wallet Files: For wallet files, select the Restore and recover Wallet Files checkbox if you want to restore the wallet files. If you select this checkbox, and if there is an existing wallet directory at the restore location, it is renamed and a new directory is created with the restored wallet files, thereby retaining the existing wallet files for future reference.



    πŸ“ Note
    ​The Restore and recover Wallet Files checkbox is visible only if you have wallet files.
    ​


  3. Destination Target: This field is visible for standby databases only. To restore data from a standby database, provide the destination target where you want to restore the database. You can restore to a standby or primary database.



    πŸ“ Notes

    To restore on a primary database, make sure the primary database is registered and authentication is assigned to it. Also, after assigning authentication, perform discovery.


Druva prompts you with a warning message that the original database on your Oracle server will be replaced with the restored data. Click Yes on the confirmation dialog.

Druva terminates connections to the database on the original server host and then replaces the database with the restored database.

Restore to alternate standalone instance

Select this option to restore the PDB to an alternate standalone instance. You can restore a PDB either to an existing CDB instance or to a new CDB instance.

Restore to existing instance

To restore a PDB to an existing CDB instance, select Restore to existing instance and provide the following information:


πŸ“Note:

Restoring a PDB to an existing CDB instance will replace the selected database with the restored data.


  • Destination Server: Select the target Oracle server where you want to restore the database.


    πŸ“ Note

    PDB level restore is available from version 8.0.1-907884 only.


  • Destination Instance: Select the target CDB instance where you want to restore the PDB.

  • #RMAN Channels: Provide the number of channels to be established between RMAN and the databases to be restored. The default value for the number of channels is set to β€˜4’. Druva recommends you to specify a maximum of 32 RMAN channels. For more information about RMAN Channels, see About RMAN Channels.

Restore to new instance

Select this option to restore the PDB to a new CDB instance. Provide the following information:
​

  • Destination Server: Select the target Oracle server where you want to restore the database.


    πŸ“ Note

    ​PDB level restore is available from version 8.0.1-907884 only.


  • Restore SP File: Select to restore the SP File.


    πŸ“ Note

    If you select this field, make sure that the source and the target server are the same 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.


  • Oracle Home: The directory structure where the Oracle database is installed.

  • Oracle Base: The directory structure of the location where Oracle software and configuration files are stored.

  • Other Server Parameters: The list of custom SPFile parameters that can be used for the restored database. Provide the parameters in the <parameter=value> format. For example, open_cursors=300.

    In case of multiple custom parameters, provide each parameter on a new line. For example:

    <parameter1=value1> <parameter2=value2>
    .

    .
    <parametern=valuen>

To restore a standalone database to an alternate server using an ASM storage, pass the following parameters in the Other Server Parameters field:

db_create_file_dest=+Data

log_archive_dest=+Data/<sourceDBName>


Where <sourceDBName> is the name of the database that you want to restore to an alternate server.


πŸ“ Notes

  • The Other Server Parameters field is visible only if you have upgraded the agent to version 6.1.1 or higher.

  • The following SPFile parameters will not be overwritten even if you pass custom values from the user interface:

    • Db_name

    • Undo_management

    • Enable_pluggable_database

  • If the
    ​
    compatible parameter
    ​ is set on the source database and you pass another value through Other Server Parameters , the compatible parameter will not be overwritten by this new value on the restored database.

  • Make sure the parameter value does not contain β€œ=”.


  • Restore location: Specify the location on the selected server where you want to restore the PDB or type the absolute path to the restore location. By default, Oracle base is used as the restore location. You can also distribute the restored PDB datafiles across multiple NFS mount locations (up to 5 mounts) instead of placing all files in a single location by clicking Add more. This helps you manage storage capacity by spreading data across available mounts during restore operations. For more information, see Multi-mount support for restore .
    ​

  • #RMAN Channels: The number of channels to be established between RMAN and the databases to be restored. The default value for the number of channels is set to β€˜4’. Druva recommends you to specify a maximum of 32 RMAN channels. For more information about RMAN Channels, see About RMAN Channels.

  • Restored CDB Instance Name: The name of the CDB instance that is to be restored to an alternate server.


❗ Important

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

  • Do not provide $ or # in the restored database name, else the restore fails.


  • Restore Wallet Files: Select to restore the wallet files. If you select this checkbox, a new directory is created for wallet files. If the wallet directory exists already, the existing wallet files are retained for future reference, and new files are downloaded in the directory.


πŸ“ Notes

  • ​The Restore and recover Wallet Files checkbox is visible only if you have wallet files.

  • While restoring the database to an alternate server, for restoring wallet files, make sure the user, group, and their respective permissions are the same on the source and the destination server.
    Also, make sure that the Oracle user on the destination server has access to the wallet location.


Restore database files

Select the Restore database files option to restore the complete database or individual database elements manually. Provide the following details and click Finish:
​

  • Destination Server: The Oracle server host to download the backup data to. By default, the original Oracle server host is selected where the database was backed up. When you restore a database to its original location, Druva replaces the database on the Oracle server host with the restored database.

  • Restore Location: The location on the selected server where you want to download the backup data or type the absolute path to the restore location. By default, Oracle base is used as the restore location. You can also distribute the PDB datafiles across multiple NFS mount locations (up to 5 mounts) instead of placing all files in a single location by clicking Add more. This helps you manage storage capacity by spreading data across available mounts during restore operations. For more information, see Multi-mount support for restore .
    ​

The database files are downloaded to the selected server and location. The database needs to be manually recovered on the server. For more details, see Recover database from the downloaded backup data.

The backup database is downloaded to the location you specify. After you click Finish, restore prechecks are run and Druva generates a restore job. You can track the progress of the job by viewing the progress log. For more information, see View progress logs.

Next Steps

  • The DBA can run RMAN scripts to fetch backup data downloaded to the restore location and recover the database on the required Oracle server host. For more information, see Recover database from the downloaded backup data.

  • You can view the details of the completed job on the All Jobs page.

Did this answer your question?