1. System Administrator's Guide
  2. Backing Up and Restoring OSM Files and Data

9 Backing Up and Restoring OSM Files and Data

This chapter helps you understand how Oracle Communications Order and Service Management (OSM) is related to the Oracle Database backup and restore procedures.

About Backing Up and Restoring OSM Files and Data

It is critical that you have a schedule and procedures for backing up and restoring your production-ready OSM system. This chapter includes a suggested schedule and backup and restore considerations, as well as information about the components involved in the backup. You must consider your own business needs when determining your backup and restore strategy.

Backup and Restore Overview

Consider OSM information from the Oracle Database for backing up and restoring OSM.

Backup and Restore Schedule

OSM Home Directory

The OSM program files in the OSM home directory do not change as part of the ongoing operation of OSM, so regularly scheduled backups may not be required. You should determine when it is appropriate to back up these files based on when you make changes to the files.

Oracle Database

You should perform a complete backup of the OSM database after installation. The suggested schedule for post-install backups is to take an incremental (level 0 in RMAN) backup of the database monthly, a cumulative (level 1 in RMAN) backup weekly and a differential (level 1 in RMAN) backup daily. It is currently not possible to take consistent backups of database and transaction logs, because the transaction logs are file-based. For highest reliability use a highly available fault-tolerant storage (for example, SAN) for database and transaction log file stores.

WebLogic Server Files

Assuming that JMS JDBC store is configured, backups of the WebLogic domain directory and any external deployments should be done primarily after making changes to the configuration. These changes include adding deployments, changing domain configuration, and other administrative tasks.

If the persistent store for JMS is on the file system, that location should be backed up on the same schedule as the database.

The OSM attachments directory (see "OSM Attachment Directory") should also be backed up on the same schedule as the database, because it contains order-related data.

Backup and Restore Considerations

Overall considerations for OSM backup and restore include:

  • Test backup and restore procedures in a test or staging environment before they are used in production.

Backing Up and Restoring the OSM Files

This section describes how to backup and restore the OSM files in the OSM_home directory.

Backing Up the OSM Files

The OSM installer creates files in a user-specified location during OSM installation. The default location in the installer is /opt/OSM, but usually another value is supplied during installation. This location is usually referred to as OSM_home.

You can back up these files using the tar command to put them in a single file, and then storing the .tar file in a safe location.

Restoring the OSM Files

To restore the OSM files, remove the contents of the OSM_home directory, and extract the contents of the backed-up tar file into the OSM_home directory.

Oracle Database Backup Considerations

The Oracle Database Server provides several means of backing up information. The two recommended methods for ordinary backup and restore are provided in this section. There are no special considerations for OSM in determining the actual procedure for a backup or restore. Information about how to use the backup and restore methods considered in this section can be found in the Oracle Database documentation.

Database backup and restore procedures should be performed by a qualified database administrator.

RMAN Considerations

Recovery Manager (RMAN) is an Oracle Database utility that backs up, restores, and recovers Oracle databases. It backs up individual datafiles, and provides complete and incremental backup options. Following are some issues you should consider for using RMAN:

  • Because it backs up datafiles, this method is most appropriate for use when OSM is not sharing any tablespaces with other applications. If OSM is sharing its tablespaces with other applications, they will be backed up at the same time. This means that if the OSM data is restored, the information for any other applications will be restored as well. This may not be desired.

  • You should back up all of the permanent tablespaces that you have defined for OSM. For example, if you have different tablespaces for data and indexes, you should remember to back up both of them.

  • RMAN may be slower than Flashback. This might be an issue in a large production environment.

Oracle Flashback Technology Considerations

Oracle Flashback Technology comprises a group of features that support the viewing of past states of data without needing to restore backups. It provides the ability to restore an entire database or individual tables from a set point in time. Following are some issues you should consider if you choose to employ this backup method:

  • Because it backs up the entire database, this method is most appropriate for use when OSM is not sharing the database with other applications. If OSM is sharing the database instance with other applications, this method does not allow you to restore only the OSM portion of the database. This can cause data for other applications to be overwritten with older data.

  • The Flashback Database command does not restore or perform media recovery on files, so you cannot use it to correct media failures such as disk crashes.

  • Some editions of the Oracle Database software may not include this feature.

Mirroring Technology Considerations

Split mirrored hardware and software solutions provide a higher level of performance than RMAN and Oracle Flash Technology. Mirroring technology, such as the Oracle Sun ZFS Storage Appliance, enables very fast backup and restore that you can run online without overloading the system. You can use mirror splitting to back up ASM disks, the RDBMS data files, redo logs, and control files.

Oracle recommends that you consider a mirroring technology over other technologies for larger OSM installations. Using a mirroring solution in large OSM installations, provides the following benefits:

  • Before you purge a partition or upgrade OSM, Oracle recommends that you backup the database in case of a failure. Mirroring technology enables fast database backup and restore operations. This ability greatly reduces the time it takes to prepare for a purge or upgrade and reduces the time it takes to recover from purge or upgrade failures.

  • Taking a database snapshot for testing an upgrade procedure, troubleshooting a problem, and so on, becomes much less time consuming.

Backing Up and Restoring the WebLogic Server Configuration

The procedure in this section describes how to perform a full backup and restore of the WebLogic configuration for the domain used by OSM.

You must read through this entire section before starting the procedures. There may be pieces of information that you must retrieve from the domain before you shut it down.

There are several parts of the WebLogic Server configuration that should be backed up. They are not all required to be backed up on the same schedule, so consider the following when determining your WebLogic backup schedule. See "WebLogic Server Files" for more information about the backup schedule. The parts of the WebLogic configuration that must be backed up are the following:

  • WebLogic domain directory

  • WebLogic persistent store

  • OSM attachments directory

  • External deployments

  • Remote managed server directories (clustered server only)

