Select the options that apply to your environment to generate a customized guide to back up or restore your installed applications.
To back up or restore the Rational solution for Collaborative Lifecycle Management (CLM) software packages, follow these steps:
To prepare for unexpected events, consider that you might have to recover from the following scenarios:
The loss of either a database server node or an application server node requires a substitute or replacement. In the worst case, you might have to reinstall or reconfigure a replacement server. To minimize downtime, you can provide replacement systems that are already configured to take over, such as a high availability configuration for the application server node. For more information about high availability and disaster recovery, see Approaches to implementing high availability and disaster recovery for Jazz environments on the Deployment wiki.
To restore a complete deployment in any scenario, you must have the following data available:
A backup procedure is worthless if data is missing, inconsistent, unreadable, or not working for other reasons. To ensure that your backup and restore procedure works, test it on an isolated test infrastructure on a regular basis.
In a distributed environment, ensure that the clocks on all servers are synchronized by using the Network Time Protocol (NTP). For more information about NTP, visit ntp.org.
During the installation of the CLM applications, you select the installation directory. For example, if you installed by using IBM Installation Manager on Linux, the default server installation directory is /opt/IBM/JazzTeamServer. If you installed on a Windows system, the default server installation directory is C:\Program Files\IBM\JazzTeamServer.
In a distributed topology where Jazz Team Server is installed on a separate server than other CLM applications, you must start up Jazz Team Server first and shut down Jazz Team Server last. Other applications can be shut down or started in any order.
For a full directory backup, you can back up the server_install_dir/server/conf directory, where server_install_dir represents the location where CLM applications are installed. This directory includes all data necessary to restore the CLM application configuration. However, it also includes additional data that you do not need. If you install all applications on one server in a departmental topology, all applications configuration files are included in this directory.
The configuration folder also contains program code which is not useful for backups. To be more selective, you can back up only the most important files and folders. Specifically, you can exclude all data that is installed with the product. The following files and folders must be backed up:
Jazz Team Server
Change and Configuration Management (CCM) application
Quality Management (QM) application
Requirements Management (RM) application
Rational Engineering Lifecycle Manager (RELM) application
Rational Rhapsody Design Manager (DM) application
Global Configuration Management (GCM) application
Link Index Provider (LDX) application
For tools to backup and restore, see Backing up and restoring Lifecycle Query Engine and Link Index Provider (LDX).
Report Builder (JRS) application
Data Collection Component (DCC) application
Lifecycle Query Engine (LQE) application
For tools to backup and restore, see Backing up and restoring Lifecycle Query Engine and Link Index Provider (LDX).
To restore the application server configuration data for all application servers, you must first back it up. How to back up the data and which data to include in the backup depends on the application server. Because only administrative tasks cause changes to the application server configuration, incrementally backing up the data once a day should suffice.
Starting in version 6.0.1, WebSphere Liberty is provided as the default application server.
The application server configuration data is stored in these folders:
Note: To create the clm folder, you must start the server at least once.
Some files in these folders are modified during the setup process and during operation, and you should include them in the backup procedure.
The following files are typically modified during the setup process and should be backed up:
If you use WebSphere Application Server, back up the profile that is used to deploy the applications. You can run the backupConfig utility to back up the configuration of your node to a file. Because security is enabled for your server, run the utility with the -user and -password options with the user name and password of the server administrator. The utility is located in the profile_root/bin directory.
backupConfig backup_file -user admin_user -password admin_password
If you do not specify a backup file, a file with a unique name is generated in the profile_root/bin directory.
Note: By default, all servers that are on the node stop before the backup is made so that partially synchronized information is not saved. You must restart the server after the backup.
Before version 6.0.1, Apache Tomcat was provided as the default application server. After version 6.0.1, Apache Tomcat is not officially supported, but you can use it in your CLM deployment. If you used Apache Tomcat before version 6.0.1, the default configuration directory was server-install-dir/server/tomcat/conf. After version 6.0.1, you can install Apache Tomcat in this default directory or a location of your choice. The following examples use the default installation directory.
The following configuration files are modified during the setup process and during operation, and you should include them in the backup procedure:
If you provide a server certificate, include it in the backup. You can find information about the storage location of the used certificate in the server.xml file. The Connector element contains a keystoreFile property that contains the file location.
If you edited the application's web.xml files; for example, if you use Apache Tomcat with LDAP, include these files in the backup. The web.xml files to backup are stored in these locations:
If you are using Apache Tomcat for user authentication, also back up the user registry file:
The applications use Jazz Foundation Services (JFS) index files for various query and search operations. These files must be backed up. You can back up the JFS index files independently from the database. For more information about indexes, see these Deployment wiki articles: Query, search, and indexing technologies in CLM and Indices storage and management: backup, recovery, and recreation.
To create a consistent backup of the JFS index files that you can restore, back up the JFS index files before or during the backup of the database. The indexing service re-creates index information for database content that is not found in the index over time.
The JFS index files are located in the teamserver.properties file for each application as a value of the com.ibm.team.jfs.index.root.directory property.
By default, the location of the index files is relative to the folder where the teamserver.properties file is located. You should change this location to an absolute path.
To back up JFS index files, while the servers are running, open a command prompt and change the directory to server_install_dir/server and enter the following commands:
This command maintains the consistency of the JFS index files and does not require to stop and restart the indexer.
Some applications, such as Change and Configuration Management or Quality Management, also use a full-text index to support various search and query operations. To restore the applications consistently, you must back up the full-text index files. You cannot back up the full-text index independently from the database.
The -backupJFSIndexes repository tools command also backs up the workitemindex directory; however, the work item index is still built during work item operations. If the directory is restored from an online backup of the JFS index, it might be inconsistent if work item operations occurred during the server uptime.
For a consistent backup of the work item index files, you might need to re-create the index. If your primary concern is the consistent online backup of the work index, you should perform a complete offline backup to get a fully consistent backup of the databases and the other files.
The full-text index files are located in the teamserver.properties file for each application as a value of the com.ibm.team.fulltext.indexLocation property.
By default, the location of the full-text index files is a relative path. The location is based on the application’s relative runtime location. If your CLM application is running on WebSphere Liberty or Apache Tomcat, this location is the same as the application’s configuration directory. If your CLM application is running on WebSphere Application Server, this location is the profile path, for example, //profiles/AppSrv01/. Change the relative path to an absolute path.
You must back up all databases that the applications use. If you use a data warehouse, also set up a backup procedure for its database.
When you back up a database, ensure that the database backup is complete and consistent from a transaction perspective. A backup is consistent if it is taken offline while the database is inactive, or when it is locked for write operations. Some enterprise databases allow consistent online backups with transaction logging or vendor-specific procedures and tools.
Jazz Team Server creates elements in the registered applications. To avoid conflicts and to ensure consistency, the databases for all registered applications must be backed up to a point in time equal to or earlier than the Jazz Team Server database.
If you use an Apache Derby database, you must shut down the application server to back up the database.
To back up the databases, compress and back up the directory that the Apache Derby database uses as repository. By default, the directory is named repositoryDB, except for Link Index Provider and Lifecycle Query Engine, where the directory is named derbyDB, warehouseDB for the data warehouse, and db for Report Builder. The following directories are the default locations for the Apache Derby database
Verify the location of your setup by checking the com.ibm.team.repository.db.jdbc.location property in the teamserver.properties file of each application.
For detailed information on how to back up your database, see the documentation for the database management system that you use:
Typically, enterprise database management systems provide the following backup options:
You must also have a consistent backup of the Jazz Foundation Services (JFS) index and the full-text index files. If your primary concern is a consistent online backup of the work index, a complete offline backup is still the preferred option for a fully consistent backup of the databases and other files.
Keep a valid temporal sequence of the database states during the backup and restore process. Ensure that you restore the databases for all applications registered to a Jazz Team Server from a point in time shortly before or equal to the last transaction of the Jazz Team Server database backup. Tracking the time is especially important for online database backups, but is also important for offline backups. For offline backups, you can create a consistent backup if all servers are down at the same time. Tracking the time is important because the Jazz Team Server creates elements in the registered applications and potential database conflicts can occur if the time of the registered application is ahead of the time of the Jazz Team Server database.
When you restore the Jazz Foundation Services (JFS) index files from a backup, ensure that the time of the backup of the index files is earlier than the time of the backup of the application database. If you restore a backup of the JFS index files that is later than the backup of the application database, error messages indicate that the index is ahead of the database. In this case, you must re-create the index files. For more information, see Repository tools command to regenerate indexes.
You must also restore a backup of the full-text index files that is consistent with the databases or you must re-create the full-text index. For more information, see Repository tools command to rebuild text indexes.
A complete restore procedure performs the following sequence of activities:
To restore Lifecycle Query Engine or Link Index Provider from a backup, see Backing up and restoring Lifecycle Query Engine and Link Index Provider (LDX).