Content Manager OnDemand Backup, Recovery, and High Availability Case Study #2: International Financial Services Company

Published 01 February 2005

Authors: Wei-Dong Zhu


This document is the second of two documents in a series that present case studies for IBM DB2 Content Manager OnDemand solutions. This case study presents an international financial services company. It includes background information, the backup procedures, the high availability configuration, and a disaster recovery plan. Through this case study, you can glimpse how a real-world solution is set up and maintained. You can take what you learn from this scenario and apply it to your next OnDemand solution implementation and maintenance project.


An international financial services company has implemented an OnDemand solution to manage their electronic data. More than 50 percent of the company's users access the OnDemand system via a company Web site. The other users are internal users who access the system using the OnDemand Windows client. The database is approximately 275 GB. Approximately 1 million stored data objects reside in cache, which equates to approximately 1.3 TB of data spread across nine OnDemand managed cache file systems. Approximately 3 TB of data are stored on Tivoli Storage Manager (TSM) managed media, primarily to optical platters, but some data is also stored on Linear Tape-Open (LTO) tape drives (for example, backups). The company has configured TSM copy storage pools to have backup platters of their data in TSM. Approximately 2000 loads are performed each day. TSM stores data to seven 3995 optical jukebox libraries.

Backup, recovery, and high availability approach
The company has the following backup procedure, high availability configuration, and disaster recovery plan.

Backup procedure
A full online OnDemand database backup is performed twice each week on the Library Server at night when the system is least accessed. Incremental backups are performed all other nights. Database backups and logs are managed by TSM and stored to LTO tape drives. The TSM database is backed up at the same time as the OnDemand database. Because application groups are configured to store data to cache and a TSM defined node, the cache file systems defined in the ars.cache file are not backed up.

High availability configuration and disaster recovery plan
The company's implementation involves two independent Library Server and Object Server configurations, each with TSM. The independent systems are located at separate geographical sites, providing a standby system for disaster recovery. Both systems are active in production, and dual loading is conducted to keep the systems equivalent in content.

This company implemented a distributed Library Server and Object Server system with TSM using two active sites to address both their high availability and disaster recovery requirement. This solution involves two independent Library Server and Object Server, each with TSM. The independent systems are located at separate geographical sites providing a standby system for disaster recovery. Both systems are active in production. They use dual loading (defining multiple route destinations from the mainframe that generates their report files) to keep the systems equivalent in content. The company does not use annotations in their implementation. Thus, there is no concern with synchronization of the annotation table. Loads are verified on each system by an OnDemand administrator to ensure congruency in content.

Because this company has two independent active systems, each system effectively acts as a hot standby for each other, and the system downtime is far less likely. The switch to the healthy system, however, is not automatic and is not monitored by any high availability software. If a failure occurs at one site, the clients simply log on to the healthy site and work from the healthy site.

The following figure shows the system configuration for this case study.

System configuration

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Follow IBM Redbooks

Follow IBM Redbooks