Backup and Recovery for Oracle SOA Suite 12C

Arun Pareek

December 2015

 In this article written by Ahmed AboulnagaArun Pareek, and Harold Dost, authors of the book Oracle SOA Suite 12c Administrator's Guide, you have already recognized the importance of establishing well-defined backup and recovery procedures as an administrator. It is easy to write in length on this topic alone, discussing various backup, restore, failover, migration, and disaster recovery strategies. Fortunately, we will focus on the most important areas in this chapter to simplify the process for you as best as we can. As long as you understand a few core concepts regarding the overall backup and recovery strategy for Oracle SOA Suite 12c, you can implement it in any number of ways.

Establishing a backup and restore strategy is important because it provides you the ability to restore your environment in the event of a critical infrastructure or hardware failure. For instance, if you experience a hard drive failure, the disks may have to be replaced and the software restored from backup. It also provides you the ability to restore your environment to a previously working snapshot in the event of a faulty patch, faulty code deployment, or faulty configuration. In some cases, these faulty updates are not undoable and thus a restore may be needed.

In this chapter, we will cover the following key areas:

  • Understanding what needs to be backed up
  • The rrecommended backup strategy
  • Implementing the backup process
  • Recovery strategies

(For more resources related to this topic, see here.)

There are really two types of backups you can perform—offline backups and online backups. Offline backups are taken when the entire environment is down. This is the preferred approach, as all tiers are backed up at the same point, ensuring that a full restore will be an exact point in the time snapshot. Unfortunately, it is usually difficult to find the downtime needed for a full offline backup, and online backups are more commonly implemented. They are taken while the system is running and require no downtime. Compared to offline backups, online backups are generally more involved in their initial setup, and certain additional factors need to be considered to ensure that a proper restore is performed.

The types of data that are typically backed up are as follows:

  • Static files (for example, domain configuration files, software binaries, and patches)
  • Runtime artifacts (for example, application deployments, instance data and metadata, messages in queuing systems, and transaction logs)

So when should you back up your static files? As long as they don't change; technically, a single valid backup is all that is required. Configuration changes or the application of patches tend to change the contents of these static files, hence prompting the need to create another backup. Runtime artifacts or dynamic data, such as continually updated instance data in the database, may need to be backed up regularly. There are cases where both online and offline backups may be valid for these types of data, and we will discuss them in more detail later on in this chapter.

In the unfortunate event that a recovery is needed, performing a complete restore can guarantee full restoration of your environment. However, this is time consuming and the appropriate downtime may not be afforded to do so. Thus, once you understand the different types of files that need to be backed up, you will know what needs to be restored. Installing a highly available infrastructure helps reduce the risk by ensuring continued operation of your environment in the event of a software or hardware failure, simplifying the restoration process.

Understanding what needs to be backed up

Before describing how to back up your environment, it is important to understand what needs to be backed up first. We differentiate between static files, which are files that do not change frequently such as the software installation binaries, and dynamic data, otherwise referred to as runtime artifacts, which could include frequently updated data such as instance information and deployment metadata.

Static files

Static files and directories are those that do not change frequently. These files should be backed up when required, particularly when configuration changes, patching, or installations have been performed since the last backup. In most cases, static files can be backed up both online and offline.

Oracle system files

System files include the oraInst.loc and beahomelist files. These files point to the location of Oracle Inventory and the WebLogic Server Home, respectively. This enables future patching or installations of other Oracle products to easily recognize where your software is installed, check for their existing versions, and update these inventories accordingly, if needed. In Oracle SOA Suite 12c, Oracle inventory resides in the Oracle SOA home by default.

The beahomelist file is typically located in the users' home directory and varies according to the operating system. The BEA Home list contains the location of your Oracle WebLogic Server installation (which is also installed under Oracle SOA Home).

The oraInst.loc configuration file contains the location of your Oracle inventory. Oracle inventory contains metadata of all the installed Oracle products on your server. It is updated when new Oracle products are installed on your server or the existing software is upgraded. An example of the contents of oraInst.loc is as follows:

  • inventory_loc=/u01/oracle/products/Oracle_SOA1/inventory
  • inst_group=oinstall

The locations of each of these files in a standard Linux installation are shown in the following table:

File

Description

Sample location

BEA Home List

This points to the Oracle WebLogic Server installation directory and is typically created in the users' home directory.

/home/oracle/bea/beahomelist

Oracle Installation Location

