Backing up IBM® Connections

Before you migrate or update IBM® Connections, back up your databases and applications.

About this task

Follow these steps to back up your IBM® Connections deployment. You can use this backup to restore your existing deployment if the migration or update fails. This procedure backs up your entire deployment, you cannot use it to back up individual applications within IBM® Connections.
Note: Pay attention to the version of IBM® Connections you are backing up. If you must restore the backup later, it can be restored only to the same version of IBM® Connections, as described in the following details:
  • Content can be restored only to the same major/minor release that it was backed up from. For example, Cumulative Refresh (CR) releases for Connections 5.5 are considered part of the Connections 5.5 release.
  • Content cannot be restored to a later release (for example, Connections 5.5) if it was backed up on an earlier release (for example, Connections 5.0 (CRx)).
  • The /provision subdirectory in the shared content folder can be restored only to the exact version that it was backed up on. It is not safe to restore the /provision subdirectory to a version with a CR or an interim fix different from the version the directory was backed up from.


  1. Stop the IBM® WebSphere® Application Server instances that are hosting IBM® Connections.
  2. If you installed Connections Content Manager, back up the FileNet® Storage Area and the Engine-ws.ear file.
    By default the FileNet® Storage Area is in the following directory:
    Note: You need to back up FileNet Storage Area if it is reconfigured outside of <shared_data_directory_root> only.

    By default, the Engine-ws.ear is in the following directory:

    • For Connections 5.0:
      • For Linux, AIX®, or Linux on System z®:
      • For Windows:
    • For Connections 5.5:
      • For Linux, AIX®, or Linux on System z®:
      • For Windows:
  3. Determine whether the filenetAdmin user (usually the same as the ConnectionsAdmin user) is a local WIM user and, if so, back up the local fileRegistry.xml file to restore it after migration.
    1. Find the user that is used by Connections to contact FileNet®.

      From the WebSphere® Application Server administrative console, navigate to Security > Global Security > Java Authentication and Authorization Service > J2C authentication data and make note of the User ID of the filenetAdmin.

    2. Determine whether this user is in a local file-based repository.
      1. From the WebSphere® Application Server administrative console, navigate to Users and Groups > Manage Users.
      2. In the search box, enter the User ID of your filenetAdmin from the J2C authentication data and click Search.

        If the unique name of the user ends with o=defaultWIMFileBasedRealm, then your FileNet® administrator is from a local file-based repository and not LDAP. Therefore, continue to the next step to back up the fileRegistry.xml file.

        Ensure that you also add an LDAP group to the administrative access of FileNet® as described in Setting an LDAP group to be domain administrator in addition to, or instead of, a specific user.

    3. Back up the existing fileRegistry.xml file.

      For example, on Linux:

  4. Using native database tools, back up the databases. To back up Connections Content Manager databases, include both FileNet® databases: Global Configuration Database (FNGCD) and Object Store (FNOS). If the update or migration fails, use this backup to restore the databases.
  5. Back up the WebSphere® Application Server Deployment Manager profile directory: profile_root/Dmgr01. For example: D:\WebSphere\AppServer\profiles\dmgr.
  6. Back up your IBM® Connections deployment.
    1. Create a backup of the IBM® Connections installation directory: connections_root.
    2. Create a backup of the WebSphere® Application Server profile directory: profile_root
      Note: If IBM® Connections applications are deployed on separate profiles, archive each profile.
    3. Create a backup of the profileRegistry.xml file that is located under app_server_root/properties.
    4. Back up the local and shared data directories:
  7. Back up the Shared Resources directory:
    Note: For shared and remote network file system requirements, be sure to review the footnotes for each supported operating system in the detailed system requirements.
  8. Optional: Back up the IBM® Installation Manager data directory:
    Note: This step is necessary only if you are planning an in-place migration of IBM® Connections. That is, where you use the same systems to host the new deployment.
    • AIX® or Linux: /var/ibm/InstallationManager
    • AIX® or Linux (non-root user): /home/user/var/ibm/Installation Manager

      Where user is the account name of the non-root user.

    • Windows: C:\ProgramData\IBM\Installation Manager
    CAUTION: The Installation Manager's shared data directory needs to be backed up as well. If you need to go back to the older Connections installation after an upgrade, a conflict might occur if the IIM shared folder is not backed up and restored in parallel. The IIM relies on the data inside the shared folder to work correctly. If the version of Connections that IIM thinks is installed differs from the version of Connections that was restored on the file system, then IIM does not function correctly.
    Back up the following folder as follows:
    • Windows 2008:
      • C:\IBM\Installation Manager
      • C:\IBM\IMShared
      • C:\ProgramData\IBM\Installation Manager
    • Windows 2003:
      • C:\Documents and Settings\All Users\Application Data\IBM\Installation Manager
      • C:\IBM\Installation Manager
      • C:\IBM\IMShared
    • Linux:
      • /opt/IBM/InstallationManager
      • /var/ibm/InstallationManager
      • /opt/IBM/IMShared
    • AIX®:
      • /var/ibm/InstallationManager
      • /usr/IBM/InstallationManager
      • /usr/IBM/IMShared
  9. Back up any customized configuration files. For more information, see Saving your customizations.

    Most of the backup steps are covered in Saving your customizations, however, this procedure does not cover backing up security role mapping for users and groups. So be sure to back up security role mapping for users and groups before the servers are stopped. Otherwise, you have to start server again to back up this information.