Roll Back Strategies and Tips

Authors: MikeDelargy
Build basis: CLM Versions 3.x, 4.x, 5.x, and 6.x

Many organizations require a rollback strategy in the event that an upgrade / modification / rename encounters an unforeseen event that requires the change to be cancelled and the system needs to quickly be reverted to the state it was in before the change was attempted.

What needs to be considered

For the CLM applications, this rollback may include restoring:

1) Configuration files
2) Databases
3) Index files
4) WebSphere Application Server configurations

Preparing for change

Best practices dictate that prior to making any change in your CLM configuration whether it be a CLM Upgrade, a Server Rename, or any other change that could potentially lead to implementing recovery then care should be taken to ensure you have backups of critical components in your system.

For more detailed information on backing up your CLM environment, please see the Jazz article on Backing up the Rational solution for Collaborative Lifecycle Management (CLM)

Configuration Files:

Each of your CLM applications has configuration files associated with it.
These can be found in your {CLM Installation Directory (JazzTeamServer directory)}/server/conf
The complete environment depends on the deployment architecture being used.

Databases:

You or your D.B.A. should backup each of your application databases. The strategies for making backups depends on the vendor. For Derby, it can be as simple as making a copy of your database or creating a quick zip file. Databases that need to be backed up:

• JTS
• CCM
• RQM
• RDNG (only in Version 5.0 and later as earlier versions shared a database with JTS)
• DW

Index files

The Default location for the index files is relative to the folder where the teamserver.properties file is located. However, some deployments have moved them to a different location or to a network share. The exact location of the files can be found in the teamserver.properties file of each application. (Starting in the 5.0 release, RM has its own teamserver.properties file; rm no longer shares a database / indices with JTS)

There are different ways to backup your Index files. More information can be found Query and Search indices management in the Rational solution for Collaborative Lifecycle Management Part 2: Indices storage and management: Backup, recovery and recreation

WebSphere Application Server configurations:

There are a number of options to backup / restore your WebSphere profile.

Option 1:
One such method is to use WebSphere tools to create the back up or implement the restore. More information can be found at Backup and Recovery in IBM WebSphere environments

Option 2:
Another option for you, that is particularly useful when you are doing an upgrade, is to create a new profile/jvm prior to doing the upgrade.
Creating a second jvm allows you to expedite the actual upgrade and / or recovery because no change to the existing environment is actually made. You can create the new profile and configure it completely with the new / upgraded installation location / files.

When you create the new profile, WebShere will automatically assign new ports to be used for this profile. These can be easily changed to match your current environment just prior to implementing the upgrade. When it comes time to do the actual upgrade, you can stop the current (old) profile and start the new profile being sure the ports match the existing / old deployment. In the event you need to revert/rollback the upgrade, you simply shut down the new jvm and start the old one.

More information on utilizing a second profile /jvm to expedite recovery can be found here:

Expedite your WAS configuration to minimize down time for a CLM upgrade

Related topics: Deployment web home, Deployment web home

External links:

• IBM

Additional contributors: TWikiUser, TWikiUser