This is a configuration file that points to the location of Oracle Inventory.

/etc/oraInst.loc

Oracle Inventory

The location is determined by oraInst.loc.

/u01/oracle/products/Oracle_SOA1/inventory

These files should be backed up after initial installation or after any patch update or upgrade. A standard filesystem backup is sufficient.

A JDK

A JDK is typically installed outside of Oracle SOA Home. The location of your JDK can be shared between the servers in your cluster or it may be installed on each server separately.

Regardless of its location, your JDK should be backed up after new installations and/or a patch update or upgrade. Starting with Java 7, JRockit and Hotspot are merged into a single JVM to make a best breed of JVM. In the previous version of Java, you would have to select either the Sun JDK or JRockit JDK for installation—this is no longer the case with Java 7.

Here is an example of the location of a JDK installation outside your Oracle SOA Home:

/u01/oracle/products/jdk1.7.0_55

Oracle SOA Home

Oracle SOA Home contains numerous files, components, and shared components. This possibly includes the binaries and configuration files for Oracle WebLogic Server, Oracle SOA Suite, OSB, OEP, BPM Suite, BAM, as well as Oracle Common components.

For example, Oracle SOA Home, denoted as the $ORACLE_HOME environment variable, may be set to /u01/oracle/products/Oracle_SOA1. The backup commands later on in this chapter back up everything under $ORACLE_HOME and should be run after initial installation or after any patch update or upgrade. A standard filesystem backup is sufficient.

Runtime artifacts

Oracle documentation refers to data that is dynamically updated and required for runtime operations as runtime artifacts. In essence, it is the data and/or configuration that is regularly accessed and/or updated during runtime. We will describe each of these areas in the later sections of this chapter.

A Database

A database is configured during the installation to store the SOA Infrastructure (instance-specific data) and MDS (deployment metadata) data. Oracle SOA Suite 12c, or rather, Oracle Fusion Middleware 12c (12.1.3) is currently certified only on Oracle database versions 12.1.0.1+, 11.2.0.3+, and 11.1.0.7+. The Oracle database can be backed up via a tool such as Oracle Recovery Manager (RMAN).

The database maintains data related to in-flight instances, deployed SOA composites, and configuration, among other things. For example, if you deploy a composite today and perform a database restore for the day before, that deployed composite will not be available. Also note that some configurations, such as that of the Oracle BPEL Process Manager Engine, Oracle BPM Engine, Mediator, and Common Configuration are stored in the database.

Configuration data is typically stored in the database, ensuring that each managed server in the cluster has a consistent view of this data.

The schemas that need to be backed up are listed in the following table. It is recommended to have nightly backups of the database for critical business applications:

Schema

Description

<PREFIX>_ESS

Enterprise Scheduler Service

<PREFIX>_IAU

<PREFIX>_IAU_VIEWER

<PREFIX>_IAU_APPEND

Audit Services

<PREFIX>_MDS

Metadata Services

<PREFIX>_MFT

Managed File Transfer

<PREFIX>_ORABAM

Business Activity Monitoring

<PREFIX>_OPSS

Oracle Platform Security Services

<PREFIX>_SOAINFRA

SOA Infrastructure

<PREFIX>_STB

Services Tools Bundle

<PREFIX>_UMS

User Messaging Service

JMS file stores

Persistent stores host information such as JMS queues and JMS topics, also referred to collectively as JMS destinations. Persistent stores can either be file based or JDBC enabled (that is, saved in the database). Most Oracle SOA Suite 12c clustered installations utilize file-based stores for performance purposes. File-based stores essentially provide persistence capabilities to Oracle WebLogic Server subsystems and services through the use of a built-in, high-performance storage solution.

Because these file-based persistent stores save JMS messages, durable subscriber information, and temporary messages sent to unavailable destinations using the Store-and-Forward features, it is not possible for us to take their consistent backups. Restoring these persistent stores may result in data inconsistency, even if they were backed up offline. These persistent stores often (and should) reside on redundant fault-tolerant storage that is accessible to all nodes of the Oracle SOA Suite 12c cluster. Alternatively, you may have already used JDBC-enabled stores for your JMS destinations so that they are maintained in and thus backed up with the database (meaning filesystem backups of these objects are not necessary).

Backing up and restoring the JMS file-based persistent stores may result in data inconsistency. Instead, you can ensure the availability of the file store to all servers in your cluster.

