Free cookie consent management tool by TermsFeed

Backups

On This Page

This page provides detailed procedures for executing and restoring system backups for Appian on Kubernetes installations.

What is a full system backup?

A full system backup captures all Appian application and external data and is taken while the Appian site is stopped.

Why take backups?

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).

Backups can achieve an RPO on the order of hours, but not the very low RPOs, measured in minutes, that some disaster recovery scenarios require.

When to take backups

A full system backup is appropriate in two situations:

  • Upgrades: Take a full system backup when upgrading Appian, both when upgrading between quarterly versions and when upgrading to a newer hotfix.
  • Periodic snapshots: Take a full system backup periodically to capture the state of an Appian installation, so you can perform a full system restoration if a catastrophic failure occurs.

Note:  Full system backups require stopping Appian and are therefore not suited for low recovery point objective (RPO) requirements. For low RPO requirements in the face of pod, node, or zone failure, High Availability must be configured instead. For low RPO requirements in the face of other extended, catastrophic failures, Cold Failover must be configured instead.

Data components

There are two primary data components that must be backed up:

  • Appian application data (documents, archived processes, and other files): 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, data managed by the data service, and other data files. The folders containing this application data must be backed up at the same time.
  • External data: 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.

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 back up 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.

Execute a full system backup

To execute a full system backup, complete the following steps.

Step 1: Back up the Appian custom resource and referenced resources

Back up your Appian custom resource and any referenced secrets:

  1. Back up your Appian custom resource by running the following command: 
    1

    kubectl -n <NAMESPACE> get appian <NAME> -oyaml
  2. Also back up any secrets referenced by the following fields:
    • .spec.k3LicSecretName
    • .spec.k4LicSecretName
    • .spec.webapp.dataSources.primary.passwordSecretKeyRef
    • .spec.webapp.dataSources.business[].passwordSecretKeyRef
    • .spec.webapp.passwordsPropertiesSecretName

Step 2: Stop Appian

See Stopping the Appian site.

Step 3: Back up Appian application data

For installations of Appian on Kubernetes, Appian's application data is stored in persistent volumes. This includes both stateful components' per-pod persistent volumes and ReadWriteMany persistent volumes for High Availability and Health Check, if applicable.

How to backup an Appian installation's persistent volumes depends on the volume plugins and storage systems being used. Many out-of-tree Container Storage Interface (CSI) volume plugins support Volume Snapshots and/or CSI Volume Cloning. You may also elect to create snapshots/clones via your storage system. There are also a variety of products in the Kubernetes ecosystem built to help with backing up and restoring persistent volumes, many of which build on top of Volume Snapshots and CSI Volume Cloning. Examples include:

Step 4: Back up external data

Back up your Appian installation's Appian data source, its business data sources, and any external RDBMSs.

Restore from a full system backup

To restore from a full system backup, complete the following steps.

Step 1: Stop Appian and execute a full system backup

If an installation of Appian on Kubernetes with your same namespace and name is already running, stop it and execute a full system backup. If persistent volume claims matching your installation of Appian on Kubernetes already exist and haven't been backed up, back them up.

Step 2: Restore Appian application data

If persistent volume claims matching your installation of Appian on Kubernetes already exist, delete them.

Caution:  Make sure to only delete persistent volume claims matching your installation of Appian on Kubernetes. Accidental deletion of other persistent volume claims may result in other installations/applications experiencing irrecoverable data loss.

Restore the backup of your Appian installation's persistent volumes / persistent volume claims. How to restore an Appian installation's persistent volumes / persistent volume claims depends on how they were backed up and the volume plugins and storage systems being used. Volume Snapshots supports creating persistent volume claims from volume snapshots. Container Storage Interface (CSI) Volume Cloning can be reversed. You may also elect to restore via your storage system and/or via statically provisioning and reserving persistent volumes. There are also a variety of products in the Kubernetes ecosystem built to help with backing up and restoring persistent volumes, many of which build on top of Volume Snapshots and CSI Volume Cloning. Examples include:

Step 3: Restore external data

Restore the corresponding backup of your Appian installation's Appian data source, its business data sources, and any external RDBMSs.

Step 4: Restore referenced resources

If necessary, restore any secrets referenced by your Appian custom resource's *SecretName and *SecretKeyRef fields:

  • .spec.k3LicSecretName
  • .spec.k4LicSecretName
  • .spec.webapp.dataSources.primary.passwordSecretKeyRef
  • .spec.webapp.dataSources.business[].passwordSecretKeyRef
  • .spec.webapp.passwordsPropertiesSecretName

Step 5: Start Appian

Note:  If necessary, pull or re-pull the appropriate Appian container images and push them to your organization's registry.

See Restarting the Appian site.

Step 6 (Optional): Update Process HQ processes

If your organization uses Process HQ, all processes in Process HQ require a manual update before they are usable after an environment restoration.

Feedback