16 Introduction to Backup and Recovery
- About Oracle Fusion Middleware Backup and Recovery
It is important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery. - Oracle Fusion Middleware Directory Structure
Oracle Fusion Middleware has a standard directory structure, which is important to understand when you are backing up or recovering Oracle Fusion Middleware. - Tools to Use for Backup and Recovery
You can use standard operating system tools to backup or recover Oracle Fusion Middleware. - Backup and Recovery Recommendations for Oracle Fusion Middleware Components
Oracle Fusion Middleware components have different requirements for what you back up and what you recover. Many components have dependencies on a database or on other components. - Assumptions and Restrictions for Backup and Recovery
Certain assumptions and restrictions apply to the backup and recovery procedures in this book.
Parent topic: Advanced Administration: Backup and Recovery
About Oracle Fusion Middleware Backup and Recovery
It is important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery.
An Oracle Fusion Middleware environment can consist of different components and configurations. A typical Oracle Fusion Middleware environment contains an Oracle WebLogic Server domain with Java components, such as Oracle SOA Suite, and a WebLogic Server domain with Identity Management components.
The installations of an Oracle Fusion Middleware environment are interdependent in that they contain configuration information, applications, and data that are kept in synchronization. For example, when you perform a configuration change, information in configuration files is updated. When you deploy an application, you might deploy it to all Managed Servers in a domain or cluster.
It is, therefore, important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery. You should back up your entire Oracle Fusion Middleware environment at once, then periodically. If a loss occurs, you can restore your environment to a consistent state.
See Also:
Understanding Oracle Fusion Middleware for conceptual information about Oracle WebLogic Server domains, the Administration Server, Managed Servers and clusters, and Node Manager.
The following topics describe concepts that are important to understanding backup and recovery:
- Impact of Administration Server Failure
- Managed Server Independence (MSI) Mode
- Configuration Changes in Managed Servers
Parent topic: Introduction to Backup and Recovery
Impact of Administration Server Failure
The failure of an Administration Server does not affect the operation of Managed Servers in the domain but it does prevent you from changing the domain's configuration. If an Administration Server fails because of a hardware or software failure on its host computer, other server instances on the same computer may be similarly affected.
If an Administration Server for a domain becomes unavailable while the server instances it manages—clustered or otherwise—are running, those Managed Servers continue to run. Periodically, these Managed Servers attempt to reconnect to the Administration Server. For clustered Managed Server instances, the load balancing and failover capabilities supported by the domain configuration continue to remain available.
When you first start a Managed Server, it must be able to connect to the Administration Server to retrieve a copy of the configuration. Subsequently, you can start a Managed Server even if the Administration Server is not running. In this case, the Managed Server uses a local copy of the domain's configuration files for its starting configuration and then periodically attempts to connect with the Administration Server. When it does connect, it synchronizes its configuration state with that of the Administration Server.
Parent topic: About Oracle Fusion Middleware Backup and Recovery
Managed Server Independence (MSI) Mode
A Managed Server maintains a local copy of the domain configuration. When a Managed Server starts, it contacts its Administration Server to retrieve any changes to the domain configuration that were made since the Managed Server was last shut down. If a Managed Server cannot connect to the Administration Server during startup, it can use its locally cached configuration information—this is the configuration that was current at the time of the Managed Server's most recent shutdown. A Managed Server that starts without contacting its Administration Server to check for configuration updates is running in Managed Server Independence (MSI) mode. By default, MSI mode is enabled. However, a Managed Server cannot be started, even in MSI mode, for the first time if the Administration Server is down due to non-availability of the cached configuration.
Parent topic: About Oracle Fusion Middleware Backup and Recovery
Configuration Changes in Managed Servers
Configuration changes are updated in a Managed Server during the following events:
-
On each Managed Server restart, the latest configuration is retrieved from the Administration Server. This happens even when Node Manager is down on the node where the Managed Server is running. If the Administration Server is unavailable during the Managed Server restart and if the MSI (Managed Server Independence) mode is enabled in the Managed Server, it starts by reading its local copy of the configuration and synchronizes with the Administration Server when it is available. By default MSI mode is enabled.
-
Upon activating every administrative change such as configuration changes, deployment or redeployment of applications, and topology changes, the Administration Server pushes the latest configuration to the Managed Server. If the Managed Server is not running, the Administration Server pushes the latest version of the configuration to the Managed Server when it does start.
Parent topic: About Oracle Fusion Middleware Backup and Recovery
Oracle Fusion Middleware Directory Structure
Oracle Fusion Middleware has a standard directory structure, which is important to understand when you are backing up or recovering Oracle Fusion Middleware.
The following shows a simplified view of the Oracle Fusion Middleware directory structure when you have installed the Oracle Fusion Middleware Infrastructure:
Parent topic: Introduction to Backup and Recovery
Tools to Use for Backup and Recovery
You can use standard operating system tools to backup or recover Oracle Fusion Middleware.
To backup or recover your Oracle Fusion Middleware environment, you can use:
-
File copy utilities such as copy, xcopy, tar, or jar. Make sure that the utilities:
-
Preserve symbolic links
-
Support long file names
-
Preserve the permissions, timestamps, and ownership of the files
When you backup and restore the files, use your preferred tool. For example:
-
On Windows, for online backup and recovery, use copy or xcopy; for offline backup and recovery, use copy, xcopy, or jar. Do not use Winzip because it does not work with long filenames or extensions.
Note that for some versions of Windows, any file name with more than 256 characters fails. You can use the xcopy command with the following switches to work around this issue:
xcopy /s/e "C:\Temp\*.*" "C:\copy"
See the xcopy help for more information about syntax and restrictions.
-
On Linux and UNIX, use tar.
If you want to retain your backups for a longer duration, you may want to back up to tape, for example using Oracle Secure Backup.
-
-
Oracle Recovery Manager (RMAN) to back up or recover database-based metadata repositories and any databases used by Oracle Fusion Middleware. With RMAN, you can perform full backups or incremental backups. See Oracle Database Backup and Recovery User's Guide for information about using RMAN to back up or recovery a database.
You can also configure Oracle WebLogic Server to make backup copies of the configuration files. This facilitates recovery in cases where configuration changes need to be reversed or in the unlikely case that configuration files become corrupted. When the Administration Server starts, it saves a .jar file named config-booted.jar that contains the configuration files. When you make changes to the configuration files, the old files are saved in the configArchive directory under the domain directory, in a .jar file with a sequentially numbered name such as config-1.jar. However, the configuration archive is always local to the Administration Server host. It is a best practice to back up the archives to an external location.
Parent topic: Introduction to Backup and Recovery
Backup and Recovery Recommendations for Oracle Fusion Middleware Components
Oracle Fusion Middleware components have different requirements for what you back up and what you recover. Many components have dependencies on a database or on other components.
Table 16-1 describes what you must back up and recover for each Oracle Fusion Middleware component. Note the following:
-
If the component has a database dependency listed in the table, back up and recover the database using RMAN, as described in the Oracle Database Backup and Recovery User's Guide.
-
For backup, back up the entity listed in the table, as described in Performing a Backup.
-
For recovery, depending on what has failed, you may need to recover the following, as described in Recovering Your Environment:
-
The domain, which, for some components, can be either a WebLogic Server domain (see Recovering an Oracle WebLogic Server Domain) or a standalone domain (see Recovering a Standalone Domain.)
-
The Administration Server configuration: See Recovering the Administration Server Configuration.
-
A Managed Server: See Recovering a Managed Server.
-
A cluster: See Recovering a Cluster.
-
Applications: See Recovering Applications.
-
The database containing the schemas related to the component. See Recovering a Database.
After a loss of host, you may need to recover the following:
-
The domain, which, for some components, can be either a WebLogic Server domain (see Recovering After Loss of Oracle WebLogic Server Domain Host) or a standalone domain (see Recovering After Loss of Standalone Domain Host).
-
The Administration Server host: See Recovering After Loss of Administration Server Host.
-
The Managed Server host: See Recovering After Loss of Managed Server Host.
-
The database containing the schemas related to the component. See Recovering After Loss of Database Host.
-
Table 16-1 describes the backup and recovery recommendations for Oracle Fusion Middleware components.
Table 16-1 Backup and Recovery Recommendations
| Component | Database Dependencies | Backup Recommendation | Recovery Recommendation | Additional Information |
|---|---|---|---|---|
|
Oracle Access Management Access Manager |
The schema used by the Access Manager policy store. |
The Middleware home and the domain home for the Access Manager server. Back up the Oracle home and domain for the Oracle HTTP Server that contains the Webgate, and the database containing the schema used by the Access Manager policy store. |
The Middleware home and the domain home for the Access Manager server. Also the Oracle home and the domain for the Oracle HTTP Server that contains the Webgate, as needed. |
To recover from loss of host, see Recovering Oracle Access Management Access Manager to a Different Host. |
|
Oracle Access Management Identity Federation |
OIF schema |
The Administration Server domain, the Managed Server. |
The Managed Server where the Identity Federation application is deployed. |
To recover from loss of host, see Recovering Oracle Access Management Identity Federation to a Different Host. |
|
Oracle Access Management Mobile and Social |
None |
The domain home, Oracle home, and the IdaaS.xml and OIC_RP.xml files. These files are located in the following location in the domain home containing Mobile and Social configuration: DOMAIN_HOME/config/fmwconfig |
The domain home or the Oracle home or both, if necessary. Also, the image location and configuration, depending upon extent of failure |
To recover to a different host, see Recovering Oracle Access Management Mobile and Social to a Different Host. |
|
Oracle Access Management Security Token Service |
Database data used by Oracle Entitlements Server for the Access Manager and Security Token Service policy store. |
The Middleware home and domain home where the Access Manager and Security Token Service are configured. |
The Middleware home and domain home where the Access Manager and Security Token Service are configured. |
To recover from loss of host, see Recovering Oracle Access Management Security Token Service After Loss of Host. |
|
Oracle B2B |
MDS schema |
The Administration Server domain directory, the Oracle home, and the product home if changes are made to the Oracle B2B configuration file |
The Managed Server |
See Recovering Oracle B2B for information about the file Xengine.tar.gz. |
|
Oracle BI EE |
MDS and BIPLATFORM schemas |
The Oracle home, the domain home, including the Managed Servers. |
The entity that has failed |
To recover, see Recovering Oracle BI Enterprise Edition. To recover from loss of host, see Recovering Oracle BI Enterprise Edition to a Different Host. |
|
Oracle BPEL Process Manager |
MDS and SOAINFRA schemas |
The Oracle home and the Administration Server domain directory |
The domain home and the Managed Server |
See Backup and Recovery Recommendations for Oracle BPEL Process Manager for information about backing up and recovering the database. |
|
Oracle Business Activity Monitoring |
MDS and SOAINFRA schemas |
The Oracle home, the Administration Server domain directory, the Managed Server directory. |
The Managed Server or the Oracle home, or both, depending on the extent of failure |
NA |
|
Oracle Business Intelligence Publisher |
BIPLATFORM schema |
The Oracle home, the domain, and the BI Publisher repository, which can be database or file-based. |
The domain home and the Managed Server |
To recover from loss of host, see Recovering Oracle Business Intelligence Publisher to a Different Host. If backup artifacts are restored from different times, then user accounts, user reports, and user permissions revert to the restored version. Restore all artifacts from the same point in time. |
|
Oracle Business Process Management |
MDS schema |
The Administration Server domain directory and the same data as Oracle BPEL Process Manager, as described in Backup and Recovery Recommendations for Oracle BPEL Process Manager. |
The same data as Oracle BPEL Process Manager and the Managed Server |
NA |
|
Oracle Business Rules |
MDS schema |
The Oracle home and the Administration Server domain directory |
The Managed Server where the soa-infra application is deployed |
NA |
|
Oracle Data Integrator |
ODI_REPO schema |
The Oracle home, the domain if Oracle Data Integrator is installed in a domain, and the ODI_Oracle_Home/oracledi/agent folder for each machine where a standalone agent is installed |
The Managed Server or the Oracle home, or both. If your environment contains the Oracle Data Integrator Standalone Agent or Oracle Data Integrator for Developers, restore the Oracle home, as described in Recovering the Oracle Home. If your environment contains Oracle Data Integrator deployed in a Managed Server, restore the Managed Server, as described in Recovering a Managed Server. |
To recover from loss of host, see Recovering Oracle Data Integrator to a Different Host. |
|
Oracle Data Service Integrator |
MDS schema |
The Oracle home and the Administration Server domain directory |
The Administration Server domain |
NA |
|
Oracle Directory Integration Platform |
ODSSM schema, used by Oracle Internet Directory |
The Administration Server domain directories, the Managed Server directories, and Oracle Internet Directory and its dependencies. |
The Managed Server where the Oracle Directory Integration Platform application is deployed. Oracle Internet Directory. |
To recover to a different host, see Recovering Oracle Directory Integration Platform to a Different Host. |
|
Oracle Enterprise Scheduler |
ESS schema |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
NA |
|
Oracle Event Processing |
MDS schema, which stores the .cqlx files packaged in a MAR |
The Oracle home and the Administration Server domain directory |
The Managed Server |
NA |
|
Oracle Forms Services |
Any user-configured database for Oracle Forms Services applications. |
The Administration Server domain, the Managed Server directory, and domain directory where Oracle Forms Services is located. |
The domain directory where Oracle Forms Services is located. |
To recover from loss of host, see Recovering Oracle Forms Services to a Different Host |
|
Oracle HTTP Server |
None |
The Oracle home and the domain, which can be either a standalone domain or the Oracle WebLogic Server domain. |
The Administration Server domain directory |
NA |
|
Oracle Identity Governance |
OIM, MDS, OPSS, and Oracle SOA Suite schemas and, optionally, the OID schema |
The domain, the Oracle home |
The domain or Oracle home depending on the extent of the failure. |
To recover from loss of host, see Recovering Oracle Identity Governance to a Different Host. |
|
Oracle Internet Directory |
ODS and ODSSM schemas |
The domain, which can be either a standalone domain or the Oracle WebLogic Server domain. |
The domain, which can be either a standalone domain or the Oracle WebLogic Server domain. |
To recover from loss of host, see Recovering Oracle Internet Directory to a Different Host. |
|
Oracle Managed File Transfer |
MFT and MDS and schemas |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
NA |
|
Oracle Mediator |
MDS and SOAINFRA schemas |
The Oracle home and the Administration Server domain directory |
The Managed Server where the soa-infra application is deployed |
NA |
|
Oracle Platform Security Services |
If a database-based Oracle Platform Security repository is used, the OPSS schema. If an Oracle Internet Directory based repository is used, an Oracle Internet Directory repository. |
The Oracle home and the Administration Server domain directory. Back up Oracle Internet Directory if Oracle Platform Security uses an Oracle Internet Directory based repository. |
The files listed in Recovering Oracle Platform Security Services. |
NA |
|
Oracle Real-Time Decisions |
The database containing analytic models and the RTD schema |
The Oracle home, the domain home, and the database containing analytic models |
The Managed Server |
Note that if backup artifacts are restored from a different time, the analytic models miss a period of learning, but their intelligence is unaffected. |
|
Oracle Real-Time Integration Business Insight |
The database containing analytic models and the Insight schema |
The Oracle home, the domain home, and the database containing the Insight schema |
The Administration Server domain directory |
NA |
|
Oracle Reports |
The database containing any job-related information |
The Administration Server domain and the Managed Server directory where Oracle Reports is located |
The Administration Server domain and the Managed Server directory where Oracle Reports is located. |
To recover from loss of host, see Recovering Oracle Reports to a Different Host |
|
Oracle Service Bus |
If its reporting feature is enabled, Oracle Service Bus creates two tables, WLI_QS_REPORT_DATA and WLI_QS_REPORT_ATTRIBUTE, in a user-specified schema. |
The Oracle home and the Administration Server domain directory |
The Managed Server |
NA |
|
Oracle SOA Suite |
MDS and SOAINFRA schemas |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
For loss of host, see Recovering Oracle SOA Suite After Loss of Host. See Backup and Recovery Recommendations for Oracle BPEL Process Manager for information about backing up and recovering the database. |
|
Oracle User Messaging Service |
UMS schema |
The Oracle home and the domain, which can be either a standalone domain or the Oracle WebLogic Server domain. |
The domain, which can be either a standalone domain or the Oracle WebLogic Server domain |
Make configuration changes as described in Recovering Oracle HTTP Server in a Standalone Domain to a Different Host or Recovering Oracle HTTP Server in a WebLogic Server Domain to a Different Host. |
|
Oracle Web Services Manager |
If a database-based MDS Repository is used, the MDS schema. |
The Oracle home and the Administration Server domain directory. If Oracle WSM uses a file-based MDS repository, back it up using a file copy mechanism. |
The Managed Server If Oracle WSM uses a file-based MDS repository, restore it from backup. |
NA |
|
Oracle WebCenter Capture |
CAPTURE schema |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
NA |
|
Oracle WebCenter Content |
OCS schemas |
The domain and the Oracle home If the Vault and WebLayout directories are not located in the domain directory, back up their directories, which are specified in: DOMAIN_HOME/ucm/CONTEXT-ROOT/config/config.cfg
Also, back up the following directory, which is located in a shared file system: DOMAIN_HOME/ucm/CONTEXT-ROOT/config |
The domain and the shared file system containing the Vault and WebLayout directories, depending on the severity of the failure. |
To recover, see Recovering Oracle WebCenter Content. To recover from loss of host, see Recovering Oracle WebCenter Content to a Different Host. |
|
Oracle WebCenter Content: Inbound Refinery |
None |
The Oracle home and the Administration Server domain directory. If the user data is not in the domain directory, back up the data. |
The entity that has failed. If the user data needs to be recovered, recover it. |
NA |
|
Oracle WebCenter Content: Records |
OCS schema |
Depends on Oracle WebCenter Content and has no additional backup artifacts, |
Depends on Oracle WebCenter Content and has no additional recovery artifacts, |
NA |
|
Oracle WebCenter Portal |
MDS and WEBCENTER schemas |
Administration Server domain |
The Administration Server domain |
NA |
|
Oracle WebCenter Portal's analytics data |
ACTIVITIES and MDS schema |
The Oracle home and the domain home, |
The Oracle home and the domain home. |
NA |
|
Oracle WebCenter Portal's discussion server |
DISCUSSIONS schema |
The Administration Server domain |
The Administration Server domain |
NA |
|
Oracle WebCenter Portal's portlet producer |
PORTLET schema |
The Administration Server domain |
The Administration Server domain |
NA |
|
Oracle WebCenter Sites |
WCSITES schema |
The Oracle home and the Administration Server domain directory. If the WebCenter Sites configuration files are located outside of the Oracle home directory, back up those files as well. Ensure to back up WebCenter Sites shared filesystem (specified by the
|
The Oracle home and the Administration Server domain directory. If the WebCenter Sites configuration files are located outside of the Oracle home directory, restore those files as well. Ensure to restore WebCenter Sites shared filesystem (specified by the
|
NA |
|
Oracle WebLogic Server |
By default, does not depend on any database repository. However, applications deployed on Oracle WebLogic Server may use databases as data sources. |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
If you use Whole Server Migration, see Recovering Oracle WebLogic Server with Whole Server Migration. |
|
Oracle WebLogic Server JMS |
Only if JMS is database-based |
The Oracle home and the Administration Server domain directory |
The entity that has failed |
See Backup and Recovery Considerations for Oracle WebLogic Server JMS. |
- Backup and Recovery Considerations for Oracle WebLogic Server JMS
- Backup and Recovery Recommendations for Oracle BPEL Process Manager
Parent topic: Introduction to Backup and Recovery
Backup and Recovery Considerations for Oracle WebLogic Server JMS
If you are using file-based JMS, use storage snapshot techniques for taking consistent online backups. Alternatively, you can use a file-system copy to perform an offline backup.
If the JMS persistent store is file-based, recover it from backup. If the JMS persistent store is database-based, recover the database to the most recent point in time, if needed. Note the following:
-
Always try to keep JMS data as current as possible. This can be achieved by using the point-in-time recovery capabilities of Oracle Database, recovering to the most recent time (in the case of database-based persistence) or using a highly available RAID-backed storage device (for example, SAN/NAS).
-
If you are using a file-based JMS, you can use storage snapshots to recover.
-
If, for whatever reason, you need to restore JMS data to a previous point in time, there are potential implications. Restoring the system state to a previous point in time not only can cause duplicate messages, but can also cause lost messages. The lost messages are messages that were enqueued before or after the system restore point time, but never processed.
Use the following procedure before recovery to drain messages in the JMS queue after persistent-store recovery to avoid processing duplicate messages:
Note:
Do not drain and discard messages without first being certain that the messages contain no data that must be preserved. The recovered messages may include unprocessed messages with important application data, in addition to duplicate messages that have already been processed.
-
Log into the Oracle WebLogic Server Administration Console.
-
Before recovery, configure JMS server to pause Production, Insertion, and consumption operations at boot time to ensure that no new messages are produced or inserted into the destination or consumed from the destination before you drain stale messages. To do this:
-
Expand Services, then Messaging, and then click JMS Servers.
-
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
-
On the Configuration: General page, click Advanced to define the message pausing options. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.
-
Click Save.
-
Use the following procedure after recovery:
-
After recovering the persistent store, start the Managed Servers.
-
Drain the stale messages from JMS destinations, by taking the following steps:
-
Expand Services, then Messaging, and then JMS Modules.
-
Select a JMS module, then select a target.
-
Select Monitoring, then Show Messages.
-
-
Click Delete All.
-
Resume operations, by taking the following steps:
-
Expand Services, then Messaging, and then JMS Servers.
-
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
-
On the Configuration: General page, click Advanced. Deselect Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.
-
Click Save.
-
If the store is not dedicated to JMS use, use the Oracle WebLogic Server JMS message management administrative tool. This tool can perform import, export, move, and delete operations from the Administration Console, MBeans, and WLST.
For applications that use publish and subscribe in addition to queuing, you should manipulate topic subscriptions in addition to queues.
-
Backup and Recovery Recommendations for Oracle BPEL Process Manager
Back up the database after any configuration changes, including changes to global fault policies, callback classes for workflows and resource bundles that can potentially be outside the suitcase. Also back up the database after deploying a new composite or redeploying a composite.
Recover the database to the most recent point in time, if needed. Point-in-time recovery ensures that the latest process definitions and in-flight instances are restored. However, this may result in reexecution of the process steps. Oracle recommends that you strive for idempotent Oracle BPEL Process Manager processes. If the system contains processes that are not idempotent, you must clean them up from the dehydration store before starting Oracle Fusion Middleware. See Administering Oracle SOA Suite and Oracle Business Process Management Suite .
Because instances obtain the process definition and artifacts entirely from the database, there is no configuration recovery needed after the database is recovered to the most current state; instances should continue to function correctly.
For redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition since the process definition is stored in database repository where dehydrated instances are also stored.
Assumptions and Restrictions for Backup and Recovery
Certain assumptions and restrictions apply to the backup and recovery procedures in this book.
Besides the following restrictions, also see the restrictions listed in Limitations and Restrictions for Backing Up Data.
-
Only the user who installs the product or a user who has access privileges to the directories where Oracle Fusion Middleware has been installed should be able to execute backup and recovery operations.
-
If a single Managed Server and Administration Server run on different hosts and the Managed Server is not in a cluster, you must use the pack and unpack commands on the Managed Server to retrieve the correct configuration.
If you are using Cold Failover Cluster or Disaster Recovery, refer to Setting Up and Managing Disaster Recovery Sites in the Disaster Recovery Guide for additional information.
Parent topic: Introduction to Backup and Recovery