Elasticsearch Snapshots and Backup

Replicas protect against a failed machine. They do not protect against a mistaken delete command, a corrupted deployment, or a lost data center. A delete request removes the document from every copy at once. Snapshots fill the gap. A snapshot is a backup stored outside the cluster, and it can restore data to a past moment.

  Replicas                          Snapshots
  ─────────────────────────         ─────────────────────────
  Copy inside the cluster           Copy outside the cluster
  Survives one node failing         Survives losing everything
  Mirrors deletes instantly         Keeps data from a past moment

How Snapshots Work

The first snapshot copies all index files. Later snapshots copy only the new or changed segment files, so they finish quickly and use little extra space. Each snapshot still behaves like a complete backup, because it references every file it needs.

Snapshot 1 (Monday):    [A] [B] [C]             → uploads 3 files
Snapshot 2 (Tuesday):   [A] [B] [C] [D]         → uploads 1 new file
Snapshot 3 (Wednesday): [A] [B] [C] [D] [E]     → uploads 1 new file

Repository stores: A B C D E   (each file kept once)

Step 1: Register a Repository

A repository tells Elasticsearch where backups live. Options include a shared file system, Amazon S3, Google Cloud Storage, and Azure Blob Storage. The file system type requires a path listed in elasticsearch.yml on every node.

In elasticsearch.yml (all nodes):
  path.repo: ["/mnt/es_backups"]

Register the repository:
PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/mnt/es_backups/main"
  }
}

Verify access from every node:
POST /_snapshot/my_backup/_verify

Cloud repositories use the type s3, gcs, or azure, with credentials stored in the Elasticsearch keystore rather than in plain settings.

Step 2: Take a Snapshot

PUT /_snapshot/my_backup/snapshot_2026_11_04?wait_for_completion=false
{
  "indices": "products,orders",
  "include_global_state": false
}

Leave out the "indices" setting to back up every index. Setting wait_for_completion to false returns immediately, and the snapshot runs in the background.

Step 3: Check Status

GET /_snapshot/my_backup/snapshot_2026_11_04
GET /_snapshot/my_backup/_all
GET /_snapshot/my_backup/snapshot_2026_11_04/_status

The state field reads IN_PROGRESS, SUCCESS, PARTIAL, or FAILED. A PARTIAL state signals that some shards did not finish, so inspect the failure list before trusting that backup.

Restoring Data

A restore recreates indexes from a snapshot. An existing open index with the same name blocks the restore. Rename the restored index, or delete the damaged one first.

POST /_snapshot/my_backup/snapshot_2026_11_04/_restore
{
  "indices": "products",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored_$1"
}

Snapshot contains:  products
Restore result:     restored_products   (original "products" untouched)

Compare data, then reindex or swap an alias to switch over.

Automating Backups with SLM

Snapshot Lifecycle Management (SLM) schedules snapshots and cleans old ones. A cron expression sets the time, and a retention block sets how many copies to keep.

PUT /_slm/policy/nightly
{
  "schedule": "0 30 1 * * ?",
  "name": "<nightly-{now/d}>",
  "repository": "my_backup",
  "config": { "indices": ["*"] },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

POST /_slm/policy/nightly/_execute

The schedule above runs at 1:30 AM every day. The execute call triggers an immediate run, which proves the policy works before the first night arrives.

What a Snapshot Includes

Content	Included by Default	Note
Index data and mappings	Yes	Chosen by the indices setting
Cluster settings and templates	Only with include_global_state	Turn on for full cluster recovery
Feature state (security, Kibana)	Controlled by feature_states	Review for system indexes
Elasticsearch binaries and config files	No	Back up these separately

Backup Habits That Save Projects

Keep the repository on storage that is independent of the cluster, ideally in another location. Take snapshots on a regular schedule that matches how much data loss the business can accept. Practice a restore into a test cluster every few months. An untested backup gives false comfort, and the practice run reveals missing permissions and slow steps before an emergency does.

Habit	Reason
Store backups off-cluster	Survives total cluster loss
Schedule with SLM	Removes human forgetfulness
Set retention limits	Controls storage cost
Test restores	Proves backups work
Monitor snapshot state	Catches PARTIAL and FAILED runs

Securing the Repository

Backups contain the same sensitive data as the live cluster. Restrict access to the repository location with the same care as the cluster itself. Cloud storage buckets need private access settings, limited credentials, and optional encryption at rest. Give the snapshot account only the permissions it needs, and avoid sharing the credentials with application servers.