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 () software packages, follow these steps:
Backing up and restoring applications (Right click to open the link in a new window)
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 applications, you select the installation directory. For example, if you installed by using 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 is installed on a separate server than other applications, you must start up first and shut down 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 applications are installed. This directory includes all data necessary to restore the 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:
() application
() application
() application
() application
() application
() application
For tools to backup and restore, see Backing up and restoring and ().
() application
() application
() application
For tools to backup and restore, see Backing up and restoring and ().
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.
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 , 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.
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 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 or , 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 application is running on , 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.
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 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 and , where the directory is named derbyDB, warehouseDB for the data warehouse, and db for . 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 from a point in time shortly before or equal to the last transaction of the 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 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 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:
You can use the restoreConfig command to restore the configuration of your node after backing up the configuration using the backupConfig command. See, restoreConfig command
You can use the restoreConfig command to restore the configuration of your node after backing up the configuration using the backupConfig command. See, restoreConfig command
This step must be done by a database administrator. The information about the how to restore the database is provided by the database vendor.
This step must be done by a database administrator. The information about the how to restore the database is provided by the database vendor.
To restore or from a backup, see Backing up and restoring and ().