KB-2400 How to use archived KDBs to remediate KDB corruption

Purpose

This article describes how to use archived KDB files to restore the engines in the event of KDB corruption. This may be necessary if the live KDB files being used by the engines are corrupted or unusable, and reverting to a backup of the Appian installation is not possible.

One example of a possible scenario where this may be necessary is if the index of each KDB is extremely low, indicating the original KDB files were lost and new KDB files were generated. The index of KDB files can be confirmed by viewing their filenames. This will also be apparent in service_manager.log in lines such as the following.

YYYY-MM-DD HH:MM:SS,mmm [engine-supervisor-groups-0] INFO  com.appian.komodo.engine.Gw1Initializer - kdb files found in …/server/personalization/gw1: [ag3.kdb(Created …, size 1.4 MiB)]

Instructions

Self-Managed Appian on Kubernetes

1. Exec into the Service Manager Pod for the affected engine: kubectl -n <NAMESPACE> exec <POD> -it -- bash
2. Stop the affected engine:./serviceManagerScriptWrapper.sh services/bin/stop.sh -s <ENGINE> (you can see all available values for the -s flag in our documentation)
   1. If the engine is unresponsive, it may be necessary to kill the engine. Identify the PID with ps -ef | grep adb and stop the process with kill -9 <PID>
   2. If it is necessary to skip checkpointing to ensure a new KDB file is not written, add the -q flag
3. Locate the most recent archived KDB for the affected engine. The filename will end with ".kdb.gz": ls -l /usr/local/appian/ae/services/data/archived/<ENGINE>
   1. The archived KDB files can also be located with: find /usr/local/appian/ae -name "*.kdb.gz"
4. Move the archived KDB to the live KDB location: mv /usr/local/appian/ae/services/data/archived/<ENGINE>/<ARCHIVED_KDB> /usr/local/appian/ae/services/data/server/.../gw1
   1. Note that the path of the live KDB location varies depending on the affected engine. You can use find /usr/local/appian/ae -name "*.kdb" to identify the location of the live KDB.
5. Rename (or remove) the corrupt KDB: mv /usr/local/appian/ae/services/data/server/.../gw1/<CORRUPT_KDB> /usr/local/appian/ae/services/data/server/.../gw1/<CORRUPT_KDB>.bkp
6. Uncompress the archived KDB: gzip -d /usr/local/appian/ae/services/data/server/.../gw1/<ARCHIVED_KDB>
7. Restart the affected engine. It will now boot off the archived KDB:  ./serviceManagerScriptWrapper.sh services/bin/start.sh -s <ENGINE>

(Legacy) Self-Managed Appian on Linux

1. Stop the affected engine:  <APPIAN_HOME>/services/bin/stop.sh -s <ENGINE> (you can see all available values for the -s flag in our documentation)
   1. If the engine is unresponsive, it may be necessary to kill the engine. Identify the PID with ps -ef | grep adb and stop the process with kill -9 <PID>
   2. If it is necessary to skip checkpointing to ensure a new KDB file is not written, add the -q flag
2. Locate the most recent archived KDB for the affected engine. The filename will end with ".kdb.gz": ls -l <APPIAN_HOME>/services/data/archived/<ENGINE>
   1. The archived KDB files can also be located with: find <APPIAN_HOME>/services/ -name "*.kdb.gz"
3. Move the archived KDB to the live KDB location: mv <APPIAN_HOME>/services/data/archived/<ENGINE>/<ARCHIVED_KDB> <APPIAN_HOME>/server/.../gw1
   1. Note that the path of the live KDB location varies depending on the affected engine. You can use find <APPIAN_HOME>/server/ -name "*.kdb" to identify the location of the live KDB.
4. Rename (or remove) the corrupt KDB: mv <APPIAN_HOME>/services/data/server/.../gw1/<CORRUPT_KDB> <APPIAN_HOME>/services/data/server/.../gw1/<CORRUPT_KDB>.bkp
5. Uncompress the archived KDB: gzip -d <APPIAN_HOME>/services/data/server/.../gw1/<ARCHIVED_KDB>
6. Restart the affected engine. It will now boot off the archived KDB:  <APPIAN_HOME>/services/bin/start.sh -s <ENGINE>

Affected Versions

This article applies to all self-managed versions of Appian.

Last Reviewed: October 2026