Updated June 2020

New related features regarding Informix storage and backup encryption are available in IDS 14.10 and described in other Oninit articles.


GDPR is causing many companies to revise their policies regarding data privacy, and encrypting data may help meet some of the requirements. Fortunately, storage space (dbspace) encryption (otherwise known as “Encryption at rest” or EAR) is a very easy-to-use feature available in all Informix Dynamic Server (IDS) editions since version 12.10.xC8. No application changes are required.

This should be combined with encryption of backups – both archives and logical logs – whether created via “onbar” or “ontape”:

  1. Prior to IDS 10, this had to be performed after backup files had been created.
  2. IDS 10 allowed backup or restore via any pipe with “ontape -t STDIO”, but only for archives.
  3. From IDS 11, configuration parameters exist to pass all backups and restores through specified filter commands, which is ideal for in-line compression and encryption.

This article explains the steps involved in implementing both storage and backup encryption (using method 3 above) on supported IDS versions.


All commands shown below should be run as user “informix”.

For storage encryption, first make sure that the IBM Global Security Kit (GSKit) is set up. For example, the installer is present but not yet run in either of these free Docker images:



You can fix that with:

Copy to Clipboard

It doesn’t seem to cause any harm if the above is repeated unnecessarily. Note that the installed GSKit location varies with platform, for example:

Linux: /usr/local/ibm/gsk8_64     AIX: /usr/opt/ibm/gsk8_64

Next, you need to add a line such as this to the $INFORMIXDIR/etc/$ONCONFIG file:

Copy to Clipboard

The exact line above is recommended which automatically handles multiple instances. For example, if the Informix server name is “test”, the following files will be created automatically in the same directory:

Copy to Clipboard

There are other options that can be appended, but none of them essential:


The default cipher is 128-bit AES.

If the above is in place before you first initialize an instance for the first time with “oninit -iv”, all dbspaces will be encrypted from the outset.

If you wish to encrypt all dbspaces for an existing instance, set up the above and then perform a level 0 archive, stop the instance, and restore it again specifying encryption. For example, using “ontape” with a directory in configuration parameter TAPEDEV, these are the necessary commands:

Copy to Clipboard

Note that, should you need to perform a cold restore of a previously encrypted instance, it will fail unless the key files are removed beforehand with:

Copy to Clipboard

Should you wish to have only some dbspaces encrypted, this can be achieved by using the “onspaces” command to create individual dbspaces with or without the “-u” (unencrypted) option, for example:

Copy to Clipboard


You can check which dbspaces are encrypted with “onstat -d”, which shows “E” in the “flags” column where applicable (whereas “E” would mean “expandable” in the second “Chunks” list):

Copy to Clipboard


Backup encryption is equally straightforward. This article assumes the use of “openssl” as it is the most portable tool, for example it’s available as standard on both Linux and AIX. The main alternative on Linux is “pgp”, but no binary installer exists at this time for AIX 7.

We first need to create a file in a secure location containing the encryption password on one line:

Copy to Clipboard

The contents entered with “vi” above could be 128 bytes randomly generated here:


Next, create a filter script with two names as follows:

Copy to Clipboard

The shell script contents entered with “vi” above could be as follows:

Copy to Clipboard

Finally, set configuration parameters to use the above automatically:

Copy to Clipboard

The new settings entered with “vi” above should be:

Copy to Clipboard

The solution above assumes that, as well as encryption, “gzip” compression is desired, as it often is.

On later versions of “openssl”, you may find the “-z” option is supported which similarly performs compression with the “zlib” library. This would reduce the number of processes and in theory make it possible to do without the shell script.

Otherwise, pipe symbols in BACKUP_FILTER or RESTORE_FILTER cause the operation to fail, even if quoted as documented, so there is no choice but to have a script. There are in any case other advantages, such as having the cipher details and password location defined once, and the latter not accessible to other users with “ps -f”.

On larger systems with many CPU cores, consider compiling and using the much faster multi-threaded implementation of “gzip” available here:


The cipher chosen in the filter script is 128-bit AES (the same as the DISK_ENCRYPTION default). It uses around 10% of the CPU used by “gzip” during a backup and 50% during a restore. You could go up to 256-bit with a modest performance penalty.


You obviously need to copy encryption key files from $INFORMIXDIR/etc to another secure location any time they change. Otherwise:

  • If the disk encryption key files (*.p12 and *.stm) were lost, Informix would stay running as the keys are cached, but you would be unable to restart the instance without a full restore.
  • If the backup encryption key file (.openssl/*) was lost, you could recreate it with new contents, but you would not be able to restore from previous backups.

Beware that setting BACKUP_FILTER and RESTORE_FILTER for whatever purpose causes the “archecker” and “onlog” tools to fail prior to IDS 11.50.xC7W1 due to defects such as:

IC68956  Reading of archived logical logs using the onlog utility does not work if BACKUP_FILTER /usr/bin/gzip is used


Assuming a small CPU overhead is acceptable, there is every reason to implement storage and backup encryption if your databases contain personal or sensitive data. Everything you need to know is given in this article, and it’s not that difficult to implement.


Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.

Contact us

If you have any questions regarding Informix storage and backup encryption, or would like to find out more, simply contact us.