If you have a TSM database spread across mutliple database volumes on disk, be very careful on how you use them. It is best to assign multiple database volumes on different disks, all equal in size. This way, TSM is able to use the performance of several disks equally.

Also, take a look at the assigned capacity of the TSM database. It might well be that not the full capacity of the database is assigned to TSM; this way, some database volumes are more heavily used than other. A good command to check if the database volumes are equally used is "q dbspace":

q dbspace
q db f=d

When using TSM on AIX, JFS file systems for storage of the database volumes are preferred, and not RAW logical volumes. This subject usually tends to cause discussion, so here are the reasons for using JFS and not use RAW logical volumes:

When TSM has JFS files open, they are locked by JFS and other applications cannot write to them. However, raw logical volumes are not locked and any application can write to them. TSM tries to prevent starting more than one instance of the same server from the same directory, but it can be done. If you are using raw logical volumes, multiple server instances can simultaneously update the same information. This could cause errors in the database, recovery log, or storage pool raw logical volumes. Auditing a corrupted TSM database and fixing corruptions can take up to a day downtime.

After a database, recovery log, or storage pool volume is defined to TSM, you cannot change its size. TSM uses size information to determine where data is placed and whether volumes have been modified by other applications or utilities. However, if you use raw logical volumes, smit lets you increase their sizes. If the volume is defined to TSM before its size is increased, TSM cannot use the volume or its data.

The use of JFS file systems for database, recovery log, and storage pool volumes requires slightly more CPU than is required for raw volumes. However, JFS read-ahead caching improves performance. Lab tests have proven that the use of raw logical volumes tend to give better performance. So as long as you have enough CPU, you may still use JFS.

How many times can the tape drives be cleaned?

# mtlib -l /dev/lmcp0 -qL

# mtlib -l /dev/lmcp0 -qC -s FFFD

# mtlib -l /dev/lmcp0 -qE -V [tape-volume-serial-number] -u

# dsmadmc -c comma -id=readonly -password=readonly q dr f=d

# query path

Want to know what all TSM administrators did in the last 24 hours in TSM?

# dsmadmc -comma -id=readonly -password=readonly query actlog s=ANR2017I begind=-1 begint=09:00 endd=today endt=09:00 | grep -v -i readonly | grep -v -i ibm-oc-server1

register admin readonly readonly contact="Readonly account'

Tivoli Storage Manager (TSM) is a backup system. Not just any backup system, but probably the best there is. It exists for over a decade and is a product of IBM. It used to be known as ADSM (Adstar Distributed Storage Manager); later on it was renamed to TSM (Tivoli Storage Manager) and nowadays it is known as ITSM (IBM Tivoli Storage Manager).

One of the most important benefits of TSM is the fact that it runs on many systems; it has a broad hardware support. TSM runs on AIX, HP-UX, Linux, Sun Solaris, and Windows. Client software for even more operating systems exist (Such as Mac, Netware, OS400, Tru64UNIX), thus enabling the backup of other operating systems to TSM.

Another important aspect of TSM: the progressive incremental backup. Only files that are changed or are new to the system are backed up, therefore eliminating unnecessary data transfers, and gives you faster backup times. Progressive incremental backups needs to backup less data, thus saving network bandwith, tapes and management overhead. No more full backups are required.

TSM can be combined with several Tivoli Data Protection agents. These are add-ons to TSM, which enable you to create backups of several databases (e.g. Oracle or DB2), ERP applications (e.g. SAP/R3), mail (e.g. Exchange), and others. These TDP agents also enables online backups, so vital systems can stay online during backups.

Besides backup and restore, TSM also includes functions for archiving/retrieval and hierarchical storage management, to free up disk space normally used by files that aren't accessed for an extended period of time.

TSM can be administered centrally, either via the command-line or via a Web-based Enterprise Console. TSM is based on a (DB2) database, which needs zero management. All information of backups, backup versions and overhead is stored in the TSM database. TSM has its own powerfull scheduler, for either backup schedules or TSM maintenance schedules (so-called administrative schedules) which automate a lot of house-keeping jobs in TSM.