The following table shows an example of the location of persistent stores required by Oracle SOA Suite 12c clusters. These stores are shared and accessible to all nodes of the clusters (in this example, a two-node cluster):

JMS file store name

Sample location

Shared

BPMJMSFileStore_auto_1

/share/soa_domain/soacluster/jms/BPMJMSFileStore_auto_1

Yes

BPMJMSFileStore_auto_2

/share/soa_domain/soacluster/jms/BPMJMSFileStore_auto_2

Yes

MFTJMSFileStore_auto_1

/share/soa_domain/soacluster/jms/MFTJMSFileStore_auto_1

Yes

MFTJMSFileStore_auto_2

/share/soa_domain/soacluster/jms/MFTJMSFileStore_auto_2

Yes

SOAJMSFileStore_auto_1

/soa_domain/soacluster/jms/SOAJMSFileStore_auto_1

Yes

SOAJMSFileStore_auto_2

/soa_domain/soacluster/jms/SOAJMSFileStore_auto_2

Yes

UMSJMSFileStore_auto_1

/share/soa_domain/soacluster/jms/UMSJMSFileStore_auto_1

Yes

UMSJMSFileStore_auto_2

/share/soa_domain/soacluster/jms/UMSJMSFileStore_auto_2

Yes

By virtue of the file stores being shared, they are accessible to all nodes in the cluster. The recommendation here is to implement one of the following backup strategies for JMS file-based persistent stores:

  • Move the JMS modules to a JDBC-enabled persistent store. Database backups will ensure the consistency of the data in the event of a database restore, but restoring to older backups of the database may result in data inconsistency.
  • Ensure that the file-based persistent stores reside in fully redundant shared storage accessible to all nodes of the cluster, and guarantee its availability. Backing up these stores is possible, but there are implications regarding message loss and message duplication should you choose to restore them.

The only scenario perhaps where file stores can be backed up is in non-production environments, where data consistency is not critical. In this case, it is still recommended that you take an offline backup (that is, where all midtier nodes are shut down while the backup is performed). Restoring from this backup essentially performs a point-in-time recovery, where the file stores may contain older JMS messages that have already been consumed and processed. It may also result in lost messages. For example, this may include messages that may have been enqueued but not consumed before the backup. The only advantage of backing up your JMS file store is that it allows the administrator to always take a single, working, and consistent backup of the environment, but with the risk of data duplication and/or inconsistency as a result of restoring older file stores.

Transaction logs

Transaction logs store information about committed transactions that are coordinated by Oracle WebLogic Server that may not have been completed. The transaction logs, or TLOGs, provide Oracle WebLogic Server with a mechanism to recover from system crashes or network failures.

TLOGs can either be saved to WebLogic Server's Default Store or to a database via a JDBC store. TLOGs that are targeted to Default Store are file based, and thus the backup behavior is similar to that of JMS file-based persistent stores. Oracle WebLogic Server 12c, however, allows transaction logs to be stored in a JDBC store, thus eliminating the need for filesystem backups. The following screenshot shows where to select the Transaction Log Store type:

Figure 10.1: Selecting the Transaction Log Store type in the WebLogic Server Administration Console

In the event that the Default Store is selected, it is recommended to set it to a directory on highly available and shared storage. This is typically a requirement for multinode installations of Oracle SOA Suite 12c anyway. This can be configured by logging in to the Oracle WebLogic Server Administration Console and navigating to Environment | Servers | soa_server1 | Configuration | Services and setting the value of Directory.

Do not attempt to delete or restore TLOGs that are file based. It may result in data inconsistency.

The recommendation, therefore, is to ensure that the transaction logs that are logged to Default Store reside in fully redundant shared storage that is accessible to all nodes of the cluster and guarantee its availability. Backing up the transaction logs is suggested, but there are implications regarding message loss and message duplication should you choose to restore them.

For transaction logs that are stored in the database, ensure that the appropriate database schema it is connected to is backed up regularly via RMAN.

The SOA domain

Typically, every Oracle SOA Suite 12c installation includes at least one domain extended with SOA extensions (for example, soa_domain), which hosts your administration and managed servers configuration. Though many of the files in your Domain Home are static in nature, several of them change periodically (for example, log files). By default, Domain Home is located under the Oracle SOA Suite installation directory (for example, $ORACLE_HOME/user_projects/domains/soa_domain), but it may reside elsewhere depending on what was specified during the domain creation. A typical SOA domain will fall within the 2 GB to 4 GB size range and will contain a multitude of file types that include the following:

  • Startup scripts
  • Libraries
  • Domain configuration files
  • Logs
  • Deployed and extracted Java applications

