This topic outlines the backup process for Appian documents and data.
The main reasons for backing up Appian installations and related data are for data archival and auditing purposes and as a protection against catastrophic events. The frequency of conducting backups depends on the use case.
For data archival and auditing purposes, backing up weekly or even monthly may be sufficient. Using backups to preserve data when a catastrophic event occurs requires more frequent backups that ultimately depend on how much data you are willing to lose when restoring the data. If you back up nightly, the most data you might lose is one day's worth. This concept is referred to as the Recovery Point Objective (RPO).
While backups are an approach to achieving an RPO on the order of hours, it is not the preferred method for achieving very low RPOs (minutes). Instead, the High Availability configuration should be used for disaster recovery with low RPO requirements.
There are two primary data components that should be backed up:
Each of these components is backed up separately, yet all backups must occur simultaneously so that data can be restored in a consistent state. When scheduling a script to backup the Appian data, external databases must be backed up at the same time. This ensures that during recovery the system's data snapshot is synchronized and consistent. Otherwise, you might encounter synchronization issues.
Application data comprises files stored on the server that are referenced by Appian engines, including documents stored in the document management system, archived processes, search indices, the keystore file, data in the data server, and other data files. The folders containing this application data should be backed up at the same time.
All external data sources used with Appian must be backed up separately and simultaneously. Use your preferred backup mechanism for the specific RDBMS used in the Appian environment.
There are two types of backups:
A full system backup is appropriate when upgrading Appian or applying a patch/hotfix. Full system backups can also be run periodically (perhaps monthly) in order to capture a snapshot of the state of the server(s) should a catastrophe strike that requires a full system restoration.
A live data backup is appropriate in order to frequently capture the state of the application data in order to provide rapid restoration of a previous state in case of a failure. While not sufficient for low recovery time objective (RTO) use cases, it can be used for a hot/cold restoration scenario where an RPO on the order of minutes is desirable.
On This Page