OpenSearch Backup and Restore (Docker Swarm)

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

Backup scope and schedule

The Docker Swarm deployment uses the same OpenSearch backup archive prefix and the same ActiveAlerts-only scope as the Kubernetes deployment.

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

Verify the scheduled backup service and inspect its logs from a Swarm manager:

docker service ps aod_ofelia
docker service logs aod_ofelia

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 data volume and do not manually delete OpenSearch data directories.

Locate the restore helper script

The deployment installs the restore helper on the Swarm leader host. Run it from the Swarm leader with sufficient privileges.

List available backups

sudo /etc/aod/scripts/opensearch-restore-swarm.sh --list-only

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.

sudo /etc/aod/scripts/opensearch-restore-swarm.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.

A same-name restore requires explicit confirmation:

sudo /etc/aod/scripts/opensearch-restore-swarm.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 data 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.

Related Topics

• OpenSearch Backup and Restore (Kubernetes)
• Elasticsearch Backup and Restore (until deployments migrate)