How to restore Elasticsearch snapshots

Restoring an Elasticsearch snapshot is the supported way to recover index data after accidental deletion, corruption, or a failed migration, because it rebuilds the missing shards from the repository copy instead of trying to salvage node-local storage.

A restore request reads snapshot metadata from a registered snapshot repository, recreates the selected shards, and runs shard recovery until the restored primaries are available again for search and indexing. The repository must already be registered on the target cluster, and the snapshot, cluster, and restored index versions must still be compatible.

Current Elasticsearch releases reopen restored indices automatically after recovery completes, so a separate _open request is not part of the normal workflow. An open index with the same name blocks an in-place restore, and the existing closed index must still match the snapshot's primary shard count. Keep include_global_state set to false unless the goal is to roll back cluster metadata such as templates, ingest pipelines, and persistent settings. For data streams, ensure the target cluster already has a matching data-stream-enabled index template before starting the restore.

1. List the snapshots in the repository before choosing a restore point.

   $ curl -sS --fail "http://localhost:9200/_cat/snapshots/local_fs?v"
   id                   repository  status start_epoch start_time end_epoch  end_time duration indices successful_shards failed_shards total_shards
   snapshot-restore-001 local_fs   SUCCESS 1775118668  08:31:08   1775118668 08:31:08    201ms       1                 1             0            1

   CAT snapshot output is intended for operator checks in the terminal. Use the get snapshot API in the next step when the restore decision depends on the exact snapshot contents.

   On secured clusters, switch the endpoint to https:// and add authentication such as --user elastic:password or an ApiKey header.

   Related: How to create and manage Elasticsearch snapshots

2. Inspect the chosen snapshot to confirm the indices, data streams, and cluster-state scope.

   $ curl -sS --fail "http://localhost:9200/_snapshot/local_fs/snapshot-restore-001?pretty&filter_path=snapshots.snapshot,snapshots.indices,snapshots.data_streams,snapshots.include_global_state,snapshots.feature_states,snapshots.state"
   {
     "snapshots" : [
       {
         "snapshot" : "snapshot-restore-001",
         "indices" : [
           "logs-2026.04"
         ],
         "data_streams" : [ ],
         "include_global_state" : false,
         "state" : "SUCCESS",
         "feature_states" : [ ]
       }
     ]
   }

   The get snapshot API is the exact source of snapshot contents. If the expected index is missing here, it was not captured in that snapshot. When feature_states is non-empty, restoring system data requires the matching feature-state workflow.

3. Check whether an index with the target name already exists.

   $ curl -sS -o /dev/null -w "%{http_code}\n" "http://localhost:9200/logs-2026.04"
   200

   A response of 200 indicates the index exists, while 404 indicates no index exists to close.

4. Close the target index if it already exists.

   $ curl -sS --fail -X POST "http://localhost:9200/logs-2026.04/_close?pretty"
   {
     "acknowledged" : true,
     "shards_acknowledged" : true,
     "indices" : {
       "logs-2026.04" : {
         "closed" : true
       }
     }
   }

   Elastic's current restore rules still require the existing closed index to have the same number of primary shards as the snapshot. If the current index must stay online, restore under a new name with rename_pattern and rename_replacement instead.

5. Start the restore request for the required indices.

   $ curl -sS --fail -H "Content-Type: application/json" -X POST "http://localhost:9200/_snapshot/local_fs/snapshot-restore-001/_restore?pretty" -d '{
     "indices": "logs-2026.04",
     "include_global_state": false
   }'
   {
     "accepted" : true
   }

   Leaving include_global_state at true can roll back persistent cluster settings, templates, ingest pipelines, and other stack metadata that may affect unrelated workloads.

   Restore requests run asynchronously by default. Add wait_for_completion=true only when the restore is small enough that the client can block until recovery finishes.

6. Monitor shard recovery until the restore stage reaches done.

   $ curl -sS --fail "http://localhost:9200/_cat/recovery/logs-2026.04?v&h=index,shard,type,stage,repository,snapshot,files_percent,bytes_percent"
   index        shard type     stage repository snapshot             files_percent bytes_percent
   logs-2026.04 0     snapshot done  local_fs   snapshot-restore-001 100.0%        100.0%

   The CAT recovery API is convenient for operator checks. For automation or deeper detail, use the index recovery API at GET /logs-2026.04/_recovery.

   Related: How to monitor Elasticsearch cluster health
   Related: How to monitor shard recovery in Elasticsearch

7. Verify the restored index is open and the documents are searchable.

   $ curl -sS --fail "http://localhost:9200/_cat/indices/logs-2026.04?v&h=health,status,index,pri,rep,docs.count,store.size"
   health status index        pri rep docs.count store.size
   green  open   logs-2026.04   1   0          1      5.9kb
   
   $ curl -sS --fail "http://localhost:9200/logs-2026.04/_count?pretty"
   {
     "count" : 1,
     "_shards" : {
       "total" : 1,
       "successful" : 1,
       "skipped" : 0,
       "failed" : 0
     }
   }

   Current restore behavior reopens restored indices automatically when recovery succeeds, so a separate _open request is not required in the normal flow.