Deploy Searchable Snapshots in Elasticsearch 7.14: A Complete Step‑by‑Step Guide

Searchable Snapshots Overview

Elasticsearch introduced searchable snapshots in version 7.10, but the feature became production‑ready in 7.14. This guide uses ES 7.14.2 to explain both the underlying principles and practical implementation.

1. DataTier Model

Starting with 7.10, Elasticsearch classifies nodes into tiers: content , hot , warm , cold , and frozen . Each tier has specific workloads and recommended storage media (e.g., SSD for hot, HDD for cold, cheap object storage for frozen).

Content tier – handles catalog‑type indices.

Hot tier – high‑read/write workloads, typically on SSD.

Warm tier – read‑only time‑series data, lower query frequency.

Cold tier – infrequently accessed older data, usually on HDD.

Frozen tier – very low query frequency, data stored in snapshots; only metadata resides on the node.

2. Node Role Optimization

From 7.10 onward, node roles are defined via the node.roles array. Example configurations:

node.roles: ["data_hot","data_content","ingest","ml","remote_cluster_client","transform"]

node.roles: ["master"]

For frozen nodes, set node.roles: ["data_frozen"] to avoid mixing roles.

Index allocation is now controlled with index.routing.allocation.include._tier_preference, a comma‑separated list of preferred tiers. Example for a system index:

index.routing.allocation.include._tier_preference: "data_hot,data_warm,data_cold"

When a node of the first tier in the list is unavailable, Elasticsearch falls back to the next tier.

3. Working Principle

Searchable snapshots can be mounted in two ways:

Fully mounted index – the snapshot data is copied to the cluster; queries behave like a regular index, and damaged shards are automatically restored from the snapshot.

Partially mounted index – only metadata is stored on the node; data remains in the snapshot and is fetched on demand. This mode uses the shared_cache storage type and is ideal for frozen tier nodes with minimal disk usage.

Mounting is performed via the _mount API. Example for partial mount:

POST /_snapshot/default_searchable_snapshot_repository/my_cos_snapshot/_mount?wait_for_completion=true&storage=shared_cache
{
  "index": "wurong-test-2021.11.26-000001",
  "renamed_index": "wurong-test-2021.11.26-000001_from_cos",
  "index_settings": {"index.number_of_replicas": 0},
  "ignore_index_settings": ["index.refresh_interval"]
}

Because frozen nodes store only metadata, queries are slower; Elasticsearch mitigates this with async search, which returns a request ID and delivers results once ready.

POST /sale*/_async_search?size=0
{
  "sort": [{"date": {"order": "asc"}}],
  "aggs": {"sale_date": {"date_histogram": {"field": "date", "calendar_interval": "1d"}}}
}

4. Practical Implementation

Cluster Preparation

Deploy an ES 7.14.2 cluster (enterprise features required). Activate the trial license:

POST /_license/start_trial?acknowledge=true

Create COS Repository

PUT _snapshot/default_searchable_snapshot_repository
{
  "type": "cos",
  "settings": {
    "app_id": "1254139681",
    "access_key_id": "xxxx",
    "access_key_secret": "xxxx",
    "bucket": "wurong-es-snapshpt",
    "region": "ap-guangzhou",
    "compress": true,
    "chunk_size": "500mb",
    "base_path": "/searchable-snapshot"
  }
}

Configure ILM Policy

PUT _ilm/policy/searchable_snapshot_test_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "100mb",
            "max_primary_shard_size": "10mb",
            "max_age": "20m",
            "max_docs": 1000000
          },
          "set_priority": {"priority": 100}
        }
      },
      "cold": {
        "min_age": "1h",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "default_searchable_snapshot_repository",
            "force_merge_index": true
          },
          "set_priority": {"priority": 0},
          "allocate": {"number_of_replicas": 0}
        }
      },
      "frozen": {
        "min_age": "2h",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "default_searchable_snapshot_repository",
            "force_merge_index": true
          }
        }
      }
    }
  }
}

Index Template

PUT _template/searchable_snapshot_test_template
{
  "order": 100,
  "index_patterns": ["wurong-test*"],
  "settings": {
    "index": {
      "lifecycle": {"name": "searchable_snapshot_test_policy", "rollover_alias": "wurong-test"},
      "routing": {"allocation": {"include": {"_tier_preference": "data_hot,data_warm,data_cold"}}},
      "refresh_interval": "30s",
      "number_of_shards": "5",
      "translog": {"sync_interval": "5s", "durability": "async"},
      "max_result_window": "65536",
      "unassigned": {"node_left": {"delayed_timeout": "5m"}},
      "number_of_replicas": "1"
    }
  }
}

Create Initial Index

PUT %3Cwurong-test-%7Bnow%2Fd%7D-000001%3E
{
  "aliases": {"wurong-test": {"is_write_index": true}}
}

Data is continuously written via a load‑testing program. After the index reaches 10 MB or 20 minutes, it rolls over, migrates to the cold tier, and is backed up to COS. After one hour the index is fully mounted; after two hours it is partially mounted on frozen nodes.

Result Verification

Mounted indices appear with the restored‑* prefix (full mount) and partial‑* prefix (partial mount). Full‑mount indices show normal storage size, while partial‑mount indices report zero storage because only metadata resides locally.

Settings of a fully mounted index reveal the tier preference order data_cold,data_warm,data_hot and zero replicas. Settings of a partially mounted index show _tier_preference: data_frozen.

Snapshots created by ILM can be inspected in Kibana under Management → Snapshot and Restore.