Backing up system components

Backing up the IBM WebSphere InterChange Server system is among the more critical tasks for IBM WebSphere system administrators. Standardized backup procedures allow for easier environment restoration in the event of system failures. Backing up the IBM WebSphere InterChange Server system is also important because hardware or software failures may leave data in an inconsistent state between IBM WebSphere InterChange Server and the integrated applications.

Note:
Backed up repositories from previous versions should not be restored in the current version, since there is no guarantee of CWBF format enforcement in Bi-Directional (BiDi) enabled releases. This could be due to several reasons not related to the new release and the subsequent BiDi support, for example, non-BiDi enabled adapters or the custom codes associated with system components not in CWBF. For more information about BiDi, refer to the Technical Introduction to IBM WebSphere InterChange Server and the Business Object Development Guide.

This section covers the following topics:

"Backup schedule planning"

"Component backups"

Backup schedule planning

It is important for you to plan and carry out procedures for regularly scheduled backups of the IBM WebSphere InterChange Server system. The more frequently you perform backups, the less data you need to recover in the event of data loss.

Within the IBM WebSphere InterChange Server system, two types of data should be backed up: static data and dynamic data.

Plan your backup schedule at times when your systems environment is in a quiescent state or in a state with a minimal amount of event processing. IBM WebSphere InterChange Server is in a quiescent state when all of the following conditions exist:

Component backups

Different components of the IBM WebSphere InterChange Server environment require different backup procedures. The following topics are described in this section:

"Relationship table backups"

"Repository backups"

"System installation file backups"

"Collaboration class file backups"

"Archive table backups"

Attention:
When backing up IBM WebSphere InterChange Server Components, do not back up the WebSphere MQ queues. WebSphere MQ queues represent in-progress transactions in the system, which are dynamic and therefore should never be backed up. Instead, IBM WebSphere InterChange Server recommends that the WebSphere MQ queues be mirrored in a fail-over scenario.

Relationship table backups

Relationship tables are backed up using the standard backup utility for the database where these tables reside. Schedule this backup to coincide with the corresponding application backups. If you back up applications at different times, back up the relationship tables each time you back up an application. There are often static relationship tables within the relationship database. Although this data is static, it is recommended that you back up all relationship tables together. Make sure the IBM WebSphere InterChange Server system is in a quiescent state when backing up the relationship tables. For more information on bringing the system to a quiescent state, see "Steps for shutting down InterChange Server".

It is recommended that the relationship database log be mirrored to assist in recovery. If hardware/software cost is not a consideration, the relationship run time data can also be mirrored.

The set of relationship tables for one relationship are closely associated, so you should back up all of these at the same time.

Back up relationship information using the standard backup utility from the DBMS (Database Management System) where these tables reside.

Note:
To avoid data loss, run relationship backups at the same time you run backups for the applications that the tables reflect.

Repository backups

Repository tables are backed up using the repos_copy command. For more information on this command, see "Using repos_copy". Back up the repository whenever it is modified and before and after performing a reinstallation or an IBM WebSphere InterChange Server software upgrade. The IBM WebSphere InterChange Server system does not need to be in a quiescent state when backing up the repository.

The method to use for backing up the repository depends on whether your database is partitioned or unpartitioned.

Partitioned database backups

If your databases are partitioned, you can use the standard database backup utility from the DBMS to back up the Repository, Event Management, and Transaction databases.

Note:
It is recommended that the Repository, Event Management, and Transaction database logs be mirrored to assist in recovery.

Unpartitioned (single) database backups

If your IBM WebSphere InterChange Server databases are not partitioned, meaning they are contained in a single database, they should not be part of your normal database backup routine. The IBM WebSphere InterChange Server databases contain transient data whose recovery can cause inconsistencies in the system. Instead, back up the objects in the IBM WebSphere InterChange Server repository by using the repos_copy utility.

System installation file backups

The system installation files should be backed up at the following stages:

Collaboration class file backups

Back up collaboration class files with your other non-IBM WebSphere InterChange Server system files. Coordinate the repository backup with the collaboration class file backups.

Archive table backups

Some applications have archive tables. Back up archive tables using the standard database utility for the database in which they reside. The archive tables are part of the IBM WebSphere InterChange Server system, but typically reside in the application's database. Back up the archive tables on a regular basis. Data in the archive table represents all of the events that have passed from the application to the IBM WebSphere InterChange Server system. These events can be used to "resynchronize" the application and the IBM WebSphere InterChange Server cross-reference tables.

Copyright IBM Corp. 1997, 2004