Informix OnBar and Tivoli Storage Manager, Part 1
Configure and use IDS/OnBar with Tivoli Storage Manager for powerful backup and restore
Relational database servers build the information backbone for many companies today. These companies rely on the smooth operation of their database servers and any outages could have an great impact on their business. Keeping that in mind, backup is one of the most critical aspects for every DBA. It has to be done on a regular basis. The inability to restore from a backup in an emergency situation will have serious consequences for your company and probably for you as a DBA who is responsible for these tasks.
This is the first part of a two-part article series discussing the backup of the IBM Informix Dynamic Server (IDS) using IBM Tivoli Storage Manager (TSM). The article shows you how to implement your backup solution using these IBM products and gives you some valuable hints on how to do it.
Below you will find some common terms used when working with the TSM product. These terms are necessary in order to understand the interrelations to IDS.
Archive and backup objects
TSM has two different kind of storage objects called archive and backup objects. The main difference between them is that backup objects can be in an active or inactive state, while archive objects don't have this distinction.
Active backup objects will never expire; only inactive backup objects will expire based on the attributes that have been set in the underlying backup copy group.
The following table gives you an overview about the attributes of archive and backup copy groups and their place inside the TSM hierarchical structure:
Archive and backup copy groups
|Backup Copy Group||Archive Copy Group|
Maximum number of backup versions to retain for files that still exist on the client. However, if the retention time specified by RETEXTRA is reached, VEREXISTS is ignored.
Number of days to keep an archive copy.
Maximum number of backup versions to retain for files that have been deleted on the client.
Specifies when the retention time specified by RETVER is initiated, either by CREATION or by EVENT.
Number of days to retain a backup version after that version becomes inactive.
Minimum number of days to keep an archive copy.
Number of days to retain the last backup version of an object that has been deleted on the client.
A policy domain is a logical grouping entity. TSM offers a default policy domain named standard. The TSM administrator can define additional policy domains.
Within a policy domain there exists policy sets. A policy set is a logical grouping of one or more management classes. Only a single policy set can be active at a time.
Each policy set contains a default management class and one or more additional management classes. The management classes consist of archive and backup copy groups. These copy groups contain the crucial attributes that control the expiration of objects of this type (archive or backup objects). Details about the configured management classes can be retrieved through the 'dsmc query mgmtclass -detail' command (see Query TSM).
During the registration of a TSM client node, it will be bound to a single policy domain (by default the standard policy domain) and thus uses the active policy set for this policy domain. So objects backed up under this TSM client nodename will be assigned to management classes defined in the active policy set for this policy domain.
IDS backup utilities
Informix delivers two independent backup utilities:
There has been a third backup utility in the past named onarchive. However, the onarchive utility is no longer delivered with IDS V9.4 and later versions of IDS.
With ontape, you are able to make online backups. These backups can be sent to tape (local or remote), to disk, or to a pipe that makes ontape quite flexible. However, you are not able to parallelize your backups and there is no direct interface to a storage manager.
In order to store ontape backups in TSM, you can perform your backup to disk and then use the TSM dsmc utility to send it to TSM. There are Informix customers doing their backups in that way; however, we will not discuss this possibility here.
The other Informix backup utility is called onbar (Online Backup Archive). Onbar uses the XBSA interface (X/Open Backup Services API) to communicate with third-party storage managers. With onbar you can parallelize your backups and you are also able to perform a point-in-time restore. An Informix storage manager (ISM) is bundled with IBM IDS, which allows customers without separate third-party storage manager to use onbar.
External backup and restore
IDS is also able to work together with split mirror technologies provided by sophisticated disk subsystems. This method is called EBR (External Backup Restore). For these kind of backups, IDS allows the blocking of the database server through 'onmode -c block' to accomplish a consistent state. During a restore, IDS is able to combine an external physical restore with a logical restore. The EBR method is not further discussed in this article.
To send backups from onbar to TSM, you need the IBM Tivoli product called Data Protection for Informix if you are working with IDS V7.x or V9.x. Data Protection for Informix is now bundled with IDS V10. We will discuss this interface in the following sections.
Database server objects
The examples below use an Informix database server named ids10 with server number 67.
IDS has two kinds of database server objects that can be backed up with onbar:
- Logical logs
As already mentioned, both types will be stored as TSM backup objects (see Archive and backup objects) and there is no possibility to customize this behavior. IDS always generates backup objects.
IDS stores information about each backup operation (dbspaces and logical logs) in a database called sysutils. This database is automatically created during the first initialization of the database server and contains several tables populated with information about the backups that have been performed. Data in the sysutils database can be selected using SQL.
In addition to the sysutils database, IDS also stores information in a flat file called the emergency boot file. The emergency bootfile is located here:
The emergency bootfile is needed for cold restores. A cold restore is a restore where the database server is not available and thus the sysutils database cannot be accessed. Onbar retrieves the necessary information from the emergency bootfile. During warm restores, the database server is online and onbar will query the sysutils database for information about backups.
Type of backups
IDS allows you to take backups of dbspaces and logical logs. Both backups are performed using the onbar utility. The backup of the logical logs is configured with the Informix ALARMPROGRAM mechanism.
Informix distinguishes between two different types of dbspace backups:
- Whole-system backup
- Parallel backup
Both types of backups can be performed while the database server is online, executing transactions.
A whole-system backup is a snapshot of the entire system at a single point in time (known as the archive checkpoint). Whole-system backups are performed sequentially (dbspace after dbspace) and they can be restored without applying any logical logs. Without logical logs, the system is restored to a consistent point, which is the archive checkpoint. All open transactions that existed at the archive checkpoint will be rolled back.
Parallel backups allow the processing of several dbspaces ($ONCONFIG parameter BAR_MAX_BACKUP) simultaneously, thus reducing the overall backup time if the infrastructure is adequate. However, in the case of a restore, a parallel backup will rely on the logical logs to reach a point of consistency.
It is essential that you ensure your logical logs will be backed up regularly if you plan to do parallel backups or want be able to perform point-in-time restores. Informix versions before IDS V10 did not prevent you from doing parallel backups without saving your logical logs. However, in the case of a restore, you won't be able to get your data back because the logical logs are needed to reach a point of consistency for backups performed in parallel mode.
Make sure that the $ONCONFIG parameter LTAPEDEV is set to something different than /dev/null and that the configured ALARMPROGRAM is capable of doing log backups with onbar. If LTAPEDEV is set to /dev/null, a logical log will be marked as backed up as soon as a log switch occurs. The logical log will not be saved. (see IDS/Onbar configuration).
For both types of backups (whole system and parallel) you will be able to specify the backup level, for instance, if this should be a full or an incremental backup:
- All used pages are backed up
- Only pages that have changed since the last Level-0-Backup will be backed up
- Only pages that have changed since the last Level-1-Backup will be backed up. If the last backup is a Level-0-Backup, a Level-2-Backup will be the same as a Level-1-Backup.
Incremental backups are reasonable because they reduce the time needed to restore the database server. Applying a Level-0-Backup and then incremental backups will be much faster than having to rollforward through a large range of logical logs.
Type of restores
IDS differentiates between the following types of restores:
A cold restore has to be done if any of the critical dbspaces (such as root dbspace, dbspaces containing the logical logs, or the physical log) is down. During the restore, the database server will not be available.
A warm restore can be performed for non-critical dbspaces only. During a warm restore the database server is available and any data that is not contained in the dbspaces that are currently restored can be selected and updated.
A mixed restore is the combination of a cold and a warm restore. The critical dbspaces (and probably some non-critical, too) are restored in offline mode. After that, the database server is brought in online mode and then the remaining dbspaces will be restored. This approach allows the DBA to restore the most important data first, making it available to the users before restoring the less important data in online mode.
These types of restores rely on the information in the logical logs. The database server can be either restored to a specific point in time or to a specific logical log. It is important to notice that in both cases the whole database server will be restored to the specified point-in-time or logical log. Individual dbspaces cannot be restored to a certain point-in-time or logical log.
The separate product TDP for Informix is only needed for IDS versions before 10. The complete process of installing and configuring TDP for Informix is described in the IBM product manuals (see Related topics). You might need assistance from your TSM system administrator in order to provide the necessary configuration values.
Please note that the 32-bit IDS instances must use the 32-bit TDP/Informix components and 64-bit versions of IDS must use the 64-bit components of TDP/Informix.
32-bit versions of IDS have the U identifier in the version number; for example:
64-bit versions of IDS have the F identifier in the version number; for example:
The 32- and 64-bit versions of TDP/Informix are normally installed in the same base directory; however, the 64-bit version appends the 64-identifier to the end of the pathname, such as is shown below:
- 32-bit: /usr/tivoli/tsm/client/informix/bin
- 64-bit: /usr/tivoli/tsm/client/informix/bin64
Here is a short overview of the individual steps that should be performed as user root. Step 2 is not required if you are using IDS V10. TDP/Informix, which is known as TXBSA and is already included in IDS 10.
- Installing the TSM/API
- The TSM/API is the basis. TDP/Informix uses the TSM/API to send and receive data to and from the Tivoli Storage Manager. The TSM/API package is available on the TDP/Informix software CD ROM. The installation is performed using the native operating system procedures (see below).
- Installing TDP/Informix
- The software is installed using the native operating system package installation procedures like smitty (installp) on IBM AIX® or pkgadd on
Sun Solaris. The default installation directory depends on your platform:
- AIX (TSM API): /usr/tivoli/tsm/client/api/bin
- AIX (TDP/IFX): /usr/tivoli/tsm/client/informix/bin
- Solaris (TSM API): /opt/tivoli/tsm/client/api/bin
- Solaris (TDP/IFX): /opt/tivoli/tsm/client/informix/bin
In IDS V10, the TXBSA library is available in $INFOMIXDIR/lib.
- The software is installed using the native operating system package installation procedures like smitty (installp) on IBM AIX® or pkgadd on Sun Solaris. The default installation directory depends on your platform:
- Defining Environment Variables
- Full pathname of the client user options file (dsm.opt)
- Full pathname of the TSM API installation path (only necessary if not installed in the default path)
- Full pathname of the TDP/Informix installation path (only necessary if not installed in the default path)
- Full pathname of the directory where the TSM API error logfile (dsierror.log) should be created
- Edit client system options file (dsm.sys)
- Specify a logical name (server stanza) for this group of entries. There can be multiple server stanzas in the dsm.sys file. The server stanza that will be used is
determined by the following order of decreasing priority:
- The SERVERNAME set in your client user options file (dsm.opt)
- The DEFAULTSERVER entry in the client system options file (dsm.sys)
- The first server stanza in the client system options file (dsm.sys)
- Set PASSWORDACCESS to GENERATE. This ensures that TSM will not ask for a password because onbar will not be able to handle this. The encrypted password is stored locally (filename TSM.PWD) and also a new password is automatically generated and stored locally when the old password expires.
- Specify the NODENAME under which the client should contact the TSM server. If no NODENAME is specified, the hostname of the machine will be used.
- Set the INCLEXL parameter to the full path of the inclexcl.def file.
- There are several additional parameters that need to be set in order to identify the TSM server like COMMETHOD, TCPSERVERADDRESS, and TCPPORT. Your TSM administrator should be aware of them.
- Specify a logical name (server stanza) for this group of entries. There can be multiple server stanzas in the dsm.sys file. The server stanza that will be used is determined by the following order of decreasing priority:
- Edit client user options files (dsm.opt)
- Set the SERVERNAME pointing to the appropriate server stanza of the client system options (dsm.sys).
- Add entries to the inclexcl.def file
- Add entries to assign appropriate management classes to your IDS backup objects (see Management class assignment). The location of the inclexcl.def file is configured with the INCLEXCL parameter in the dsm.sys file.
- Register the client node on the TSM server
- Your TSM administrator should register your TSM client node on the TSM server under the desired NODENAME. If asked, you don't need the BACKDEL (deleting backup objects) permission because onsmsync (the storage manager synchronization utility provided by IDS) only executes the BSAMarkObjectInactive() XBSA-call for logical logs. This call can be performed without the BACKDEL permission because objects are only inactivated not deleted.
- Initialize TSM password
- Run the tdpipswd, which is delivered with TDP/Informix. In IDS V10, which has TXBSA already bundled, this program is called:
- Run the tdpipswd, which is delivered with TDP/Informix. In IDS V10, which has TXBSA already bundled, this program is called:
The IDS configuration part for TDP/Informix is quite simple. The following parameters should be set in your $INFORMIXDIR/etc/$ONCONFIG file:
- Set this to the full pathname of the XBSA library provided by TDP/Informix if using IDS versions before 10:
- AIX: /usr/tivoli/tsm/client/informix/bin/bsashr10.o
- Solaris: /opt/tivoli/tsm/client/informix/bin/libTDPinf.so
Depending on the TDP/Informix version used on AIX, the object file bsashr10.o might not be directly available. If this is the case, you have to extract this object file from the libTDPinf library with the ar command:
- cd /usr/tivoli/tsm/client/informix/bin
- ar x libTDPinf.a
IDS will also try to open the XBSA library under a default path if BAR_BSALIB_PATH is not set. However, this default path depends on the used IDS version, so defining BAR_BSALIB_PATH is ambiguous. If already on IDS V10, then set BAR_BSALIB_PATH to:
- AIX: $INFORMIXDIR/lib/libtxbsa.a
- Solaris: $INFORMIXDIR/lib/libtxbsa.so
- Set this to the full pathname of the XBSA library provided by TDP/Informix if using IDS versions before 10:
- Full pathname of the onbar activity log. This is the primary logfile for any messages relating to onbar. There are additional parameters available for turning debugging on, which will be discussed in the second part of this article series.
- Create the sm_versions file
- cd $INFORMIXDIR/etc
- cp -p sm_versions.std sm_versions
Change the single configuration line in the sm_versions file to:
- LTAPEDEV and ALARMPROGRAM
- Backing up your logical logs is always a good idea and it is essential if you plan to do parallel backups or want to be able to perform point-in-time restores (see Type of backups). Set LTAPEDEV to something different than /dev/null and set ALARMPROGRAM to $INFORMIXDIR/etc/log_full.sh.
- You should set this $ONCONFIG parameter to ON. It might save you valuable time because you will be able to continue with interrupted or failed restores without starting from the beginning.
After these changes, restart IDS (onmode -ky && oninit). Now you should be able to back up your IDS instance to TSM using onbar.
Monitoring an ongoing backup operation is possible by executing a tail -f on your onbar activity logfile. In addition, you can execute the onstat -g arc command to monitor the progress of your backup.
Management class assignment
As already mentioned, onbar always generates TSM backup objects. These backup objects are bound to a specific management class and are stored according to the attributes of the underlying backup copy group (see Archive and backup copy groups).
There is no configuration parameter available in IDS to specify an explicit management class for backups. The $ONCONFIG parameters ISM_DATA_POOL and ISM_LOG_POOL are only used by ISM, the included storage manager integrated in IDS.
The binding of backup objects to specific management classes is done externally (TSM API) by comparing the backup object names to the pattern set in the inclexcl.def file. The location of the inclexl.def file is determined by the INCLEXCL parameter in you client system options file (dsm.sys). The default location is:
- AIX: /usr/tivoli/ tsm/client/api/bin/inclexcl.def
- Solaris: /opt/tivoli/tsm/client/api/bin/inclexcl.def
Backup object names
All backup objects stored in TSM have a name associated with them. The client (onbar) controls the following key components of this name:
- For dbspaces and logical logs, the name of your IDS instance (DBSERVERNAME) is used here (see Query TSM). The filespace name is important to TSM as it groups related data together. Certain TSM operations operate on the filespace level.
- For dbspaces, a combination of the IDS instance name plus the name of the individual dbspace is used here. For logical log backups, it is a combination of the IDS instance name plus the IDS servernumber. (see Query TSM)
- For dbspaces, the backup level (for example, level-0, level-1, or level-2) is used here. For logical log backups, it is the logical log ID. (see Query TSM).
Here are two inclexcl.def entries for our IDS instance named ids10, servernumber 67 with different management classes for dbspaces and logical logs:
- include /ids10/.../* IFX_LOG
- include /ids10/.../[0-2] IFX_DB
The pattern matching is performed from the bottom to the top of the inclexcl.def file. Though the first entry will match all objects (dbspaces and logical logs), dbspace backups will be correctly assigned to management class IFX_DB because the matching is done from the bottom upwards and stops as soon as a match has been found. For dbspaces, it stops at entry 2. Logical log backup object names will not match entry 2. They will match entry 1, which assigns them to the management class IFX_LOG.
However, you can change entry 1 in your inclexcl.def to clarify this distinction:
- include /ids10/.../67/* IFX_LOG
Backup objects for which there is no matching entry found are bound to the default management class in the active policy set (see Archive and Backup Copy Groups).
It is also possible to place an exclude entry in the first line of the inclexcl.def file to prevent the implicit binding to the default management class for non-matching objects; for example:
- exclude /.../*
An error is returned to the client if no matching entry is found in inclexcl.def because it is essential that each backup object is bound to a management class. If this cannot be done, TSM will return the XBSA errorcode 96 (0x60).
The TSM command line tool dsmc can be used to control the correct assignment of management classes to backup objects. Here are some examples for retrieving the backup object names for our IDS instance called ids10 with servernumber 67:
|query backup 'ids10/*'||Show all active backup object names (dbspaces and logical logs)|
|query backup -inactive 'ids10/*'||Show all active and inactive backup object names (dbspaces and logical logs)|
|query backup 'ids10/ids10/67/*'||Show only active backup object names referring to logical logs|
|query backup 'ids10/*' -fromnode=ifx_node||Show all active backup object names for backups taken under the dedicated nodename ifx_node|
|query mgmtclass -detail||Show detailed information about the management classes in the active policy set|
Example output from the dsmc command
dsmc query backup -inactive "/ids10/*" Size Backup Date MgmtClass A/I File ---- ----------- --------- --- ---- API 4.194.304 B 09.11.2005 08:29:45 IFX_LOG A /ids10/ids10/67/100 API 1.892.352 B 21.12.2005 11:39:02 IFX_LOG A /ids10/ids10/67/101 API 4.194.304 B 08.11.2005 10:25:55 IFX_LOG I /ids10/ids10/67/95 API 4.194.304 B 08.11.2005 10:27:11 IFX_LOG I /ids10/ids10/67/96 API 4.194.304 B 08.11.2005 11:59:28 IFX_LOG A /ids10/ids10/67/97 API 4.194.304 B 08.11.2005 12:00:01 IFX_LOG A /ids10/ids10/67/98 API 4.194.304 B 08.11.2005 12:08:49 IFX_LOG A /ids10/ids10/67/99 API 13.438.976 B 21.12.2005 11:38:32 IFX_DB A /ids10/ids10/ehtest/0 API 184.320 B 03.08.2005 12:32:56 IFX_DB A /ids10/ids10/ehtest/1 API 42.160.128 B 21.12.2005 11:38:35 IFX_DB A /ids10/ids10/logdbs/0 API 42.147.840 B 03.08.2005 12:32:56 IFX_DB A /ids10/ids10/logdbs/1 API 217.088 B 21.12.2005 11:38:35 IFX_DB A /ids10/ids10/physdbs/0 API 10.690.560 B 03.08.2005 12:32:56 IFX_DB A /ids10/ids10/physdbs/1 API 27.549.696 B 21.12.2005 11:38:06 IFX_DB A /ids10/ids10/rootdbs/0 API 15.728.640 B 03.08.2005 12:27:02 IFX_DB A /ids10/ids10/rootdbs/1 API 738.900 KB 03.08.2005 14:38:21 IFX_DB I /ids10/ids10/logdbs/0 API 736.200 KB 08.11.2005 12:08:19 IFX_DB I /ids10/ids10/logdbs/1
Beside the assigned management class, you see also the status (Active or Inative) of the individual backup objects in column A/I.
This was the first part of the article. In the upcoming second part, I will talk about common IDS/TSM pitfalls, tracing methods, and other interesting onbar features.
- Visit the developerWorks Informix technical resources center for more technical information and resources.
- IDS 10 Information Center provides easy Web-based access to the whole documentation set of IDS V10.
- IDS Support Center contains helpful technotes and other support information regarding IDS.
- Backup and Restore Guide provides detailed information about onbar.
- onbar returncodes contains the officially documented onbar returncodes.
- TSM Information Center provides easy Web-based access to the whole documentation set of TSM.
- TDP/Informix Documentation provides information about TDP/Informix.
- TSM for Databases Support Knowledge Base provides some valuable hints if you search for informix or onbar.