Skip to content

Back up and restore

Elasticsearch snapshots store data and supported cluster state in an off-cluster repository. Azure storage access can be provisioned for snapshots, but do not assume that a repository, schedule, retention rule, or restore test is active until you verify it.

Azure snapshot and restore flow showing a recovery owner, source Elasticsearch cluster, Azure snapshot repository, supported restore action, restored indices and state, and customer validation.

A restore is complete only after the customer validates recovered data, security, integrations, and application behavior.

Verify backup readiness

  1. In Kibana, use navigation search to open Snapshot and Restore.
  2. Confirm that the approved repository is registered and reachable.
  3. Review Snapshot Lifecycle Management policies.
  4. Confirm the last successful snapshot and its included data.
  5. Compare retention and frequency with the approved recovery objectives.
  6. Record the last restore-test date.

Create an on-demand snapshot

Before a high-risk change, create a snapshot through Kibana or the approved Elasticsearch API. Give it a descriptive, non-sensitive name. Wait for success and confirm that failed or partial shards are not being overlooked.

Plan a restore

  1. Identify the exact snapshot and indices or feature state to restore.
  2. Review version compatibility and name conflicts.
  3. Confirm the required cluster and repository privileges.
  4. Define the effect on current data, writes, aliases, and clients.
  5. Obtain change approval and a maintenance window.
  6. Restore into a non-production target first when possible.
  7. Validate document counts, searches, Kibana objects, permissions, and application behavior.

Snapshots are not copies of Azure managed infrastructure. Coordinate a full-service recovery with iVedha.

See Elastic snapshot and restore for product behavior and compatibility requirements.