Regular Backups protect your valuable data from Hardware- and Software-Failures. IDS Developer Edition delivers with ontape and onbar powerful utilities to accomplish this important task.

We will discuss the ontape and dbexport utilities here as they offer the best combination between simplicity and effectiveness. For those interested in onbar, please check the Link Section at the end of this article.

All examples assume that you have logged on to the system as user informix. User root may also perform backups. However the recommendation is to perform those tasks as informix. Backups can be taken in online, quiescent or administration mode (see IDS operating modes). There are no transactions blocked when taking a backup online. Users have full read and write access to the IDS instance and it's databases during the backup.

Please make sure that you have created the suggested directory structure and the necessary environment settings are active. If the env.sh has been executed, variable $PENGUIN should point to our /home/informix/instances/penguin directory.

The ontape utility supports several different destination targets for your backup data:

1. directory
2. stdio
3. tape
4. file
5. named pipe

The most popular ones are directory and stdio as they offer the most flexibility and ease of use. Backing up directly to tape is a valid option if you've a tape drive attached to your machine. However we will only discuss directory and stdio in this article.

ontape allows you to take full (level-0) or incremental (level-1 and level-2) backups. A full backup contains all used pages at the time of the backup, a level-1-backup contains all modified pages since the last level-0-backup and a level-2-backup contains all modified pages since the last level-1-backup. So essentially a level-1 is an incremental backup of a full backup and a level-2 is an incremental backup of an incremental backup.

Keep in mind that ontape backups can only be exchanged between the same platforms and the same IDS versions. dbexport is platform and version independent.

Backing up to directory is the recommended backup method. Ensure that you've already created the suggested directory structure.

• vi $INFORMIXDIR/etc/$ONCONFIG

  • TAPEDEV   /home/informix/instances/penguin/backups

• Perform full backup

  • ontape -s -L 0 -d

The backup files will be automatically named by ontape using the following convention:

• Filename Schema:
  • <backup_dir>/<hostname>_<servernum>_<backup_level>
• Example: hostname=apollo4, servernum=1, backup_level=0
  • /home/informix/instances/penguin/backups/apollo4_1_L0

If a new backup of the same level is performed, ontape will automatically rename the previous backup file by adding a timestamp to the filename:

• Filename Schema:
  • <backup_dir>/<hostname>_<servernum>_<date>_<time>_<backup_level>
• Example: hostname=apollo4, servernum=1, backup_level=0, date=2007-11-11, time=13:13:17
  • /home/informix/instances/penguin/backups/apollo4_1_20071111_131317_L0

The environment variable IFX_ONTAPE_FILE_PREFIX can be set to overwrite the default filename created by the ontape utility:

• export IFX_ONTAPE_FILE_PREFIX=penguin

• ontape -s -L 0

  • Backup filename: /home/informix/instances/penguin/backups/penguin_L0

The onconfig parameter BACKUP_FILTER allows you to modify the format of the backup data. The specified filter is automatically applied to the backup data delivered by the IDS engine before it is processed by the backup utility (i.e. ontape or onbar). You can for example encrypt the data or compress it:

• BACKUP_FILTER  /usr/bin/gzip

It is important that you also set the RESTORE_FILTER onconfig parameter appropriately before restoring data that has been processed by a backup filter:

• RESTORE_FILTER  '/usr/bin/gzip -d -c'

Backing up to stdio is another popular backup method that offers great flexibility:

• Write full backup to stdout and redirect to file

  • ontape -s -L 0 -t STDIO > $PENGUIN/backups/ontape.l0

• Write full backup to stdout, pipe to gzip and redirect to file

  • ontape -s -L 0 -t STDIO | gzip > $PENGUIN/backups/ontape.l0.gz

ontape allows several methods of log backup:

• Discarding Logs (setting LTAPEDEV to /dev/null)
• Automatic Backup (thru the IDS alarmprogram mechanism)
• Manual Backup (ontape -a)
• Continuous Backup (ontape -c)

Beside discarding logs we will only discuss the automatic backup of logs here.

Remember restarting your IDS instance after you have changed LTAPEDEV to /dev/null or from /dev/null to another value.

If your are not interested in backing up your logical logs, just set the onconfig parameter LTAPEDEV to /dev/null. This will mark the logical log as free as soon as there are no log entries inside it that are part of an open transaction. Discarding your logs disables the possibility to perform a logical restore. In the case of a hardware- or software-failure, you would only be able to restore the data to the point of you your most recent |data backup:

• vi $INFORMIXDIR/etc/$ONCONFIG

  • LTAPEDEV   /dev/null

Configuring an IDS instance for log backup and performing an automatic backup of the logs is the recommended approach. You just need to set LTAPEDEV to a directory on your filesystem. Ensure that you've already created the suggested directory structure.

• vi $INFORMIXDIR/etc/$ONCONFIG

  • LTAPEDEV   /home/informix/instances/penguin/backup

