OpenSearch Backup and Restore (Kubernetes)

This article describes how to create and verify backups for the OpenSearch 2.19.5 service used by Crosswork Assurance deployments on Kubernetes, and how to request a restore.

Backup scope and schedule

OpenSearch creates a backup daily at 02:30 UTC. The scheduled Kubernetes job is named backup-create-opensearch.

Backups contain the ActiveAlerts indexes only (*_active_alerts). The product does not support using this backup or the Elasticsearch-to-OpenSearch migration to carry over other Elasticsearch indexes.

The backup is stored as a compressed archive in the configured object-storage bucket under this prefix:

opensearch/v2/opensearch-Backup/

Each archive name includes the backup timestamp, for example:

2026-07-22_02-30-00.tar.gz

Verify the scheduled backup

Use the following commands from a workstation with kubectl access to the deployment. Replace pca if your deployment uses a different namespace.

kubectl get cronjob -n pca backup-create-opensearch
kubectl get jobs -n pca --sort-by=.metadata.creationTimestamp

To review the result of a completed backup job, first identify its job name and then view its logs:

kubectl logs -n pca job/<backup-job-name>

The job is successful when it completes without errors and the backup archive is present in the configured object-storage bucket.

Create a manual backup

Create a one-time job from the scheduled OpenSearch backup job when you need a backup before maintenance or an upgrade:

JOB="manual-opensearch-backup-$(date +%Y%m%d%H%M%S)"
kubectl create job -n pca --from=cronjob/backup-create-opensearch "$JOB"
kubectl wait -n pca --for=condition=complete --timeout=3600s "job/$JOB"
kubectl logs -n pca "job/$JOB"

Use your organization's approved object-storage client, such as MinIO Client (mc), to find the resulting archive. For example:

mc --insecure ls pca/<backup-bucket>/opensearch/v2/opensearch-Backup/

Replace pca and <backup-bucket> with the alias and bucket configured for your deployment. Record the complete archive name before beginning a restore.

Restore an OpenSearch backup

Restoring replaces or adds search indexes, so perform this procedure during an approved maintenance window. Do not copy an archive directly into an OpenSearch persistent volume and do not manually delete OpenSearch data directories.

Locate the restore helper scripts

The deployment creates the opensearch-backup-restore-operator-scripts ConfigMap in the PCA namespace. Extract the standalone scripts to a workstation that has kubectl access:

HELPER_DIR="$(mktemp -d)"
kubectl -n pca get configmap opensearch-backup-restore-operator-scripts \
  -o jsonpath='{.data.list-opensearch-object-backups-kubernetes\.sh}' \
  > "$HELPER_DIR/list-opensearch-object-backups-kubernetes.sh"
kubectl -n pca get configmap opensearch-backup-restore-operator-scripts \
  -o jsonpath='{.data.opensearch-restore-kubernetes\.sh}' \
  > "$HELPER_DIR/opensearch-restore-kubernetes.sh"
chmod 0755 "$HELPER_DIR"/*.sh

List available backups

bash "$HELPER_DIR/list-opensearch-object-backups-kubernetes.sh"

Run the restore helper

By default, the helper restores *_active_alerts under temporary validation index names. This validates that the archive can be restored without replacing the live ActiveAlerts indexes. Review the helper output and complete the validation before requesting a same-name restore.

bash "$HELPER_DIR/opensearch-restore-kubernetes.sh" --archive <backup-timestamp>.tar.gz

Warning: A same-name restore can replace live ActiveAlerts data. Use it only when the maintenance plan calls for replacement and after the validation restore succeeds.

The restore helper requires explicit confirmation for a same-name restore:

bash "$HELPER_DIR/opensearch-restore-kubernetes.sh" \
  --archive <backup-timestamp>.tar.gz \
  --same-name \
  --confirm-same-name

The restore helper retrieves the archive from the configured object-storage location, prepares the OpenSearch snapshot repository, and restores the supported ActiveAlerts indexes. Follow the helper's completion status and verify that ActiveAlerts data is available before ending the maintenance window.

Before closing the maintenance window

Verify that ActiveAlerts data is visible in the Crosswork Assurance UI before ending the maintenance window. If ActiveAlerts data is missing or incorrect, keep the maintenance window open and continue working with TAC.

Warning: Do not copy an archive directly into an OpenSearch persistent volume and do not manually delete OpenSearch data directories.

Elasticsearch-to-OpenSearch migration note

During the supported Elasticsearch-to-OpenSearch migration, only the ActiveAlerts indexes (*_active_alerts) are migrated. Other Elasticsearch indexes are not carried forward by the product migration path. Plan any retention, export, or replacement requirements for other Elasticsearch data separately.

Documentation Index