Searchable Snapshots in Elasticsearch 7.10: Features, Usage, and Future Outlook

Elasticsearch 7.10 introduces a major feature called Searchable Snapshots , which allows snapshots stored in remote repositories such as S3, HDFS, or Tencent Cloud COS to be queried directly, significantly reducing storage costs.

Before this feature, snapshots created via the _snapshot API could only be used for cold backup. To query data, the snapshot had to be restored to the cluster, initializing the index before it became searchable.

Searchable Snapshots decouple storage from compute by enabling queries on data that remains in remote storage. This is especially beneficial for large, infrequently accessed log indices, where storage cost is a primary concern.

Key Benefits

Potentially halves storage costs by keeping older indices in cheap object storage.

Maintains query performance comparable to local indices after the snapshot is mounted.

Reduces the need for additional replica shards, as reliability is handled by the remote repository.

1. Manual Mounting of a Snapshot

POST /_snapshot/my_repository/my_snapshot/_mount?wait_for_completion=true
{
  "index": "test",
  "renamed_index": "test1",
  "index_settings": {
    "index.number_of_replicas": 0
  },
  "ignored_index_settings": [ "index.refresh_interval" ]
}

This request mounts the test index from my_snapshot as test1 , sets the replica count to 0, and ignores the index.refresh_interval setting.

After mounting, the new index appears in a yellow state, then transitions to green once initialization completes.

The settings of the mounted index differ from a regular index:

{
    "test1":{
        "settings":{
            "index": {
                "blocks":{
                    "write":"true"
                },
                "recovery":{
                    "type":"snapshot_prewarm"
                },
                "store":{
                    "type":"snapshot",
                    "snapshot":{
                        "snapshot_name":"test",
                        "index_uuid":"p1Opq7gdQz6WTeKgiIEaTw",
                        "index_name":"test-aggregation-2020-11-25-02",
                        "repository_name":"my_repository2",
                        "snapshot_uuid":"Muy7vsiLSWKbQf3mJALfLw"
                    }
                }
            }
        }
    }
}

index.blocks.write is true, making the snapshot index read‑only.

index.recovery.type is snapshot_prewarm , indicating data is restored from a snapshot.

index.store.type is snapshot , different from the usual fs storage.

2. Using Searchable Snapshots in ILM

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "cold": {
        "actions": {
          "searchable_snapshot" : {
            "snapshot_repository" : "my_repository",
            "force_merge_index": true
          }
        }
      }
    }
  }
}

When an index follows this ILM policy, it is first backed up to my_repository during the cold phase, then mounted as a searchable snapshot.

Important ILM considerations:

Searchable snapshots can only be used in the cold phase.

If a delete phase is defined, set delete_searchable_snapshot to false to keep the snapshot.

By default, force_merge_index is true, reducing the number of segments and thus storage and retrieval costs.

Future Outlook

In the current beta, snapshots still need to be cached locally, limiting storage savings. The roadmap aims for full storage‑compute separation, allowing direct queries on data stored in S3/COS without local caching, especially in a future “Frozen” tier.

Combining searchable snapshots with the Data Tiers feature will enable truly elastic clusters that can store petabytes of data while keeping costs low.