Topics: Backup & restore, IBM Content Manager, Spectrum Protect

Backup tips for IBM Content Manager

Creating consistent backups is probably one of the most difficult things to do with IBM Content Manager (ICM). The databases function as a reference to all content stored on disk or on TSM archive. Here are some options on how to create consistent backups.

1. Offline

This is a very easy way: take the complete system down and do a backup. This is a fair solution if you have a rather small amount of documents stored in ICM.

2. Offline, but parallel

This is the same as the first option, but this time you'll backup the databases and content data in parallel. This will save some time.

3. Offline, parallel and improved

This is the same as option 2, but with a faster Resource Manager (RM) content backup. Backing up a lot of RM data can still take a very long time. E.g., backing up 10 million files can take 8 hours to complete, which was might be too long. To improve the RM content backup, create two separate sessions for the RM content backup: a find process, that takes care of finding all directories in the RM content file system, which pipes the output to the second process: the backup process, that started a backup session per directory found. Normal backups with TSM would do a scan of the file system first (find) and then backup all data that is changed. By using this pipe, these two functions will act in parallel. You should limit the maximum amount of sessions to the TSM server to 20; otherwise you might overload the TSM server with sessions. With normal TSM performance, backing up 10 million files suddenly changes from 8 hours to 1 hour!

Only drawback about this option is, that TSM doesn't recognize this directory-type backup as a complete file system backup, and will therefor report the filesystem as not having backed up completely. So you'll need to create all kinds of checks in the backup script in order to check, if everything went ok (if all directories have succesfully backed up).

4. Offline, but with read-only RM content backup

This option is only feasible, if you can backup your RM content read-only. This option will backup your databases offline, but after the database backup is complete, the system is started again and the RM content file system will be set to read-only. This way, users are still able to retrieve documents; when trying to store a document, they will receive an error, until also the RM content backup completes. The only down-time needed in this situation is the time for backing up the databases. This option is interesting if there are no users during evening and night-time releasing new documents to ICM. Important with this option: you'll have to keep the Migrator process down during the read-only backup, since this process might try to delete documents from the RM content. Just start the Migrator again, when the read-only RM content backup completes.

Also very important with this option: It might well be, that the database changes during the RM read-only backup. If you have to restore the system, you'll restore the last database backup and the last RM file system backup. Any changes to the database (usually only user session information and attribute data of the documents) will get lost with this restore. If that is no problem for you, you can use this option.

5. Offline, using the JFS2 snapshot

This only works on AIX and JFS2 file systems. Starting with AIX 5.2 you can use the JFS2 snapshot. This is an AIX feature, with which you create a snapshot of the JFS2 file system, called the snappedFS file system. Creating a snapshot only takes a few minutes. It creates a new file system and copies the file system meta-data from the snappedFS to snapshot file system. If, during the existence of the snapshot any changes are made to the snappedFS, than the previous blocks are copied to the snapshot. This way it will keep the snapshot of the file system as it was at the moment it was made. You can backup this snapshot, knowing that this file system never changes. After the backup, you can delete the snapshot.

If you have to restore, just restore the last offline database backup and the RM file system backup.

Important: running defragfs on file systems with snapshots, creates a lot of changed data blocks and therefor might use up a lot of available space for the snapshot. If the snapshot runs full, it will be deleted. Usually, you'll need to create a snapshot of only 3-6% of the original file systems size.

6. Online, using the JFS2 snapshot The ultimate solution: Backup the databases online, then pause ICM. Then create the JFS2 snapshot. The only downtime experienced by the users, is the moment that ICM is paused until it is resumed again. If you have to restore the system, restore the system until the point-in-time, the JFS2 snapshots are taken. This way, you'll know for sure that the database is consistent with the RM data.

Online DB2 backup and JFS2 snapshot

Other considerations for backups

There are also some other things, that are important, when backing up a content management system:

ICM gives you the possibility of configuring the system in multiple ways: You may install the Libary Server (LS) and the Resource Manager (RM) on the same system, but you may also install the RM on a completely different system, even on another Operating System:

RM and RMDB on separate systems

Having the LS and the RM on the same system is much easier method to create a consistent backup. When you have the RM on a separate system, you'll have to figure out how to create a consistent backup, which is quite difficult.

Because you're backing up different parts (databases, file systems), as a backup administrator, you'll probably have to deal with different people involved in managing the system. You'll have to keep them informed about what the backup is doing, and probably give them a way to check if the backup is active or not. E.g. Web admins might start up the applications again, without any knowledge of the backup status, thus ruining the complete backup. Communication is important here.

ICM has an utility to check the consistency of the database with the RM content: icmrmvolval. You'll have to run this utility once in a while, especially after a restore!

Document your backup solution, in the event someone else needs to restore the system, while you're away on holiday.

Do not store all the RM content in a single file system. If you go beyond 8 million files in a single file system, the index for this file system in TSM will grow beyond 2 Gigabytes, which is a process limit for AIX. If a process grows beyond 2 GB, it will core dump. You can do a memory-efficient TSM backup. This option requires a lot less memory, because it will retrieve index information per directory from TSM, somewhat like option 3. Drawback of this option is, that a memory-efficient TSM backup takes a much longer time to complete.

If you found this useful, here's more on the same topic(s) in our blog:

UNIX Health Check delivers software to scan Linux and AIX systems for potential issues. Run our software on your system, and receive a report in just a few minutes. UNIX Health Check is an automated check list. It will report on perfomance, capacity, stability and security issues. It will alert on configurations that can be improved per best practices, or items that should be improved per audit guidelines. A report will be generated in the format you wish, and the report includes the issues discovered and information on how to solve the issues as well.

Interested in learning more?