TSM stores its backup data in a variety of storage pools, which can consist of various sequential (tape) media or direct-access (disk) media. The storage pools are very flexible and data can be moved from one storage pool to another (migration). Building a hierarchy of storage pools is possible, thus enabling fast backups to disk storage pools and later on, migration from disk to tape storage pools. Data storage is based on policies, defined by the administrator in TSM. These policies include information on how many backup versions to store, and how long to retain the backups.

Note: From TSM 5.3 the Web Admin GUI is no longer supported. Because of popular demand, IBM has made the TSM 5.2 Web Admin GUI available for TSM 5.3.

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

RM and RMDB on separate systems

IBM (DB2) Content Manager Version is a product available for Microsoft Windows, AIX, Sun Solaris and Linux. The former name of IBM Content Manager was Visual Info. Actually, the Content Manager portfolio from IBM is much larger, than this single product. Basically, there are 2 products, the first one called IBM Content Manager, and the second one IBM Content Manager OnDemand. Besides these two, there are a lot of additional tools and products.

ICM is a system for the management of business content, or Enterprise Content Management (ECM). It handles all types of digitized content, based on access via browsers, similar to Documentum. In other words: ICM is a system which allows storage of digitized documents, which can be retrieved via a web browser. Content Manager OnDemand is specifically used for storing spooled output and usually replaces the older Microfiche.

In general, most organizations have well-developed information systems in place for storing, sorting and retrieving text-based data records (business or structured data). These same organizations however, usually do not have the same type of data storage and retrieval systems in place for the large and growing mass of digital media (unstructured or semi-unstructured data).

The concept of Enterprise Content Management is to bring under the control of one system a platform independent integrated solution for storing and managing large quantities of multimedia content as well as the traditional relational database data. This allows database management facilities such as referential integrity, transactional integrity, robustness and archival and retrieval to be utilized to manage the full range of data objects within the modern enterprise.

Data stored by IBM Content Manager can be categorized as follows:

• Operational content: Scanned images (often in TIFF format - Tag Image File Format), Facsimiles, Computer generated output.
• Workgroup documents: Word processors (like MS Word, WordPerfect, Adobe FrameMaker, Lotus), Spreadsheets (MS Excel and Lotus 1-2-3), Presentation graphics.
• Media Assets: Audio and Video (MPEG).
• Web Content: HTML, graphics, business content.

A standalone configuration of IBM Content Manager

A very easy way of getting a report from a backup is by using the POSTSchedulecmd entry in the dsm.sys file. Add the following entry to your dsm.sys file (which is usually located in /usr/tivoli/tsm/client/ba/bin or /opt/tivoli/tsm/client/ba/bin):

POSTSchedulecmd "/usr/local/bin/RunTsmReport"

#!/bin/bash
TSMLOG=/tmp/dsmsched.log
WRKDIR=/tmp
echo "TSM Report from `hostname`" >> ${WRKDIR}/tsmc
tail -100 ${TSMLOG} > ${WRKDIR}/tsma
grep -n "Elapsed processing time:" ${WRKDIR}/tsma > ${WRKDIR}/tsmb
CT2=`cat ${WRKDIR}/tsmb | awk -F":" '{print $1}'`
((CT3 = $CT2 - 14))
((CT5 = $CT2 + 1 ))
CT4=1
while read Line1 ; do
   if [ ${CT3} -gt ${CT4} ] ; then
      ((CT4 = ${CT4} + 1 ))
   else
      echo "${Line1}" >> ${WRKDIR}/tsmc
      ((CT4 = ${CT4} + 1 ))
      if [ ${CT4} -gt ${CT5} ] ; then
         break
      fi
   fi
done < ${WRKDIR}/tsma
mail -s "`hostname` Backup" email@address.com < ${WRKDIR}/tsmc
rm ${WRKDIR}/tsma ${WRKDIR}/tsmb ${WRKDIR}/tsmc