The configuration files most relevant to your domain installation are listed in the following table. Backing up your domain is usually recommended if one or more of these files are updated:

Component

Configuration file location

Domain, JMS, BAM, B2B, Business rules, BPM, OWSM, and OPSS configuration

$DOMAIN_HOME/config/*

Oracle WebLogic Server Startup Scripts

$DOMAIN_HOME/bin/*

Oracle WebLogic Server Node Manager

$DOMAIN_HOME/nodemanager/nodemanager.properties

Oracle WebLogic Server

$ORACLE_HOME/wlserver/common/bin/wlsifconfig.sh

Oracle WebLogic Server

$ORACLE_HOME/wlserver/common/bin/commEnv.sh

In most cases, you do not need to back up managed server directories separately because AdminServer contains information about all the managed servers in its domain.

Managed servers do not require AdminServer to be up during normal operation. However, as an administrator, your view of the health and performance of the infrastructure may be restricted. Furthermore, it prevents you from making any changes to the domain's configuration if AdminServer is down.

A managed server maintains a local copy of the domain configuration. If you attempt to start a managed server while AdminServer is down, the managed server uses a local copy of the domain configuration and continues to periodically attempt to reconnect with AdminServer. The managed server, thus, runs in what is called the Managed Server Independence (MSI) mode. When it connects successfully, the configuration state is synchronized.

It is, therefore, recommended that you take a full backup of your Domain Home periodically while your infrastructure, especially AdminServer, are offline. Technically, backing up the Domain Home on the machine that runs AdminServer is sufficient, though it might make your life easier to back up the domain on the other servers in your cluster as well.

The recommended backup strategy

Generally speaking, your environment should be backed up on a regularly scheduled basis. These are standard operating procedures, and we will discuss them toward the end of this section. In addition to this, occasional one-off backups may be needed. By considering the proposed backup strategy outlined here, you should be protected for the majority of cases and will be able to perform effective recovery, if needed.

The following table is a summary of the actions described in this section, as well as when and what type of backup to perform:

Event

When

Backup schedule

Backup type

New installation

After installation

One-off

Offline

Upgrading

Before and/or after upgrading

One-off

Offline

Applying patches

Before and/or after patching

One-off

Offline

Configuration changes

Before and/or after changes

One-off

Offline

Architectural changes

Before and/or after changes

One-off

Offline

Code deployment

Only if needed

Never

Offline

After a new installation

Installing Oracle SOA Suite 12c involves creating a database; running the Repository Creation Utility (RCU) to create all the required database schemes; installing the binaries for Oracle WebLogic Server 12c, JDK, and Oracle SOA Suite 12c; followed by the creation of the SOA domain. In high-availability installations of two or more nodes, further configuration and setup is required.

It is, therefore, recommended that you perform a full offline backup of your environment after confirming the successful installation of your infrastructure. This includes taking a back up of the following:

  • Oracle system files
  • A JDK
  • Oracle SOA Home
  • The SOA domain
  • A database (using a tool such as RMAN)

Before upgrading

Prior to upgrading from Oracle SOA Suite 12c (12.1.3) to a later patchset, you may decide on performing a back up of the environment for the purpose of rolling back in the event of an unforeseen upgrade problem.

In this case, it is recommended that you perform a full offline backup of the entire infrastructure, which includes:

  • Oracle system files
  • A JDK
  • Oracle SOA Home
  • JMS file stores
  • Transaction logs
  • The SOA domain
  • A database (using a tool such as RMAN)

Before applying patches

The overwhelming majority of Oracle patches are downloaded from Oracle Support and come in the form of OPatch. Many, but not all, of these patches provide some form of a rollback mechanism. If the patch application is unsuccessful, it will not be installed. If the patch application is successful but does not resolve your particular problem, it can be rolled back (in other words, uninstalled).

These patches can be OPSS patches, JDK patches, OWSM patches, Oracle WebLogic Server patches, Oracle SOA Suite patches, Oracle BPM patches, OSB patches, BAM patches, or any type of patch related to one of the many underlying subcomponents. Even though most (but not all) patches can be rolled back, there are rare cases where patches can corrupt or produce undesirable results in your system. It is both our and Oracle's recommendation that you take a back up of your environment prior to applying a patch. However, by reviewing the readme of the patch and deciphering the type of change, it may not be necessary to perform a full backup, and a partial backup may only be needed.

If the patch is a JDK patch, simply perform an offline backup of a JDK.

If the patch is an Oracle SOA Suite 12c patch (including Oracle WebLogic Server), simply perform an offline backup of the following:

  • Oracle SOA Home
  • The SOA domain
  • A database (using a tool such as RMAN)

When in doubt, perform a full offline backup of the entire infrastructure, which includes backing up the following:

  • Oracle system files
  • A JDK
  • Oracle SOA Home
  • JMS file stores
  • Transaction logs
  • The SOA domain
  • A database

Before configuration changes

There are many types of configuration changes that can be performed and an even more endless list of possible backup scenarios for each of the configuration changes. Some settings are stored in configuration files (for example, config.xml) and startup scripts (for example, setSOADomainEnv.sh), while other settings such as BPEL Process Manager configuration settings are stored in the database. When in doubt, perform a full offline backup prior to making any configuration change (though this may be excessive in most cases).

Configuration changes can usually be rolled back by simply undoing the configuration change itself, though there are rare scenarios where damaging repercussions can occur. For example, modifying the number of maximum connections in your connection pool typically involves zero risk. On the other hand, in certain scenarios where a second SOA server has never yet been started and conflicting JVM configuration are found across the cluster, irrecoverable startup issues may occur on that second SOA server.

We, therefore, recommend you to perform a back up, at minimum, of the following prior to making configuration changes:

  • The SOA domain
  • A database

Configuration changes that are committed to the database can usually be rolled back by undoing them or restoring the database itself. Configuration changes to any of the software installs (for example, files under $ORACLE_HOME/soa, $JAVA_HOME, and $ORACLE_HOME/wlserver) are usually undoable by simply restoring the configuration change to its original settings.

Before architectural changes

Examples of architectural changes include extending your domain to install additional products or converting your single-node installation to a cluster. Even though performing these activities should not be a problem, the administrator often has to deal with unforeseen setbacks. Some architectural changes are simple while others are more involved. Performing a full offline backup of the entire infrastructure is recommended in these cases:

  • Oracle system files
  • A JDK
  • Oracle SOA Home
  • The SOA domain

The database, JMS file stores, and transactions logs may not need to be backed up, as the impact on transactional data due to these changes is usually low.

After upgrade, patch, configuration, or architectural changes

After finishing an upgrade, applying one or more patches, or performing major configuration or architectural changes, you probably want to perform a full offline backup of your environment in order to maintain a snapshot of a working installation that you can recover in the future, if need be.

For that reason, performing a full offline backup of the entire infrastructure in the event of any of these actions is recommended. The components to be backed up are:

  • Oracle system files
  • A JDK
  • Oracle SOA Home
  • JMS file stores
  • Transaction logs
  • The SOA domain
  • A database

Before or after a code deployment

It is often unnecessary to perform backups before or after a code deployment, unless major architectural changes or high-risk activities are involved. You should have a change control strategy for code deployments defined, wherein if a deployment fails or a code deployment is successful but needs to be rolled back, you have the ability to redeploy the prior version of the code. Code could include Java applications, SOA composites, DVMs, or even schemas and WSDLs.

Prior to a restore and to avoid any issues, it is recommended that you delete the contents under $DOMAIN_HOME/servers/soa_server/dc, which contain the converted SOA source code downloaded from the database. All SOA composites and artifacts are stored in the MDS. In the event that no formal change control strategy is in place, reverting to a previous snapshot of the database will restore your SOA composites to their original version at the time of the database backup. Therefore, if you require it, you may perform a full database backup before or after SOA code is deployed to protect yourself.

Ongoing backups

As part of your operation, maintenance, and support activities, you will want to regularly schedule backups of your environment. Some backups may be nightly, while others may be weekly. If little to no changes take place in your midtiers, nightly delta filesystem backups of the Oracle SOA Home, JDK, and SOA domain may suffice (after a full offline backup is performed at least once). In this case, the only ongoing change that really does occur is the growth of log files.

As for the JMS file store and transaction logs, as mentioned earlier, these are not backed up. In the event of their irrecoverable failure, the best option will be to recreate them.

As a good practice, your databases should be backed up consistently. Daily and weekly full backups of databases are not uncommon, and the database administrator will need to be engaged in this activity.

With the exception of logs, files within your SOA domain rarely change unless there is a code deployment or configuration change. If neither of these two activities are performed, delta filesystem backups are often sufficient.

As for ongoing backups, certain components such as the Oracle system files, JDK, and Oracle SOA Home do not require frequent backing up unless changes occur to them. Regardless of this, implementing some type of ongoing and regular backup is typically recommended. This table provides a suggested guideline for your backup schedule, but should be customized based on your needs and operational standards:

Component

Backup schedule

Backup type

Comments

Oracle system files

Monthly

Online

 

A JDK

Monthly

Online

 

Oracle SOA Home

Monthly

Online

 

The JMS file store

Never

-

Recreate if recovery is needed. Data loss or inconsistency may occur.

Transaction logs

Never

-

Recreate if recovery is needed.

The SOA domain

Weekly

Online*

Online backups are acceptable as long as no changes to the domain have been made.

A database

Daily

Online

 

Implementing the backup process

Now that we have described the types of files to be backed up, the frequency of backup needed, and the locations of what needs to be backed up, you may use third-party tools or commands to perform your filesystem backups. The backup commands and instructions in this section are meant to serve as a workable guideline to cover all areas requiring backup and are general in nature. They assume a Linux-based operating system with gtar installed, but they may be substituted with alternative file manipulation commands as needed. We recommend that you dedicate a backup mount point with ample storage and timestamp each backup file with the date and time in the file name. Many backup solutions that can be leveraged to automate and simplify the administration of the entire backup process are available on the market.

Oracle system files

The Oracle system files are comprised of server specific files under the /etc system directory as well as beahomelist:

  1. Set up your environment if it is not already set using the following commands. This may vary depending on your installation:
    export BACKUP_DIR=/backup 
    export TIME=`date "+%Y%m%d_%k%M"`
  2. Execute the following commands to take a backup of the Oracle system files under /etc and /home/oracle/bea:
    gtar -czvf $BACKUP_DIR/etcora.${TIME}.tgz /etc/oraInst.loc /etc/oratab
    gtar -czvf $BACKUP_DIR/beahomelist.${TIME}.tgz /home/oracle/bea

A JDK

Back up the JDK as per the following instructions and modify the directory locations accordingly:

  1. Set up your environment if it is not already set. This may vary depending on your installation:
    export BACKUP_DIR=/backup
    export JAVA_HOME=/u01/oracle/products/jdk1.7.0_55
    export TIME=`date "+%Y%m%d_%k%M"`
  2. Execute the following command to take a backup of the JDK:
    gtar -czvf $BACKUP_DIR/jdk.${TIME}.tgz $JAVA_HOME

Oracle SOA Home

Oracle SOA Home consists of several installed components such as WebLogic Server, Oracle SOA Suite, OSB, coherence, shared libraries and utilities, and more. Back up the JDK as per the following instructions:

  1. Set up your environment if it is not already set. This may vary depending on your installation:
    export BACKUP_DIR=/backup
    export ORACLE_HOME=/u01/oracle/products/Oracle_SOA1
    export TIME=`date "+%Y%m%d_%k%M"`
  2. Execute the following commands to take a backup of the files:
    gtar -czvf $BACKUP_DIR/oraclehome.${TIME}.tgz $ORACLE_HOME

The Domain Home

The Domain home is sometimes created under the $ORACLE_HOME/user_projects/domains directory, but it is not a requirement and often is different in clustered installations. It is only necessary to take a back up of the domain on which AdminServer is running, but you may also opt to take a back up of the domain on all other nodes of the cluster for ease of restoration in future using following instructions:

  1. Set your environment if it is not already set. This may vary depending on your installation:
    export BACKUP_DIR=/backup
    export DOMAIN_NAME=soa_domain
    export DOMAIN_HOME=/u01/oracle/products/Oracle_SOA1/user_projects/domains/${DOMAIN_NAME}
    export TIME=`date "+%Y%m%d_%k%M"`
  2. Execute the following commands to take a backup of the files:
    gtar -czvf $BACKUP_DIR/domain.${TIME}.tgz $DOMAIN_HOME

A Database

Contact your DBA and use a backup utility such as RMAN to perform nightly hot backups.

Another crude way to take a backup of your database is to use the Oracle Data Pump utility commands such as expdp that can be used to export the database schemas and the impdp command that is used to import the dump file to the database. Because these are the low-level database methods, this approach is more suitable when performing an initial data migration to a fresh installation or cloning of an environment that does not contain any business data yet.

Recovery strategies

The purpose of recovering your environment is to restore it due to a software failure (such as a faulty patch or misconfiguration), hardware failure (such as an internal hard disk failure), or due to a need to perform a point-in-time recovery (to undo configuration or architectural changes that have proven defective or problematic).

Multiple factors should be considered before recovering an environment. It depends on which component failed and what point in time you want to recover it. Additional factors, such as ensuring consistency among components, is equally important. Full restores of the entire midtier and database to the same point in time are perhaps the simplest and least risky of all approaches, but are time consuming in nature. Furthermore, when a simple faulty configuration change needs to be rolled back, do you really need to restore the entire environment or just restore that particular component?

The installation of an Oracle SOA Suite 12c environment relies on interdependent components that contain configuration information, applications (including Java, composite and service bus), and data that must be kept in synchronization. As a consequence, both backing up and restoring an Oracle SOA Suite 12c installation requires more thought than merely unzipping the backup files.

By now, you have a good understanding of how Oracle SOA Suite 12c functions, which files and components it requires and relies on, and what area to perhaps recover in the event of a failure. You also understand the implications of restoring different components separately.

All components, with the exception of the database, are backed up using standard file system commands or tools. To recover your Oracle SOA Suite 12c environment, simply restore the file or files of the component that needs to be restored. For example, any combination of the following may need to be restored depending on the type of failure:

  • Domain: This can be used, for example, in the event of a severe configuration failure of the domain in which it is unable to start.
  • Oracle SOA Home: This can be used, for example, to restore the entire infrastructure (or subset of it) to a previous release after a patch has been applied.
  • JDK: This can be used, for example, if you want to revert to a previous version of your JDK.

    Oracle system files: This can be used, for example, in the event of a bad software installation and you wish to restore the Oracle Inventory to its original state. Many Oracle patches include their own rollback mechanism. Refer to their README files for rollback instructions in order to avoid a lengthy restore process.

In almost all cases, your Oracle SOA Suite 12c environment must be offline to recover. Though this is possible, it is dangerous to try to recover Oracle SOA Suite, Oracle WebLogic Server, the JDK, or any other component while the infrastructure is running.

There are implications to recovering JMS data to a previous point in time. As discussed earlier, we generally do not recommend backing up (or restoring) of the JMS file stores unless you have a full understanding of the implications of such an activity as it can result in duplicate or lost messages. In many cases, it is probably better to recreate the persistent stores in the event that they are accidentally deleted or are in need of recovery.

Since the transaction log is accessible to all nodes of your cluster, in the event of a server failure, the other machines should be able to process the transactions. Even in the unlikely event of a full environment crash, the Transaction Recovery Service gracefully handles transaction recovery once the servers are brought up.

Furthermore, we recommend that you clear the following temporary and state-based directories after a restore but prior to starting the managed servers as their contents are dynamically generated/loaded:

  • $DOMAIN_HOME/servers/*/cache/*
  • $DOMAIN_HOME/servers/*/data/*
  • $DOMAIN_HOME/servers/*/dc/*
  • $DOMAIN_HOME/servers/*/tmp/*

Summary

Backing up and restoring an environment should be relatively simple. After all, software is merely a bunch of files scattered on various filesystems. However, the two challenges that Oracle SOA Suite 12c administrators face when the need to restore arises are as follows:

  • To identify what exactly needs to be recovered
  • At what state or point in time you should recover them

In this article, we described all the various components that need to be backed up in an Oracle SOA Suite 12c environment, then followed up with detailing how to actually perform the backup. Specifically, we covered the following:

  • The various static files in an Oracle SOA Suite 12c installation such as Oracle system files, the JDK, and the Oracle SOA Home
  • Runtime artifacts that include the database and SOA domain
  • The implications of backing up and restoring JMS file stores and transaction logs
  • A backup strategy; focusing on what needs to be backed up after installations, upgrades, patches, and configuration changes; as well as a recommended regular backup schedule
  • The backup commands for Linux-based installations
  • Key recovery strategies and considerations

At this point, you should be fully capable of backing up your environment with a thorough enough understanding of when to restore individual components as needed.

Resources for Article:


Further resources on this subject:


You've been reading an excerpt of:

Oracle SOA Suite 12c Administrator's Guide

Explore Title