Edit
Attach
P
rintable
r30 - 2018-02-26 - 10:54:40 -
RalphSchoon
You are here:
TWiki
>
Deployment Web
>
DeploymentInstallingUpgradingAndMigrating
>
BackupCLM
<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%"> ---+!! Backing up the Rational solution for Collaborative Lifecycle Management (CLM) %DKGRAY% Authors: [[Main.RalphSchoon][Ralph Schoon]], [[Main.TimFeeney][Tim Feeney]] <br> Build basis: Rational solution for Collaborative Lifecycle Management 2011 - Rational Team Concert, Rational Quality Manager, Rational Requirements Composer 3.0.1.1. This article is also valid for the product versions 4.x and later. Please note, in version 5.0 the database storage for the RM application changed. RM has now its own database and index files that need to be taken care of in the backup. This has been added to below.<br> <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/todo16.png" alt="todo16.png" width="16" height="16"/>This article has been preliminary updated to include new applications delivered as part of 6.0 as well as the Liberty application server replacement of Tomcat. %ENDCOLOR%</div></sticky> <!-- Page contents top of page on right hand side in box --> <sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> %TOC{title="Page contents"}% </div></sticky> <sticky><div style="margin:15px;"></sticky> After you start using the Rational solution for Collaborative Lifecycle Management (CLM), it will contain more and more important data. Therefore, it is essential to make regular backups of the data to avoid losing it. The [[https://jazz.net/help-dev/clm/][Rational solution for Collaborative Lifecycle Management Information Center]] contains information on how to [[https://jazz.net/help-dev/clm/topic/com.ibm.jazz.repository.web.admin.doc/topics/t_jfs_backup.html][back up the databases]]. To minimize down time, you can increase the reliability of the Rational solution for CLM by using hardware that provides high reliability. However, failure can still happen. Since whole development teams depend on the infrastructure, it is desirable to be able to recover it as quickly as possible. This article provides specifics about what to consider when backing up the Rational solution for CLM. ---++ Deployment topology to back up For the purposes of this article, assume that the Rational solution for CLM is deployed in a fully distributed topology. * Jazz Team Server is installed on its own server; for example, JTS_SERVER. * The Change and Configuration Management (CCM) application (Rational Team Concert) is installed on its own server: CCM_SERVER. * The Quality Management (QM) application (Rational Quality Manager) is installed in its own server: QM_SERVER. * The Requirements Management (RM) application (Rational Requirements Composer) is installed in its own server: RM_SERVER. * For simplicity, assume that the installation is new and without a migration from prior versions. The context roots are /jts, /ccm, /rm, /qm. * The databases are hosted on one or more servers. As described in [[https://jazz.net/blog/index.php/2010/08/16/building-products-from-applications/][Building products from applications]], the Rational solution for CLM is now built around a central Jazz Team Server and several applications that share this Jazz Team Server. In this topic, the following abbreviations are used: 1 Jazz Team Server is referred to as JTS. 1 The Change and Configuration Management application is referred to as the CCM application. 1 The Quality Management application is referred to as the QM application. 1 The Requirements Management application is referred to as the RM application. The assumptions above will result in a deployment topology as shown below. Each application node has an application server installed and the application is deployed on it. JTS, the CCM application, and the QM application have their own own database to store data. The RM application below Version 5.x uses JTS to store its data. Since version 5.x RM has its own database. In the example topology, the databases hosted on the database nodes are referred to as JTS_DB, which are used by JTS and the RM application; CCM_DB, which is used by the CCM application; and QM_DB, which is used by the QM application. *Note:* Since 5.0 the RM Application has its own database RM_DB that needs to be backed up. <img width="578" alt="CLMBackup1.png" src="%ATTACHURLPATH%/CLMBackup1.png" height="391" /> Additional CLM applications such as Design Manager require backup like any other Jazz application, if deployed. In case a data warehouse such as Rational Reporting for Development Intelligence or Rational Insight is set up, keep in mind that setting up a separate backup procedure for its database and configuration data is also needed. ---++ Relevant data for backup operations This section answers the question, "What could happen?" In the topology described above, you must plan for the following potential failure scenarios: 1 Loss of one or more database server nodes 1 Loss of one or more application server nodes The loss of the database server or the application server node would each require a substitute or replacement. In the worst case, this could mean reinstalling or reconfiguring a machine as a replacement. You can minimize downtime also by providing replacement systems already configured to take over as described in [[https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/t_setting_up_ha.html][setting up a basic high availability]] configuration for the application server node. In any case, it is necessary to have all required data available. The data needed to restore a complete deployment as described above consists of: 1 The [[#Backing_up_the_databases][databases]] with consistent data 1 The [[#Backing_up_the_Jazz_application][application configuration data]] created and maintained during setup and administration 1 The [[#Backing_up_the_Jazz_application][application server configuration data]] for each application server 1 The [[#Backing_up_the_JFS_index_files][JFS index]] files used by each application 1 The [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files for the CCM and QM applications 1 Any custom server extensions and applied patches ---++ Practicing your backup and restore procedure A backup procedure is worthless if data is missing, inconsistent, unreadable, or not working for other reasons. Practice and test your backup and restore procedure on an [[https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/c_upgrade_staging_env.html][isolated test infrastructure]] on a regular basis, to be sure that it works. ---++ Synchronizing server clocks For normal operations as well as for backup and restore, it is important that the clocks of your machines that run the Rational solution for CLM are closely synchronized. The applications that require the synchronization provide [[https://jazz.net/help-dev/clm/topic/com.ibm.jazz.install.doc/topics/c_cluster_prerequisites.html][setting up a connection to a NTP server]] to monitor the machine clocks in the advanced server properties. ---++ Backing up the Jazz application configuration files While installing the products, you choose install directories. 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 Windows, the default server installation directory is =C:\Program Files(X86)\IBM\JazzTeamServer=. This installation directory will be referred to as _server-install-dir_ in the following text. The image below shows a typical folder structure after installing all applications on Apache Tomcat. <img width="594" alt="CLMBackup2.png" src="%ATTACHURLPATH%/CLMBackup2.png" height="551" /> During the setup and configuration of Jazz Team Server and the other applications, several files are changed either automatically or manually. Some files that are updated during administration operations and should therefore be included in a regular backup as well. In this article, the backup of the Jazz application configuration files will be represented by the following pseudocode: =backup <i>APP</i>_CONFIG= In the pseudocode, _APP_, represents the application node that must be backed up. In the pseudocode for a specific application, _APP_ must be replaced with the acronym that represents the application, which will be JTS, CCM, QM, or RM. This pattern is kept in the article. The pseudocode below would do the backup for all applications: <verbatim>backup CCM_CONFIG backup QM_CONFIG backup RM_CONFIG backup JTS_CONFIG</verbatim> ---+++ Files to include in the Jazz application configuration files backup All the Jazz application configuration files are stored in one or more folders underneath the configuration data folder: <pre><i>server-install-dir</i>/server/conf</pre> The options for backing up the Jazz application configuration files are a [[#Full_backup][full backup]] and [[#Selective_backup][selective backup]]. ---++++ Full backup You can back up the whole folder structure underneath: <pre><i>server-install-dir</i>/server/conf</pre> for each application. This option will safely back up all data that might be necessary to restore the Jazz application configuration. On the other hand, it backs up more data than is actually needed. *Note:* By default, the index files for the [[#Backing_up_the_JFS_index_files][JFS index]] and the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] are also stored in this location. If you use a full backup for the folder, make sure that the backup of the index files is successful or change the server configuration and place the index files into a location outside of the =<i>server-install-dir</i>/server/conf= folder. See below for more information. ---++++ Selective backup The configuration folder also contains program code which is often not desired to be included in backups. To be more selective, it is possible to only include the most important files and folders into the back up. This can especially exclude all data that is installed with the product. Each application has its own [[#Configuration_folder][configuration folder]]. An application can use more than one folder. The folders must be backed up together. JTS uses the following folders for JTS and the Lifecycle Project Application (LPA): <pre><i>server-install-dir</i>/server/conf/jts <i>server-install-dir</i>/server/conf/admin</pre> The CCM application stores its data in the folder: <pre><i>server-install-dir</i>/server/conf/ccm</pre> The QM application stores its data in the folder: <pre><i>server-install-dir</i>/server/conf/qm</pre> The RM application stores its data in the folder: <pre><i>server-install-dir</i>/server/conf/rm</pre> Each application has its own configuration files as shown below: <img width="594" alt="CLMBackup3.png" src="%ATTACHURLPATH%/CLMBackup3.png" height="485" /> For each application, at least back up the following files from the configuration folder: <verbatim>teamserver.properties log4j.properties</verbatim> In general, back up all files of this format: <verbatim>*.properties</verbatim> Some applications store data in RDF format. Check for files of the following format and back them up in case there are any: <verbatim>*.rdf</verbatim> Other files created during the installation are typically not modified. If in doubt, check the modification date and time, and include files that changed after the installation finished. ---+++ Configuration folder As mentioned above, if you use this as a general advice for Jazz based solutions; for example, to back up Design Manager, or for newer versions of the tool, back up all of the relevant data in all available configuration folders in: <pre><i>server-install-dir</i>/server/conf</pre> Like JTS, Design Manager uses more than one configuration folder; in this particular case, =dm= and =vvc=. Be sure to catch all relevant data from these folders. Do not add any folders to the <pre><i>server-install-dir</i>/server/conf</pre> folder. Especially do not create copies of the existing folders and store them in this folder. This will cause issues with your application; for example, if you run setup again in an upgrade scenario. ---++++ Backing up custom server extensions A [[#Full_backup][full backup]] contains all the required data. If you deployed any custom server extensions, and do a [[#Selective_backup][selective backup]], either back up the corresponding files or at least have the files available for rapid redeployment. The files that are needed to deploy custom server extensions are typically stored in the folder: <pre><i>server-install-dir</i>/server/conf/<i>APP</i>/provision_profiles</pre> The files that must be backed up are the provision profile =.ini= file and the corresponding update =site= folder. ---++++ Backing up the deployed patches A [[#Full_backup][full backup]] contains all the required data. If you deployed any patches, and do a [[#Selective_backup][selective backup]], either back up the corresponding files or at least have the files available for rapid redeployment. See the patch description for the files that need to be included in a backup. ---++ Backing up the application server configuration Back up the application server configuration data for all application servers, in order to be able to restore it later. How to back up this data and which data needs to be included in the backup depends on the application server in use. The application server configuration changes only due to administrative tasks. It should be sufficient to use an incremental backup once a day. Backing up the application server configuration files for the _APP_ application will be be represented below by the following pseudocode: <pre>backup <i>APP</i>_APPSERVER_CONFIG</pre> The following pseudocode shows the steps to back up all application server configuration files for all nodes: <verbatim>backup CCM_APPSERVER_CONFIG backup QM_APPSERVER_CONFIG backup RM_APPSERVER_CONFIG backup JTS_APPSERVER_CONFIG</verbatim> ---+++ Tomcat When installing on Tomcat, the application server configuration data is in <pre><i>server-install-dir</i>/server/tomcat/conf/</pre>. Some of these files are modified during the setup process and during operation and should be included in the backup procedure. The following files are typically modified during the setup and should be backed up: <pre><i>server-install-dir</i>/server/tomcat/conf/server.xml <i>server-install-dir</i>/server/tomcat/conf/web.xml</pre> If you provide a server certificate, include it in your 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 instance, when using Tomcat with LDAP, include these files in your backup. The =web.xml= files to backup are stored in this location: <pre><i>server-install-dir</i>/server/tomcat/webapps/<i>APP</i>/WEB-INF/web.xml</pre> For example: <pre><i>server-install-dir</i>/server/tomcat/webapps/jts/WEB-INF/web.xml <i>server-install-dir</i>/server/tomcat/webapps/ccm/WEB-INF/web.xml</pre> If you are using Tomcat for user authorization, also back up the user registry file: <pre><i>server-install-dir</i>/server/tomcat/conf/tomcat-users.xml</pre> ---+++ !WebSphere Application Server When using !WebSphere Application Server, back up the profile used to deploy the application. See the [[http://www.ibm.com/support/knowledgecenter/SSEQTP/mapfiles/product_welcome_was.html][WebSphere Application Server Knowledge Center]] for your version of the !WebSphere Application Server for more information. One option is to use the [[http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.installation.base.doc/ae/rxml_manageprofiles.html][manageprofiles]] command. ---+++ !WebSphere Liberty As of 6.0, !WebSphere Liberty replaced Tomcat as the application server packaged out of the box with CLM. When installing on !WebSphere Liberty, the application server configuration data is in these folders <pre><i>server-install-dir</i>/server/liberty/servers/clm/ <i>server-install-dir</i>/server/liberty/servers/clm/conf/ </pre> Some of the files underneath these folders are modified during the setup process and during operation and should be included in the backup procedure. The following files are typically modified during the setup and should be backed up: <pre><i>server-install-dir</i>/server/liberty/servers/clm/server.xml <i>server-install-dir</i>/server/liberty/servers/clm/conf/ldapUserRegistry.xml <i>server-install-dir</i>/server/liberty/servers/clm/conf/application.xml</pre> If you are using the built in local user authorization, also back up the user registry file: <pre><i>server-install-dir</i>/server/liberty/servers/clm/conf/basicUserRegistry.xml</pre> If you provide a server certificate, include it in your backup. You can find information about the storage location of the used certificate in the =server.xml= file. The element keyStore contains a location property that contains the file location. If this shows a file or a relative path the default location for the file is in <pre><i>server-install-dir</i>/server/liberty/servers/clm/conf/resources/security/</pre> ---++ Backing up the databases It is necessary to backup all databases used by the applications. The RM application since version 5.0 has its own database. In versions before 5.0 RM used the JTS database to store its data and therefore did not have a separate database to back up. If you use a data warehouse, also set up a backup procedure for its database. Backing up the application database for the _APP_ application will be be represented below by the following pseudocode: <pre>backup <i>APP</i>_DB</pre> The pseudocode below represents all steps and the sequence needed to back up for all databases for all applications: <verbatim>backup CCM_DB backup QM_DB backup RM_DB backup JTS_DB</verbatim> ---+++ Ensuring a consistent database backup When backing up a database, make sure that the database backup is complete and consistent from a transaction perspective. A backup is consistent if 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. There are several databases to back up and the applications interact. JTS creates elements in the registered applications. The JTS cannot create an element if it is already there because the database of the registered application is ahead of the JTS. To avoid conflicts and ensure consistency, the databases for all registered applications must be backed up to a point in time equal or earlier than the JTS database. In the example topology, this holds for the CCM and the QM databases. This has an [[https://jazz.net/library/article/795#Temporal_Database_Consistency_During][impact on the database restore operation]], especially for online backups. ---+++ Derby databases If a Derby database is used, the application server must be shut down to perform the database backup. To back up the databases, compress and back up the directory and its content used by Derby as repository. By default, the directory is called repositoryDB. The default location for this directory is the =derby= folder in the configuration folder of each application: <pre><i>server-install-dir</i>/server/conf/ccm/derby/repositoryDB <i>server-install-dir</i>/server/conf/qm/derby/repositoryDB <i>server-install-dir</i>/server/conf/rm/derby/repositoryDB <i>server-install-dir</i>/server/conf/jts/derby/repositoryDB</pre> 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. ---+++ Enterprise databases See the system requirements on the *Getting Started* tab of the individual product download page for the supported database management systems. Also see the [[https://jazz.net/help-dev/clm/][information center]] and the [[https://jazz.net/library/][library]] for information about how to backup other databases. For detailed information on how to backup your database, see the documentation for the database management system you are using. In general, the options provided by enterprise database management systems are: ---++++ Offline backup It is always possible to do an offline backup. Before you back up the database, stop the application server so that no user interaction occurs during the backup. This ensures the backup is consistent. You can also consistently back up all other data related to the server while it is shut down. ---++++ Online backup Some database management systems, such as DB2, support online backup. This can be used to continuously back up the databases. For more details about DB2 online backup, see [[https://jazz.net/wiki/bin/view/Deployment/OnlineBackupCLMDB2][this article]]. If using online backup, you still want to back up the [[#Backing_up_the_Jazz_application][Jazz application configuration files]] as well as the [[#Backing_up_the_application_serve][application server configuration files]]. You will most likely not be able to back up and restore the configuration files consistently with the online backup. However, these files are only changed when configuring the application server or administrating the capabilities of the server configuration. Back up these files after performing any of these tasks. Otherwise you must redo changes that did not make it into the last backup. You also must have a consistent backup of the [[#Backing_up_the_JFS_index_files][JFS index]] and the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files. Since version 4.0.5 the [[#Backing_up_the_JFS_index_files][JFS index]] provides a capability to back up the work item index along withe the [[#Backing_up_the_JFS_index_files][JFS index]]. See [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] for considerations, especially for online backup. For backing up DNG indices, see [[https://jazz.net/wiki/bin/view/Deployment/DngJfsIndexBackup][Backup and restoration of Jazz Foundation Service index files for Rational DOORS Next Generation]] If a consistent online backup of the work index is the primary concern, A complete offline backup is still the preferred option to get a fully consistent backup of the databases and the other files. ---++ Backing up the JFS index files The applications use [[#Backing_up_the_JFS_index_files][JFS index]] files for various query and search operations. These files must be backed up. The [[#Backing_up_the_JFS_index_files][JFS index]] files can be backed up independent from the database. See [[DeploymentJazzIndicesTechnology][Query, Search and indexing technologies in CLM]] and [[DeploymentJazzIndicesStorage][Indices storage and management: Backup, recovery and recreation]] for more information on the indexes. ---+++ Ensuring a consistent backup of database and index files To create a consistent backup of the [[#Backing_up_the_JFS_index_files][JFS index]] files and restore from it, back up the [[#Backing_up_the_JFS_index_files][JFS index]] files before or during the backup of the database. The indexing service will re-create index information for database content not found in the index over time. Backing up the indexes will be be represented below by the following pseudocode: <pre>backup <i>APP</i>_JFSINDEXES</pre> In the pseudocode above, _APP_ represents the application node that must backed up. The following code backs up all nodes: <verbatim>backup CCM_JFSINDEXES backup QM_JFSINDEXES backup RM_JFSINDEXES backup JTS_JFSINDEXES</verbatim> *Note:* Up to version 5.0 the RM application did not have its own [[#Backing_up_the_JFS_index_files][JFS index]] files and these indexes where maintained by JTS. ---+++ JFS index file locations The location of the [[#Backing_up_the_JFS_index_files][JFS index]] files can be found in the =teamserver.properties= file for each application as value of the following properties: <verbatim>com.ibm.team.jfs.index.root.directory</verbatim> The location of the index files is, by default, relative to the folder where the =teamserver.properties= file is located. This should be changed to an absolute path. ---+++ Backup of the JFS index files in version 3.x products To avoid a corrupted backup of the [[#Backing_up_the_JFS_index_files][JFS index]] files in *3.x products*, stop the indexing service during the backup period or shut down the server. Stopping the indexing services can increase the server up time when running backups. It is necessary to resume the indexing services after the backup has been performed. The indexing service can be stopped by using the -suspendIndexer repotools command: <pre>repotools-<i>APP</i> -suspendIndexer <i>APP</i>_PARAMETER</pre> The indexing service can be restarted by using the -resumeIndexer repotools command: <pre>repotools-<i>APP</i> -resumeIndexer <i>APP</i>_PARAMETER</pre> In the above pseudocode, repotools-<i>APP</i> needs to be replaced by the repotools command for the application that is backed up. For example, =repotools-ccm= for the CCM application. In addition, <i>APP</i>_PARAMETER represents the required parameters for the command, such as the repository URL of the server and the login information for an administrative user. For the syntax and options, see the repotools command help. As an example for JTS, the command looks like this: <verbatim>repotools-jts -suspendIndexer repositoryURL=https://JTS_SERVER:JTS_SERVER_PORT/jts adminUserID=****** adminPassword=******</verbatim> For simplicity, this article uses the pseudocode below to describe the detailed [[#Backing_up_the_JFS_index_files][JFS index]] backup for the _APP_ node: <pre>suspendIndexing <i>APP</i>_SERVER backup <i>APP</i>_JFSINDEXES resumeIndexing <i>APP</i>_SERVER</pre> The following code shows the detailed pseudocode for all nodes: <verbatim>suspendIndexing CCM_SERVER backup CCM_JFSINDEXES resumeIndexing CCM_SERVER suspendIndexing QM_SERVER backup QM_JFSINDEXES resumeIndexing QM_SERVER suspendIndexing RM_SERVER backup RM_JFSINDEXES resumeIndexing RM_SERVER suspendIndexing JTS_SERVER backup JTS_JFSINDEXES resumeIndexing JTS_SERVER</verbatim> ---+++ Backing up the JFS index files in 4.0 - 4.0.4 In version 4.0, a new repotools command was introduced that does the backup of the [[#Backing_up_the_JFS_index_files][JFS index]] files for an application, with the server online. Backing up the [[#Backing_up_the_JFS_index_files][JFS index]] in version 4.0. and later is described by using the same pseudocode: <pre>backup <i>APP</i>_JFSINDEXES</pre> Where repotools-<i>APP</i> must be replaced by the repotools command for the application that is backed up. For example, =repotools-ccm= for the CCM application. In addition, <i>APP</i>_PARAMETER represents the required parameters for the command, such as the repository URL of the server and the login information for an administrative user. For the syntax and options, see the repotools command help. As an example for JTS, the command looks like this: <verbatim>repotools-jts -backupJFSIndexes repositoryURL=https://JTS_SERVER:JTS_SERVER_PORT/jts adminUserID=****** adminPassword=****** toFile=FILELOCATION_AND_NAME</verbatim> Using this command maintains the consistency of the [[#Backing_up_the_JFS_index_files][JFS index]] files and does not require to stop and restart the indexer. *Note:* In versions before 4.0.5 the defect [[https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=245648][Defect 245648]] prevents from suspending indexing the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]]. In these versions it is necessary to do a consistent backup of these indexes, while the server is running. ---+++ Backing up the JFS index files in 4.0.5 and later Since version 4.0.5 the [[#Backing_up_the_JFS_index_files][JFS index]] provides a capability to back up the work item index along with the [[#Backing_up_the_JFS_index_files][JFS index]]. See [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] for considerations, especially for online backup. ---++ Backing up the Fulltext index files Some applications, such as CCM and QM, also use a [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] to support various search and query operations. You must back up the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files to be able to restore the applications consistently. The [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] cannot be backed up independent of the database. Backing up the indexes is represented by the following pseudocode: <pre>backup <i>APP</i>_FULLTEXTINDEX</pre> In the pseudocode above, _APP_ represents the application node that needs to be backed up. The code below backs up all nodes. JTS does not have a [[#Backing_up_the_Fulltext_index_fi][Fulltext index]]: <verbatim>backup CCM_FULLTEXTINDEX backup QM_FULLTEXTINDEX</verbatim> ---+++ Ensuring a consistent backup of database and Fulltext index Beginning with version 4.0.5 the work item index backup is now included in the back up of the [[#Backing_up_the_JFS_index_files][JFS index]]. However, the work item index is still built up during work item operations. If restored from an online backup of the [[#Backing_up_the_JFS_index_files][JFS index]], it does not index operations that are not included in the backup. So other than the rest of the [[#Backing_up_the_JFS_index_files][JFS index]] files, the work item index does not catch up with later changes and will remain inconsistent with later work item operations. %RED% Note as of 5.0.1, the fulltext work item index does catch up with the database similarly to how the JFS indices catching up. %ENDCOLOR% To get a consistent backup of the work item index files a recreation of the index might still be necessary. If a consistent online backup of the work index is the primary concern, a complete offline backup should then be performed in order to get a fully consistent backup of the databases and the other files. ---+++ Fulltext index file locations The location of the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files can be found in the =teamserver.properties= file for each application as value of the following properties: <verbatim>com.ibm.team.fulltext.indexLocation</verbatim> The location of the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files is, by default a relative path. It will be based on the application relative runtime location. If your CLM application is running on Tomcat this will be the same as the application configuration directory; if your CLM application is running on WebSphere Application Server, this will be the profile path, for example: /<WAS_ROOT>/profiles/AppSrv01/ This should be changed to an absolute path. ---++ Other Considerations ---+++ Export the reports from Report Service You can export the reports from the report service and also import them in a different system. This is especially interesting when using backup and restore as a means to create test systems. ---++ Backup scenarios With all relevant backup operations described above, it is now possible to look at different scenarios and provide the sequence of backup operations. ---+++ Offline backup ---++++ Shutting down and starting up CLM If you shut down a CLM environment that uses multiple distributed servers, make sure to * Start up JTS first * Shutdown JTS last You can start up and shut down the other applications in any order, if you make sure the JTS is handled as described above. ---++++ Offline backup sequence for a single application on a single server A complete offline backup procedure for one application on a single server machine would perform the following sequence of activities: <verbatim>shutdown ${APP}_SERVER backup ${APP}_CONFIG backup ${APP}_SERVER_CONFIG backup ${APP}_JFSINDEXES backup ${APP}_FULLTEXTINDEX backup ${APP}_DB startup ${APP}_SERVER</verbatim> Offline backup is the easiest, safest option and easiest to implement option for co-located and distributed topologies. *Note:* Since version 5.0 The RM application does require backing up of the index files or the database. In versions before this was done with the JTS backup ---++++ Offline backup sequence for the Rational solution for CLM A full offline backup for all nodes could look like this example: <verbatim>shutdown CCM_SERVER shutdown QM_SERVER shutdown RM_SERVER shutdown JTS_SERVER backup CCM_CONFIG backup QM_CONFIG backup RM_CONFIG backup JTS_CONFIG backup CCM_SERVER_CONFIG backup QM_SERVER_CONFIG backup RM_SERVER_CONFIG backup JTS_SERVER_CONFIG backup CCM_JFSINDEXES backup QM_JFSINDEXES backup RM_JFSINDEXES backup JTS_JFSINDEXES backup CCM_FULLTEXTINDEX backup QM_FULLTEXTINDEX backup CCM_DB backup QM_DB backup RM_DB backup JTS_DB startup JTS-server startup CCM-server startup QM-server startup RM-server </verbatim> In the scenario above the backup of the [[#Backing_up_the_JFS_index_files][JFS index]] files assumes suspending the indexer in 3.x and using the backupJFSIndexes command in 4.x. During startup in a distributed environment, start JTS first, then start the other servers. ---++++ Offline backup with reduced server downtime The example above has the longest downtime for offline backup scenarios. There are several options to reduce downtime, dependent on the systems and infrastructure in use. These include: * Backing up the application configuration files while the server is up * Backing up the application server configuration while the server is up * Stopping indexing for backing up the [[#Backing_up_the_JFS_index_files][JFS index]] and keeping the server operational during the backup * Isolating the server from users while backing up the database * Online backup of the database The following example only takes the server offline to backup the databases and the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files: <verbatim>backup CCM_CONFIG backup QM_CONFIG backup RM_CONFIG backup JTS_CONFIG backup CCM_SERVER_CONFIG backup QM_SERVER_CONFIG backup RM_SERVER_CONFIG backup JTS_SERVER_CONFIG backup CCM_JFSINDEXES backup QM_JFSINDEXES backup RM_JFSINDEXES backup JTS_JFSINDEXES shutdown CCM-server shutdown QM-server shutdown RM-server shutdown JTS-server backup CCM_FULLTEXTINDEX backup QM_FULLTEXTINDEX backup CCM_DB backup QM_DB backup RM_DB backup JTS_DB startup JTS-server startup CCM-server startup QM-server startup RM-server </verbatim> ---+++ Online backup As of 5.0.1, a continuous online backup is possible which means both the [[#Backing_up_the_JFS_index_files][JFS index]] and [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files can be backed up online. However, for versions prior to 5.0.1, it is necessary to take the server offline at least to back up the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]]. In that case, to restore from an online backup without a consistent backup of the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]], you must re-create the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files from the restored databases. ---++ Restoring from a backup Replace backup by restore in the pseudocode to get a restore strategy. ---+++ Temporal database consistency during a restore Keep a valid temporal sequence of the database states during backup and restore. Make sure to restore the databases for all applications registered to a JTS; for example, the CCM and the QM database, from a point in time shortly before or equal to the JTS database backup last transaction. This is especially important for using online backup for the database, but also holds for offline backup. In offline backups, you can create a consistent backup if all servers are down at the same time. This requirement is due to the JTS creating elements in the registered applications and potential conflicts in case the database of the registered application is ahead of the JTS database. When restoring the [[#Backing_up_the_JFS_index_files][JFS index]] files from a backup, make sure that the time of the backup of the index files is from before the application's database backup. If you restore a backup of the [[#Backing_up_the_JFS_index_files][JFS index]] files that is more recent than the backup of the database of that application, error messages will indicate that the index is ahead of the database. In this case, you must re-create the index files. You also must restore a backup of the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files that is consistent with the databases or you must re-create the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]]. A complete restore procedure will perform the following sequence of activities: <verbatim>restore CCM_CONFIG restore QM_CONFIG restore RM_CONFIG restore JTS_CONFIG restore CCM_SERVER_CONFIG restore QM_SERVER_CONFIG restore RM_SERVER_CONFIG restore JTS_SERVER_CONFIG restore CCM_JFSINDEXES restore QM_JFSINDEXES restore RM_JFSINDEXES restore JTS_JFSINDEXES restore CCM_FULLTEXTINDEX restore QM_FULLTEXTINDEX restore CCM_DB restore QM_DB restore RM_DB restore JTS_DB</verbatim> ---+++ Complex scenarios With CLM 2011, you can install more than one CCM and QM application on different servers and run them against a common JTS. In that case, you must add these additional servers to the backup and perform all backup steps for each individual server. It is necessary to keep the temporal consistency for the JTS and all the applications registered to it. If you use more than one JTS, there is no requirement to keep the temporal consistency between the different groups of JTS and its registered applications. ---+++ Summary This article described the data and steps required to back up a deployment of the Rational solution for CLM. The article provides several options for backing up and also provides information about how to back up more complex Jazz deployments. ---++ Appendix ---+++ Backing up applications that were upgraded from a release of version 2 In the case of an installation that was upgraded to a version of the 3.0 release, the upgraded applications use the =/jazz= path instead of =/ccm= or =/qm=. Therefore, all occurrences of these strings in this article must be replaced with =/jazz=. ---+++ Re-creating the index files You can re-create the index files from a restored database backup. Be aware that re-creation of the index files is an expensive operation and must performed with the server shut down. ---++++ Recreating the Fulltext index You can re-create the [[#Backing_up_the_Fulltext_index_fi][Fulltext index]] files by using this command: <pre>repotools-<i>APP</i> -rebuildTextIndices</pre> ---++++ Re-creating the JFS index You can re-create the [[#Backing_up_the_JFS_index_files][JFS index]] files by using this command: <pre>repotools-<i>APP</i> -reindex all</pre> ---+++ Oracle backups See [[https://www-304.ibm.com/support/docview.wss?uid=swg21454793][this technote]] about Oracle backup, especially if you intend to use datapump. There is a known issue with Oracle databases that are restored from a backup in 3.0.x. For details, see [[https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=180771][work item 180771]]. If this issue occurs, Support can provide a solution. ---+++ Backing up products that were upgraded from a release of version 2 In the case of an installation that was upgraded from a release of version 2, the context root will be =jazz= instead of =ccm= or =qm=. In these cases, all occurrences of the context root in the URLs and paths above must be replaced with =jazz=. ---+++++!! Related topics: [[DisasterRecovery][Disaster Recovery]] ---+++++!! External links: * [[OnlineBackupCLMDB2][Transitioning to online backup of CLM databases using IBM DB2]] * [[DeploymentJazzIndicesTechnology][Query, Search and indexing technologies in CLM]] * [[DeploymentJazzIndicesStorage][Indices storage and management: Backup, recovery and recreation]] ---+++++!! Additional contributors: Main.StevenBeard <sticky></div></sticky>
Edit
|
Attach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
:
r32
<
r31
<
r30
<
r29
<
r28
|
More topic actions...
Deployment
Deployment web
Planning and design
Installing and upgrading
Migrating and evolving
Integrating
Administering
Monitoring
Troubleshooting
Community information and contribution guidelines
Create new topic
Topic list
Search
Advanced search
Notify
RSS
Atom
Changes
Statistics
Web preferences
NOTE: Please use the Sandbox web for testing
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use.
Please read the following
disclaimer
.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more
here
.