The automatic backup ensures that a logical log is backed up thru the IDS alarmprogram mechanism as soon as a log switch occurs. You need to make some small modification to the IDS alarmprogram in oder to allow it to work with ontape:

• vi $(awk '/^ALARMPROGRAM/ {print $2}' $INFORMIXDIR/etc/$ONCONFIG)

  • BACKUPLOGS=Y

  • BACKUP_CMD="ontape -a -d"

If all your logical logs become full, the IDS instances blocks transactions until you backup the full logs. So make sure that your automatic backup method works and that you have enough free space in the configured filesystem (i.e. LTAPEDEV).

ontape allows you to restore the whole instance or individual dbspaces. We will only discuss the whole instance restore below. The IDS instance has to be in offline mode in order to start the restore.

The ontape utility can be started in interactive or non-interactive mode. In non-interactive mode (option -d) ontape assumes that the backup files to be restored are available in the backup directory (onconfig parameter TAPEDEV) with their original filename. In interactive mode, ontape will ask you for the respective backup files.

• Start Restore in non-interactive mode

  • ontape -p -d

• Start Restore in interactive mode

  • ontape -p

After the Restore the IDS instance will remain in the fast recovery mode, see onstat - output below:

IBM Informix Dynamic Server Version 11.10.FC1DE   -- Fast Recovery -- Up 00:04:12 -- 38360 Kbytes

You can now decide if you wish to perform a logical restore after the physical restore:

• ontape -l -d

Or you might directly switch the IDS instance to online mode without restoring any logical logs:

• onmode -m

• Start Restore in non-interactive mode

  • ontape -r -d

• Start Restore in interactive mode

  • ontape -r

After the restore your IDS instance will be in quiescent mode, see onstat - output below:

IBM Informix Dynamic Server Version 11.10.FC1DE   -- Quiescent -- Up 00:00:26 -- 54744 Kbytes

You can switch it to online mode by executing:

• onmode -m

You just need to pipe the stored backup data stream in the original format back to the ontape utility:

• Backup stored in a normal file

  • cat $PENGUIN/backups/ontape.l0 | ontape -p -t STDIO

• Backup stored in a gzip file:

  • gzip -d -c $PENGUIN/backups/ontape.l0.gz | ontape -p -t STDIO

After the restore your IDS instance will remain in fast recovery mode. You have two options:

• Perform an additional logical restore

  • ontape -l

or

• Switch the instance to online mode without logical restore

  • onmode -m

dbexport is not a classic backup utility. However many people use it to “backup” a single database in an platform independent format (ASCII).

The dbexport exports the database in ASCII format, hence it is platform and version independent. The utility places an exclusive lock on the database during the export to guarantee consistent data. Hence the database currently exported is not available for other work, it can't be opened by any other session. dbexport can export the database in the filesystem or write the data directly to a tape device.

There are several program options, the most important one is the -ss (server sspecific syntax). This option preserves the locking mode of your tables (page or row) and also preserves the dbspace names where your tables are located. So in most cases you probably want to add the -ss option to your dbexport command.

• Export database stores_demo to the current directory

  • dbexport stores_demo -ss

• Export database stores_demo to directory /tmp

  • dbexport stores_demo -ss -o /tmp

The dbexport utility will create a sub-directory called <database>.exp (in our example stores_demo.exp) in the current directory or in the directory specified thru the -o option. This sub-directory contains:

• SQL file - stores_demo.sql - that contains all necessary commands to create tables, triggers, stored procedures, grant permissions…
• ASCII unload files of all tables

An additional log file named dbexport.out will be written to the current directory.

The below table shows the main differences between the dbexport and the ontape utility:

dbimport imports imports a database that has been exported by the dbexport utility.

As database names must be unique within an IDS instance, a database can only be imported it it doesn't already exist. You can rename an existing database using the rename database SQL statement or you can rename the dbexport directory so that the database will be imported by dbimport under a different name:

1. Rename existing database thru SQL statement:

   • RENAME DATABASE stores_demo TO stores_bak;

2. Rename dbexport directory before importing the database

   • mv stores_demo.exp stores_bak.exp

   • mv stores_bak.exp/stores_demo.sql stores_bak.exp/stores_bak.sql

• Import database stores_demo from the current directory in dbspace datadbs

  • dbimport stores_demo -d datadbs

• Import database stores_demo from directory /tmp in dbspace datadbs

  • dbimport stores_demo -i /tmp -d datadbs

If you don't specify a dbspace thru the -d option, the database will be created in the rootdbs which is not recommended.

Import the database in non-logging mode and switch it after dbimport finished to the desired logging-mode.

Here are some links to additional articles about ontape and onbar that provide you with more detailed information about those powerful IDS backup utilities:

• Daily Backup via DB Scheduler
• New backup and restore features in IBM IDS V10

• Configuring and Implementing an Informix ON-Bar Backup Solution
• Optimize your BAR Performance using parallel backups with IDS
• Informix OnBar and TSM, Part 1
• Informix OnBar and TSM, Part 2

• Data archiving with IDS table-level restore