Backing Up the WebLogic Server Configuration

This section relates to backing up WebLogic Server files for OSM.

Before You Back Up the WebLogic Server

There are some tasks that you must perform before starting the backup procedures in this chapter.

  • Configure WebLogic so that when the domain is restarted, OSM will not process any JMS messages. This ensures that when you restore the domain from the backup, you can verify the configuration before OSM starts processing messages.

  • Shut down all of the servers in the WebLogic domain that contains OSM. This includes any remote servers in a clustered environment.

Setting OSM to Pause Processing of JMS Messages

You can configure OSM to pause processing of JMS messages using the WebLogic Server Administration Console. By default, OSM has one JMS server, called oms_jms_server. If you have custom JMS servers defined, you should perform this procedure for each of them as well.

  1. Access the WebLogic Server Administration console Home window. See "Accessing the WebLogic Server Administration Console."

  2. In the Messaging subsection of the Services section, click JMS Servers.

    The Summary of JMS Servers window is displayed.

  3. Click on the name of the appropriate JMS server in the table.

  4. The settings for your JMS server are displayed with the Configuration tab and the General sub-tab selected. At the bottom of the window, expand the Advanced heading to display more options.

  5. Select the following options:

    • Insertion Paused At Startup

    • Production Paused At Startup

    • Consumption Paused At Startup

  6. Click Save.

  7. Exit the WebLogic console.

Note:

After you have taken the backup and restarted the WebLogic Server, to return the server to its normal state by following the procedure above, but deselecting the options listed above.

WebLogic Server Domain Directory

The WebLogic Server domain directory contains many important parts of the server configuration, such as the main configuration files, security files, and LDAP files.

You can back up these files using the tar command to put them in a single file, and then storing the .tar file in a safe location.

WebLogic Persistent Store

The default location for the persistent store for WebLogic is in a subdirectory of the domain directory. However, the persistent store may be required to be backed up separately, because it may be backed up on a separate schedule from the rest of the domain configuration. In addition, it is possible to configure this directory in a location outside the WebLogic domain directory. You can view the location of this directory in the WebLogic Server Administration Console. For information about accessing the WebLogic Console, see "Accessing the WebLogic Server Administration Console."

From the Home window of the WebLogic Console, Click Persistent Stores in the right pane under Services. The Persistent Stores window is displayed containing a list of the persistent stores that have been defined and their types. Click the names of any file stores with a type of FileStore. The resulting window displays the location of the directory.

Note:

If the Persistent Store type is listed as JDBCStore, you do not need to back it up separately, because it is backed up automatically with the database.

You can back up these files using the tar command to put them in a single file, and then storing the .tar file in a safe location. Ensure you back up the directories for all FileStore persistent stores if there are more than one.

OSM Attachment Directory

The default location for the attachments directory for OSM is in a subdirectory of the domain directory backed up in the previous section. However it is possible to configure this directory in another location. You can view the location of this directory in the WebLogic Server Administration Console. For information about accessing the WebLogic Console, see "Accessing the WebLogic Server Administration Console."

From the Home window of the WebLogic Console, Click FileT3 in the right pane under Services. The resulting window displays a list of the File (T3) Services that have been defined and their paths. If the path is not a complete path (for example, if it does not start with "/" on a UNIX system), the directory is located in the indicated location inside the domain directory.

You can back up these files using the tar command to put them in a single file, and then storing the .tar file in a safe location.

External Deployments

Any objects that are deployed into WebLogic using the OSM deployment tools are located in a subdirectory of the domain directory. If any objects have been deployed using other methods from a location outside the domain directory, these locations must be backed up as well.

You can use the WebLogic console to see if a particular object has been deployed from a directory outside the domain directory. For information about accessing the WebLogic Console, see "Accessing the WebLogic Server Administration Console."

From the Home window of the WebLogic Console, Click Deployments in the right pane under Your Deployed Resources. The resulting window displays a list of the deployments in your domain. Click on the name of any deployment to see the path to the source file.

You can back up these files by copying them to a safe location.

Remote Managed Servers (Clustered Server Only)

If you are working in a clustered WebLogic environment, you must also back up the directories for any remote managed servers.

You can back up these files using the tar command to put them in a single file, and then storing the .tar file in a safe location.

Restoring the WebLogic Server Configuration

This section relates to restoring WebLogic Server files for OSM.

Restoring the WebLogic Server Files

To restore the WebLogic Server files for the following components, remove the contents of the directories you backed up, and extract the contents of the backed-up tar files into those directories.

  • WebLogic domain directory

  • WebLogic persistent store

  • OSM attachments directory

  • Remote managed server directories (clustered server only)

For the external deployments which you have backed up, copy the backed up files to the directory in which they were originally located, and replacing the existing files with the same names.

Setting OSM to Resume Processing of JMS Messages

Once you have restarted the WebLogic servers from the restored files and determined that the restoration has been successful, configure OSM to resume processing of JMS messages using the WebLogic Server Administration Console. By default, OSM has one JMS server, called oms_jms_server. If you have custom JMS servers defined, you should perform this procedure for each of them as well.

  1. Access the WebLogic Server Administration console Home window. See "Accessing the WebLogic Server Administration Console."

  2. In the Messaging subsection of the Services section, click JMS Servers.

    The Summary of JMS Servers window is displayed.

  3. Click on the name of the appropriate JMS server in the table.

  4. The settings for your JMS server are displayed with the Configuration tab and the General sub-tab selected. At the bottom of the window, expand the Advanced heading to display more options.

  5. Deselect the following options:

    • Insertion Paused At Startup

    • Production Paused At Startup

    • Consumption Paused At Startup

  6. Click Save.

  7. Exit the WebLogic console.