This page details how to execute and restore from Full System Backups of installations of Appian on Kubernetes.
A full system backup is a backup of all Appian application and external data taken when Appian is stopped. A full system backup is appropriate when upgrading Appian, both when upgrading between quarterly versions and when upgrading to a newer hotfix. Full system backups can also be executed periodically in order to capture the state of an Appian installation should a catastrophic failure occur that requires a full system restoration.
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 should be configured instead. For low RPO requirements in the face of other extended, catastrophic failures, Cold Failover should be configured instead.
If necessary, backup your Appian custom resource:
1
kubectl -n <NAMESPACE> get appian <NAME> -oyaml
Make sure to also backup any secrets referenced by its *SecretName and *SecretKeyRef fields:
.spec.k3LicSecretName.spec.k4LicSecretName.spec.webapp.dataSources.primary.passwordSecretKeyRef.spec.webapp.dataSources.business[].passwordSecretKeyRef.spec.webapp.passwordsPropertiesSecretNameFor 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 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 the aforementioned features. Examples include:
Backup your Appian installation's Appian data source, its business data sources, and any external RDBMSs.
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.
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. 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 the aforementioned features. Examples include:
Restore the corresponding backup of your Appian installation's Appian data source, its business data sources, and any external RDBMSs.
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.passwordsPropertiesSecretNameNote: If necessary, pull or re-pull the appropriate Appian container images and push them to your organization's registry.
