Backing up system components

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

This section covers the following topics:

"Backup schedule planning"

"Component backups"

Backup schedule planning

Plan and carry out procedures for regularly scheduled backups of the InterChange Server Express system. The more frequently you perform backups, the less data you need to recover in the event of data loss. When planning a backup schedule, keep in mind the information in this section.

Within the InterChange Server Express 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. InterChange Server Express is in a quiescent state when all of the following conditions exist:

Component backups

Different components of the InterChange Server Express 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 Express 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, InterChange Server Express 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 InterChange Server Express system is in a quiescent state when backing up the relationship tables. For more information on bringing the system to a quiescent state, see "Shutting down InterChange Server Express".

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

The set of relationship tables for one relationship are closely associated, so 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 InterChange Server Express software upgrade. The InterChange Server Express 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 you mirror the Repository, Event Management, and Transaction database logs to assist in recovery.

Unpartitioned (single) database backups

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

System installation file backups

Back up the system installation files at the following stages:

Collaboration class file backups

Back up collaboration class files with your other non-InterChange Server Express 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 InterChange Server Express 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 InterChange Server Express system. These events can be used to "resynchronize" the application and the InterChange Server Express cross-reference tables. For more information, see "Maintaining event archives".

Copyright IBM Corp. 2004