It is critical that your IBM Connections data in its entirety is backed up and secured. Although the WebSphere Application Server servers might start and the applications appear to start, without access to the databases and data stores, the applications will not work.
The primary application data is stored on your Enterprise database server and a backup and data retention policy should be put in place to manage those databases. Although each application has its own database, in some situations, information is stored outside of the expected applications. For example, Communities data is stored across multiple applications such as Forums, Files, and Activities. For this reason, it is not often possible, certainly not with Communities, to restore a single database in order to roll back your application to a point in time.
There are tools available from IBM to restore deleted Communities, however, they are difficult to deploy and cannot restore all data.
It is critical that all IBM Connections servers are stopped before a database restore is attempted.
Local and shared data
Many customers forget to back up the local and shared data stores. The shared data stores especially which contain the file uploads from each application must be restored alongside the databases or the linked to files will not be present. The location of the shared and local data stores can be found under WebSphere variables in the Integrated Solutions Console.
To create a backup of the IBM Connections WebSphere server configuration, you can use the backupconfig
program that is found in the bin directory under every WebSphere profile, However, for our purposes, we would rely on the Deployment Manager’s configuration. The Deployment Manager, which manages all other servers in the cell, has the original copies of all the configuration files for every server. It will deploy these configuration files out to each of its managed servers if they are updated. For this reason, backing up the Deployment Manager configuration is what we need to concentrate on.
You can find the backupconfig file in /profiles/DMgr01/bin
The syntax for the file can simply be
backupConfig.sh / backupconfig.bat
However, in that form, the process with stop the Deployment Manager server completely and create a zip file in the bin directory of all the configuration files. If you do not want to have the Deployment Manager stopped in order to backup the configuration, you can use the -nostop (case sensitive) switch. You can also pass the command the name and location of the backup file that you want to create, that is
backupConfig c:\backups\dmgr050113.zip -nostop -username -password
This command creates a backup file called dmgr050113.zip in the backups directory of the C drive without stopping the Deployment Manager server itself.
If you do not have your server credentials stored in the soap.client.props file in the "properties" sub directory, you will be prompted for them during the backup, or you could pass the command line the -username and -password switches to avoid being prompted.
To restore the backup files, again move to the bin directory underneath the Deployment Manager profile and run the restoreConfig command. Once more, you can use the -nostop switch to prevent the server being stopped but since this is a restore process you do actually want the server stopped whilst the restore happens. For example:
restoreConfig -username -password