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:

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:

The overwhelming majority of Oracle patches are downloaded from Oracle Support and come in the form of an OPatch. Many, but not all, of these patches provide some form of 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 the JDK.

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

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

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 is 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:

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.

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:

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 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:

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 defined for code deployments, 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_server1/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.

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.

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 suggested guidelines for your backup schedule, but should be customized based on your needs and operational standards: