To understand why searchable snapshots exist, first look at what happens to a busy Elasticsearch cluster over time.

Logs, metrics, and events pile up

Elasticsearch is very often used to store time-based data: application logs, security events, website clicks, sensor readings, payment traces. Every second, more of it arrives. A modest company can create hundreds of gigabytes a day, and a large one can create tens of terabytes a day. Nobody deletes this data on a whim, because it has value long after the day it was created.

Auditors may require you to keep records for one, three, or seven years. Security teams need to look back months to find out when an attacker first entered the network. Engineers want to compare this month’s traffic with the same month last year. So the data stays, and the cluster grows.

Why keeping it in the normal way is so expensive

A normal Elasticsearch index lives on the local disks of data nodes. To keep it safe, you usually keep at least one replica, which is a full second copy on a different node. That means every gigabyte of data costs you two gigabytes of fast disk. On top of the disk, each node needs memory and CPU to keep the shards healthy, even if nobody ever searches them.

Fast local disks are also the most expensive kind of storage in most environments. You are paying premium prices to store data that is, in practice, almost never read. That is the mismatch searchable snapshots are designed to remove.

Data gets colder as it gets older

The most important observation behind the whole feature is that data has a temperature. Fresh data is hot: it is written constantly, searched constantly, and shown on dashboards that refresh every few seconds. A month later it is warm, because people only look at it when they investigate something. A year later it is cold, and searches against it are rare and usually planned.

Searchable snapshots combine four older ideas. If you are comfortable with each one, the rest of this guide becomes much easier.

Indices, shards, and Lucene segments

An Elasticsearch index is a named collection of documents. To spread work across machines, an index is cut into shards. Each shard is really a small, complete search engine built on a library called Lucene. Lucene stores its data in files called segments.

Here is the detail that makes everything else possible: a Lucene segment is immutable. Once it is written, it is never changed. New documents go into new segments. Deleted documents are only marked as deleted, and a background merge later builds a fresh, bigger segment and discards the old ones. Immutable files are easy to copy, easy to check, and safe to store somewhere else.

Snapshots and repositories

A snapshot is a backup of one or more indices, taken from a running cluster without stopping it. It is stored in a snapshot repository, which is usually an object store such as Amazon S3, Google Cloud Storage, or Azure Blob Storage. It can also be a shared file system.

Snapshots are incremental. Because segments never change, the second snapshot only needs to upload segments that did not exist in the first one. Segments that already exist in the repository are simply referenced again. This makes regular snapshots cheap in both time and storage.

Object storage

Object storage is a service that stores files (“objects”) in flat containers (“buckets”). It is extremely cheap per gigabyte, very durable, and effectively unlimited in size. The trade-off is that every read is a network call with noticeably higher delay than reading a local disk, and most providers charge a small fee per request and per gigabyte transferred out.

Data tiers

Elasticsearch lets you assign nodes to roles that describe the temperature of the data they hold. These are called data tiers, and index lifecycle management can move an index from one tier to the next automatically.

flowchart LR
  A[Hot tier] --> B[Warm tier]
  B --> C[Cold tier]
  C --> D[Frozen tier]
  D --> E[Delete]
        

Older versions also offered a separate “freeze index” feature that made indices cheaper by limiting their memory use. That approach was replaced by the frozen tier built on searchable snapshots, which handles the same goal far better.

A searchable snapshot is a snapshot that you can search directly, without first restoring it in the ordinary way.

The short definition

Normally, a snapshot is a sleeping backup. To read the data inside, you must restore the snapshot into a regular index, which means copying every file back onto local disks. A searchable snapshot changes the relationship. You mount the snapshot as an index, and Elasticsearch reads the data from the snapshot itself, treating the repository as the real storage layer. The index looks and behaves like any other index when you search it.

The crucial shift in thinking is this: the snapshot stops being a spare copy and becomes the primary copy of record. Local disks hold either a full working copy (in the cold tier) or only a cache of the parts that were recently used (in the frozen tier). That is why the data is so much cheaper to keep.

Mounting: the action that makes it searchable

Mounting is done through a mount operation on a snapshot, or automatically by an index lifecycle policy. The result is a new index whose settings say “my data lives in this snapshot in that repository”. Elasticsearch then allocates the shards of that index to suitable nodes, and those nodes are set up to read data from the repository as needed.

The two ways to mount

In the API, these two options are known as the full copy and the shared cache storage types. Indices mounted fully get a name starting with restored- when created by lifecycle management, and indices mounted partially get a name starting with partial-. Seeing those prefixes in your index list is the quickest way to spot what is what.

flowchart TD
  S[Snapshot in object storage] --> M{How is it mounted}
  M -->|Full copy| F[Fully mounted index on cold nodes]
  M -->|Shared cache| P[Partially mounted index on frozen nodes]
  F --> L1[All files on local disk]
  P --> L2[Only recently used pieces cached locally]
        

What you can and cannot do with a mounted index

A searchable snapshot index is read-only. You can search it, aggregate over it, filter it, and visualize it. You cannot index new documents into it, update or delete individual documents, or force-merge it. This restriction is natural, because the data files belong to an immutable snapshot and cannot be edited in place.

Licensing and history

Searchable snapshots arrived in the 7.x series as a preview and matured into a supported feature, with the frozen tier and partial mounting following soon after. They require an Enterprise-level subscription (or an active trial). Because features and defaults evolve between releases, always confirm the details against the documentation of the exact version you run.

A searchable snapshot setup is a small team of cooperating parts. Knowing each one makes troubleshooting far easier.

flowchart TD
  C[Client search request] --> CO[Coordinating node]
  CO --> CN[Cold node: full local copy]
  CO --> FN[Frozen node: shared cache]
  FN -->|Cache miss| R[Snapshot repository in object storage]
  CN -.->|Initial download only| R
  FN --> BC[Blob cache system index]
        

The store type is the secret switch

Inside Elasticsearch, every shard reads and writes files through a layer called a directory. A normal shard uses a directory that maps to files on local disk. A mounted shard uses a special directory whose settings say “the data lives in snapshot X of repository Y”. Everything above that layer, including query execution, scoring, filtering, and aggregation, is unchanged. That is why a searchable snapshot supports the same query language and the same features as a regular index.

Why the repository must be treated as production storage

Because the snapshot is now the real home of the data, the repository stops being an afterthought. Its availability, durability, permissions, and even its network path matter to your searches. A repository that was fine for nightly backups may not be fine as a live storage layer. You should think about it in the same way you think about the disks of your data nodes.

Protection against accidental deletion

Elasticsearch refuses to delete a snapshot that is still mounted by a searchable snapshot index. This is an important guard rail. It means an operator running a cleanup on old snapshots cannot silently destroy the storage of live indices. The lifecycle delete phase has a setting, on by default, that removes the underlying snapshot when the mounted index is deleted, as long as no other index still depends on it.

The choice between the two modes is the most important design decision you will make. Here is each in depth.

Fully mounted: the cold tier

When an index is mounted with a full copy, Elasticsearch downloads every file of every shard from the repository onto the local disks of the assigned nodes. Once this recovery finishes, searches read from local disks and behave much like searches on a normal index. Speed is close to that of a regular index on similar hardware.

So where does the saving come from? Since the repository already holds a durable copy of the data, you do not need replicas to protect against disk failure. If a node is lost, its shards simply recover again from the snapshot. Many teams therefore run the cold tier with no replicas at all. That alone removes half the local storage compared with a hot index with one replica.

Partially mounted: the frozen tier

Partial mounting goes much further. The shard starts almost immediately, because only a tiny amount of information is loaded up front. When a search needs some bytes from a file, Elasticsearch checks the local shared cache. If those bytes are there, it uses them. If not, it fetches just the needed range from the repository, stores it in the cache, and continues.

Because only the parts of files that searches actually touch are downloaded, a frozen node can be responsible for far more data than its local disk could ever hold. The disk is no longer a place to store data. It is a place to remember what was recently read.

What the frozen shared cache really is

The shared cache on a frozen node is a single large file on local disk, divided into equal-sized regions. Each region can hold a slice of some file from some shard. When a region is needed and the cache is full, Elasticsearch evicts a region that has been used less, favoring pieces that are used often. The size of the cache is a node setting, and on a dedicated frozen node it defaults to most of the node’s disk, leaving some headroom for the operating system.

Cache regions have a default size measured in megabytes, and reads on a miss are made in ranges rather than one tiny byte at a time. This is deliberate. Object stores respond best to fewer, larger reads, so the design trades a little extra downloaded data for far fewer network calls.

Why not always use frozen?

Frozen is cheaper, so it is tempting. The problem is that every search over uncached data pays a network price. A dashboard that runs twenty aggregations over last month’s data every minute would constantly miss the cache, overload the object store with requests, and feel sluggish. Fully mounted keeps that experience acceptable. The decision is therefore about how often, and how urgently, people query the data.

flowchart TD
  Q[Search needs bytes of a segment file] --> H{Bytes in shared cache?}
  H -->|Yes| A[Serve from local disk]
  H -->|No| B[Fetch a range from repository]
  B --> W[Write it into a cache region]
  W --> A
  W --> E{Cache full?}
  E -->|Yes| V[Evict a less used region]
  E -->|No| A
        

Now let us follow the data from the moment you mount a snapshot to the moment a search result comes back.

Step one: the mount request becomes cluster state

When a snapshot is mounted, the master node reads the snapshot’s metadata from the repository. That metadata lists the shards of the index and the files that make up each shard. The master then creates a new index in the cluster state. Its settings record the repository name, the snapshot name, the original index identity, and whether the mount is partial. The shard allocation logic is told which tier the shards must go to.

Step two: allocation and recovery from the snapshot

A shard of a normal index recovers from another copy of itself, usually the primary. A shard of a searchable snapshot index recovers from the snapshot. This is true for every copy, including any replicas. Each copy builds its own view of the data straight from the repository. No node has to stream data to another during recovery, which reduces load on the rest of the cluster.

What “recovery” means depends on the mode. For a full copy, the node downloads all files and verifies them. For a partial mount, the node only prepares the directory structure and reads a few small pieces of metadata. The shard can then be marked as started, and searches can begin immediately.

Step three: how a single read is served

When Lucene wants to read some bytes from a segment file, it asks the directory. On a fully mounted shard, the directory reads from the local copy, the same as always. On a partially mounted shard, the directory works out which cache region or regions cover the requested bytes.

If the region is already in the cache, the bytes are copied out of the local file. If not, the directory issues a ranged read against the repository, downloads that region, writes it to the cache, and returns the bytes. If several searches want the same missing region at the same moment, they share one download instead of each making their own. This coalescing is essential, because otherwise a burst of concurrent queries could flood the object store.

Small reads and the blob cache

Lucene files begin with headers and end with footers containing checksums and structure information. Opening a shard touches these small parts of many files. Fetching each one from the repository would be very slow, because each network call has a fixed delay no matter how small it is. To avoid this, Elasticsearch stores these small, hot pieces in a system index so that starting a shard does not require dozens of calls to object storage.

Why access patterns matter so much

Different Lucene structures are read in different ways, and this explains why some queries are gentle on the cache and others are brutal.

Read-ahead and eviction

Because the cost of a network call is mostly fixed, reading a slightly larger region than strictly needed is often cheaper than making two small calls. This is why the cache works in regions. On eviction, the cache prefers to keep regions that have been used repeatedly. A one-time large scan should not push out the pieces that many other queries rely on, and the frequency-based approach helps limit that damage, although a very large scan can still cause churn.

In real life you rarely mount snapshots by hand. Index lifecycle management does it for you, following the age of the data.

The lifecycle phases

An index lifecycle policy is made of phases, each with actions. The searchable snapshot action can be placed in the cold phase (producing a fully mounted index) or in the frozen phase (producing a partially mounted one). A policy usually looks like this in words: keep the index hot while it receives writes, move it to warm after rollover, then take a snapshot and mount it in cold or frozen when it is old enough, and delete it when the retention period ends.

flowchart LR
  H[Hot: writes and rollover] --> W[Warm: read mostly]
  W --> C[Cold: snapshot then full mount]
  C --> F[Frozen: partial mount]
  F --> D[Delete index and snapshot]
        

What the action does behind the scenes

Skipping tiers

There is no rule that data must pass through every tier. Many deployments go directly from hot to frozen, because a warm tier that only delays the move adds cost without adding much value. Others use hot, then cold with full mounts for a couple of months, then frozen for long-term retention. The right shape depends on how quickly your query frequency drops.

Data streams and rollover

Time-based data is best managed as a data stream, which is a set of hidden backing indices that Elasticsearch rolls over automatically by size or age. Lifecycle policies apply to each backing index separately. Only closed-out backing indices, those no longer written to, are ever converted to searchable snapshots. The write index always stays on the hot tier.

These are illustrative plans only. Choose real durations from the actual questions your users ask of the data and from any legal retention duty you have.

Changing where the master copy of the data lives changes how failures behave. This chapter walks through what breaks, what heals, and what you must protect.

Replicas mean something different here

On a regular index, a replica protects you from losing data if a node fails. On a searchable snapshot index, the data is already protected by the snapshot, so replicas are no longer about durability. They are about availability and search capacity. If you have zero replicas and a node holding a shard goes down, that shard is unavailable until it is reassigned and recovered from the snapshot. If you have one replica, another node can answer searches while the lost copy rebuilds.

A cluster with zero replicas for mounted indices can still report a healthy status, because there is nothing missing from the cluster’s point of view. Do not read that green light as a promise of zero downtime. It only means every shard has an active copy right now.

Node failures

Repository failures

The repository becomes a dependency of your searches, and the impact depends on the mode.

• Temporary outage, cold tier: searches on already recovered shards continue to work from local copies, but any shard that needs to recover cannot do so until the repository returns.
• Temporary outage, frozen tier: searches that hit the cache continue to work. Searches that need uncached data fail or time out for the affected shards.
• Throttling by the provider: a burst of requests may cause slow responses or errors, which shows up as partial search failures and long tail latencies.
• Permission change: an expired credential or a changed bucket policy looks exactly like an outage from Elasticsearch’s point of view.
• Data deleted or corrupted in the bucket: this is the worst case. If the snapshot’s files are removed from the repository by anything outside Elasticsearch’s control, the data is gone, because there may be no other copy.

flowchart TD
  X[Something fails] --> N{What failed?}
  N -->|Data node| R1[Shard reassigned and recovered from snapshot]
  N -->|Repository unavailable| R2[Cached reads work, uncached reads fail]
  N -->|Snapshot files lost| R3[Data lost unless a second copy exists]
  R1 --> OK[Service resumes after recovery]
  R2 --> OK2[Service resumes when repository returns]
        

Protecting the single most important copy

The lesson of this chapter is that you have moved your durability from many replicas on many disks into one logical copy in one repository. That repository deserves serious protection.

• Turn on versioning or object lock features of your object store so that accidental or malicious deletions can be reversed or blocked for a set period.
• Restrict who can write to or delete from the bucket. Only the Elasticsearch service identity and a very small group of administrators should have these rights.
• Consider replicating the bucket to a second region or account for disaster recovery, remembering that a second cluster can mount the replicated snapshots.
• Do not point unrelated tools at the same bucket path, because cleanup jobs written for other purposes may delete files they think are orphaned.

Searching a frozen index is not the same as searching a hot one. The good news is that a handful of habits make the difference between a tolerable experience and a painful one.

Set the right expectations

On a fully mounted index, a well-tuned search should feel similar to a regular index on comparable hardware, because the files are local. On a partially mounted index, the first search over a stretch of data may take seconds or even minutes for very large ranges, while later searches over the same data can be many times faster. Communicate this to the people who use the data, because surprise is the biggest source of complaints.

Narrow the time range

The single most valuable tuning is a tight time filter. Elasticsearch has a preliminary step called the can-match phase, where it asks each shard whether it could possibly contain matching documents before doing real work. For time-based indices, recent versions store the earliest and latest timestamps of each index as metadata in the cluster, so many shards outside the requested time range can be skipped without touching the repository at all.

Use asynchronous search for slow queries

Asynchronous search lets a request be submitted and then checked later, instead of holding an open connection until it finishes. This is the right tool for long-running searches on frozen data. The person who asked can leave a browser tab open, and results appear as shards report back. Many user interfaces do this automatically for large date ranges.

Practical tuning habits

Concurrency and the object store

Searches over many shards fan out across many nodes, and each node may read from the repository at once. Object stores handle high concurrency very well, but they can still throttle a single client that sends too many requests too fast. If searches on the frozen tier behave normally most of the time but suddenly stall in bursts, throttling by the storage provider is a prime suspect. Provider-side metrics, such as request counts and error rates, tell you quickly.

Warm-up and pre-population

On the frozen tier, the cache warms naturally as data is used. There is no simple switch to preload an entire index into it, and doing so would defeat the point of the tier, since the cache is much smaller than the data. If a known investigation window is coming, such as an audit period, you can run a representative search ahead of time so that later searches are faster. For data that must always respond quickly, the right answer is to keep it on the cold tier with a full mount.

Sizing a searchable snapshot deployment is different from sizing a hot tier. You are planning three things at once: the repository, the local storage, and the network path between them.

Sizing the repository

Estimate how much data you will keep in each snapshot, then multiply by the number of days of retention. Remember that the size of an index on disk includes its indexing overhead, but a snapshot only stores the shard files of primaries, not replicas. This means the repository usually needs less space than your hot tier uses for the same data, which is a pleasant surprise. Compression in snapshots can reduce this further, and merging segments before the snapshot helps as well.

Object stores rarely have a size limit you will hit, but they do have request rates and cost models. Estimate the number of files, because each shard contributes many files. Millions of tiny files increase request counts and slow snapshot operations. Merging to fewer segments before snapshotting reduces file counts.

Sizing cold nodes

For a fully mounted tier, local disk must be large enough to hold a full copy of every shard assigned to it, plus room for the disk watermarks that keep the node healthy. Add replicas if you need availability, and count them as extra copies. Memory and CPU needs are modest compared with hot nodes, because these nodes do not index. But keep enough memory for the operating system’s file cache, since it is what keeps repeated searches quick.

Sizing frozen nodes

For a frozen tier, the shared cache size is what matters most. A useful way to think about it is as a “working set” question: how much of your frozen data do people actually touch during a typical week? If the cache is close to that size, most searches will hit it. If it is far smaller, the cache will churn and searches will keep going to the repository.

The amount of data one frozen node can be responsible for is much larger than what its disk could hold, because the disk is only a cache. Elastic’s own guidance uses far higher ratios of data to memory for frozen nodes than for hot nodes, but the exact figures change between versions and depend on your search patterns. Use the published sizing guidance for your version as a starting point, then measure cache hit rates and search latency in your own environment and adjust.

Shard size and count

Each shard uses some memory on the node that holds it, even when idle, for keeping structures like field information and file lists ready. A frozen node holding thousands of small shards spends much of its memory on bookkeeping and leaves less for useful work. Larger shards, in the tens of gigabytes, are usually a better fit. When you roll over hot indices, choose sizes that produce sensible shards for the long life the data will have on the cold and frozen tiers, not just for hot performance.

Network throughput

The link between your nodes and the object store is often the actual bottleneck. Recovering a full copy of a large shard is limited by how quickly the node can read from the store. On cloud platforms, the network bandwidth of a virtual machine depends on its size. A small instance may cap out well below what the object store can provide. When choosing instance types for frozen and cold tiers, look at network performance as well as disk and memory.

Every design choice costs something. Here is an honest ledger for searchable snapshots.

The economics in plain words

Imagine you keep one year of logs at about one terabyte per day, with one replica on the hot tier. That is roughly 730 terabytes of premium local disk. Now imagine you keep the first week hot, and the remaining fifty-one weeks as searchable snapshots on the frozen tier with no replicas. Most of that data now sits in object storage at a small fraction of the price per gigabyte, and a modest set of frozen nodes provides the search capability. The exact saving depends on your provider and instance choices, but the direction and rough scale of the saving is what usually convinces teams to adopt the feature.

The hidden costs are worth counting too. Request charges on the object store rise with search activity on the frozen tier. Data transfer between zones or regions can add up if the repository is not close to the nodes. The Enterprise-level subscription adds licensing cost. The savings are usually large enough to outweigh these, but a proper estimate includes them.

Comparing your options for old data

Where the trade-offs bite hardest

Teams are usually happy with searchable snapshots for investigations and audits. They are least happy when they try to use the frozen tier for anything interactive that runs all day, or when they forget to protect the repository. The features are well suited to data whose value comes from the possibility of asking a question, not from the certainty of asking one every hour.

Old data is often the most sensitive data you own, because it is complete, historical, and rarely reviewed. Its protection deserves attention on two fronts: inside Elasticsearch and inside the object store.

Access inside Elasticsearch

Mounted indices are ordinary indices as far as security is concerned. Role-based access control applies in the same way: a user can only search the index names their role allows, and document-level and field-level security rules continue to work. Because lifecycle policies rename indices with a prefix, check that your role patterns cover the renamed indices, or better, give roles access to data streams and let the backing indices follow.

Actions that manage snapshots and mounting are a separate set of privileges. Only administrators and the lifecycle service should be able to create repositories, take snapshots, mount them, or delete them. Ordinary analysts should have no need for these rights.

Access to the repository

Elasticsearch reaches the object store using credentials. These are held in the secure settings store of each node, not in normal configuration files, so they are not visible in ordinary settings output. Give the identity used by Elasticsearch the minimum rights it needs on the bucket path, and no more. Where the cloud platform supports it, prefer short-lived, automatically rotated credentials or role-based identities over long-lived static keys.

Encryption

Retention, immutability, and legal duties

Many regulations require that records be kept for a fixed time and cannot be altered. A searchable snapshot repository with object lock in a compliance mode can help meet this, because even administrators cannot delete or overwrite the files until the period ends. Be careful to test that this works together with Elasticsearch, since some snapshot operations legitimately write new files and update metadata inside the repository. Work with your storage and compliance teams to choose settings that protect the data without blocking normal snapshot maintenance.

On the other side, privacy laws may require you to delete a person’s data on request. This is in tension with read-only, long-lived storage. The practical answers are to keep personal information out of long-retained indices, to shorten retention for indices that contain it, or to keep a process ready to reindex affected data into a new index without the records and then remove the old snapshot.

Shared repositories between clusters

A snapshot repository can be registered as read-only on a second cluster, which lets that cluster mount snapshots written by the first. This is powerful for reading old data from a test or analysis cluster, and for disaster recovery. It is also risky if two clusters are allowed to write to the same repository, since they can corrupt each other’s metadata. Only one cluster should ever write to a given repository path. All others must use the read-only setting.

A searchable snapshot setup that nobody watches will eventually surprise you. These are the signals worth tracking.

Cache health on frozen nodes

Elasticsearch exposes statistics about the shared cache through dedicated statistics endpoints, one for cache activity across nodes and one for activity by index. They report how many reads were served from the cache, how many needed a fetch from the repository, how many bytes were read, and how many regions were evicted. A healthy frozen tier shows a good ratio of hits to misses for the data people actually query. A cache that shows steady heavy eviction and a high miss rate is telling you it is too small for your working set.

Repository health

Check the result of snapshot operations and the state of the repository regularly. Snapshot creation failures, repository verification failures, and long snapshot durations are early warnings. On the storage side, watch request rate, error rate, throttling responses, and latency at the provider. If your object store publishes access logs, keep them for a short period so you can investigate slow-search episodes.

Lifecycle progress

Index lifecycle management has an explain feature that tells you, for each index, which phase and action it is in and whether it is stuck. The most common stuck points for the searchable snapshot action are a repository that is missing or misconfigured, a lack of space on target nodes, and a snapshot that fails partway. Alert on indices that stay in one step for far longer than expected.

Logs to read when something is wrong

Node logs record repository access failures, timeouts, throttling responses, and cache problems. Master node logs record snapshot and mounting failures. Slow log settings can capture searches that take longer than a chosen time on particular indices, and are useful for spotting the few expensive queries that cause most of the pain on the frozen tier.

A simple troubleshooting path

Teams that succeed with searchable snapshots tend to arrive at a small set of repeatable designs.

flowchart LR
  P[Primary cluster] -->|writes snapshots| R1[Repository in region A]
  R1 -->|bucket replication| R2[Repository copy in region B]
  R2 -->|read-only mount| S[Standby or analysis cluster]
        

These are the mistakes that appear again and again when teams first adopt the feature. Each one is easy to avoid once you know about it.

Smaller mistakes worth avoiding

• Forgetting the license: confirm your subscription level allows the feature before you design around it.
• Mixing writers on one repository: only one cluster may write to a path. Others must be read-only.
• Ignoring version compatibility: a snapshot can only be mounted by versions that can read the indices inside it. Plan upgrades with old snapshots in mind.
• No test of the full path: run a real mount and a real search on a copy of production data before trusting the design.
• Leaving sensitive data in long-lived indices: removal requests become painful once data is read-only.

These are common, representative ways organizations use the feature. They are patterns, not accounts of any specific company.

flowchart TD
  A[New threat announced] --> B[Analyst writes a search]
  B --> C[Search targets 12 months of data]
  C --> D[Hot and cold shards answer quickly]
  C --> E[Frozen shards fetch from repository]
  D --> F[Combined results]
  E --> F
  F --> G[Analyst finds first sign of attack]
        

Before committing to a design, gather the fine print in one place.

Known limitations

• Mounted indices are read-only. No indexing, updates, deletions, or force merging on the mounted index itself.
• Behavior depends on the repository type and its client settings. Support and performance vary across object stores and shared file systems.
• Snapshots must be readable by the version of Elasticsearch that mounts them. Very old snapshots may need special handling when you upgrade across major versions.
• Some features that rely on changing index structure in place, such as shrinking or splitting, do not apply to mounted indices.
• Index settings that describe the mount, such as the repository and snapshot names, are not meant to be changed by hand.
• Searchable snapshots need an appropriate license level, and details can change between releases.

A best-practices checklist

Numbers make ideas stick. Let us walk through a simple, made-up design to see how the pieces fit together. All figures are illustrative assumptions, not measurements.

The situation

A company collects about 500 gigabytes of log data per day. Assume the data takes roughly the same amount of space inside Elasticsearch as it did when it arrived. The business wants to keep one year of logs. Engineers search the last week constantly, and they investigate older data only a few times a week. Auditors sometimes ask about anything in the past twelve months.

Option A: everything hot, with one replica

One year is about 182 terabytes of primary data. With one replica, that becomes about 365 terabytes of fast local disk, plus the memory and processors to keep thousands of shards ready. This design works and is simple, but its cost grows every single day, and most of the disk is holding data that nobody reads.

Option B: hot for a week, frozen for the rest

The first seven days are about 3.5 terabytes of primary data, or about 7 terabytes with a replica, on hot nodes. The remaining 358 days of primary data, close to 179 terabytes, lives in the object store as snapshots. The frozen nodes hold a cache that is a small fraction of that total, sized to the amount of old data that investigations touch in a typical week. The local fast disk needed falls from hundreds of terabytes to a small number of terabytes plus a cache, and the bulk of the data sits at object storage prices.

Option C: hot, cold, then frozen

If engineers actually search the past month often and dislike waiting, add a cold tier for weeks two to five. Those 28 days are about 14 terabytes as a full local copy with no replicas. It costs more than Option B but keeps a comfortable experience for the most likely investigation window. The remaining eleven months stay frozen.

Choosing between B and C

The deciding fact is user behavior. Look at your search history and find out what share of searches touch data older than seven days, and how far back they go. If very few do, choose Option B. If a lot of searches reach back a month, Option C avoids frustrating people. If searches almost never go past a month, but the audit demand exists, Option C’s cold period might be shortened to a couple of weeks.

flowchart TD
  Q1{Do many searches reach back beyond a week?} -->|No| B[Choose hot then frozen]
  Q1 -->|Yes| Q2{Do they stay within about a month?}
  Q2 -->|Yes| C[Add a cold tier for that window]
  Q2 -->|No| D[Extend cold or add cache and replicas]
        

Searchable snapshots are one of several ways to deal with aging data. Knowing the alternatives helps you choose honestly.

Restore on demand

You can keep plain snapshots and restore an index only when someone asks for it. This is the cheapest option in storage, but restoring large indices takes time, needs free disk space at the moment of need, and turns every investigation into a small project. Searchable snapshots remove that delay. The data is always searchable, and you pay only for what you use of it.

Downsampling and rollups

For metrics, another way to reduce cost is to shrink old data by keeping fewer data points, for example one per hour instead of one per minute. This removes detail permanently, but it can be combined with searchable snapshots, because the smaller data is then also cheaper to store and read. Logs and security events, which cannot be summarized without losing the very detail investigators need, are better served by keeping all the data on cheap storage.

Keeping data in an external data lake

Some teams export old data to files in a data lake and query it with other engines. This can be very cheap, but it splits your data across two systems, with different query languages, security models, and dashboards. Searchable snapshots keep a single place to ask questions. The trade-off is that a data lake may be better for very large batch analytics, while Elasticsearch is better for fast, flexible, text-heavy search.

Cross-cluster search

Cross-cluster search lets one cluster query others. It solves a different problem: spreading data across clusters. It can be combined with searchable snapshots, for instance by placing the frozen tier in a dedicated cluster and searching it remotely, which isolates heavy historical searches from production.

If you decide to introduce searchable snapshots into an existing cluster, a staged approach lowers risk and builds confidence.

Communicating with users

The best technical design can still fail socially if people are not told what to expect. Explain in simple terms that recent data is instant, older data is a little slower, and the oldest data may take a moment on the first search. Provide a place to run long searches asynchronously. When people understand the reason for the difference, they adapt quickly, and they stop treating every slow search as a fault.

Real problems rarely announce their cause. These scenarios link common symptoms to the most likely explanations and sensible responses.

Searchable snapshots did not appear fully formed. They have grown across releases, and the direction of travel is worth understanding.

Planning upgrades

Each Elasticsearch version can read indices created by its own version and by the previous major version. Mounted indices follow the same rule, because they are made of the same kind of files. In practice, this means you should upgrade in the recommended order, verify that old snapshots can still be mounted after an upgrade, and check the release notes for changes to defaults such as cache sizes and lifecycle behavior. Rehearse an upgrade on a non-production cluster that includes mounted indices.

A steady move toward object storage

The wider trend in search and analytics systems is to treat cheap, durable object storage as the foundation and local disks as a performance layer. Searchable snapshots were an early and practical step in that direction for Elasticsearch. Later architectures push the idea further, but the core concepts you have learned here, a durable copy in object storage, a cache close to compute, and read paths that fetch ranges on demand, carry over directly.

Keep documentation close

Defaults, setting names, and sizing guidance evolve. Use this guide to understand why the system behaves as it does, and use the official documentation for your exact version to confirm the specifics before making production changes.

A quick reference for the vocabulary used throughout this guide.

They start the same, since both are point-in-time copies of an index stored in a repository. The difference is what you do with them. A normal snapshot is restored before it can be searched. A searchable snapshot is mounted and searched in place, with the repository acting as the real storage layer.

Yes, for anything that is not stored as a searchable snapshot, such as hot data and cluster configuration. And for the mounted data itself, you should protect the repository with bucket versioning, restricted permissions, and ideally a replicated copy, because it is now the only durable copy.

The cold tier normally holds fully mounted indices with a complete local copy of the data, so searches are fast. The frozen tier holds partially mounted indices, with only a cache of recently used pieces on local disk, so it is much cheaper but slower on data that is not cached.

Because they do not download the shard files up front. They only load a small amount of starting information and then fetch further data when a search asks for it.

No. Mounted indices are read-only, because their data belongs to an immutable snapshot. To change data, you need to work with a regular index, for example by reindexing the affected documents.

Not for durability, because the snapshot already protects the data. Replicas are useful for availability and for extra search capacity. Choose the number based on how much interruption is acceptable for that data.

The first search had to fetch data from the repository over the network and stored it in the cache. The second search found much of that data already in the cache and read it from local disk.

It helps until the cache is larger than the working set of your real searches. Beyond that point, extra cache just sits mostly unused. Measure hit rates before buying more capacity.

On the frozen tier, searches that can be answered from the cache continue, while searches that need uncached data fail or time out for the affected shards. On the cold tier, already recovered shards keep working from local disk, but shards that must recover cannot do so until the store returns.

No. Elasticsearch refuses to delete a snapshot that a mounted index still depends on. This guard protects you from removing live data by accident.

They can, but only one of them should be allowed to write to it. Every other cluster should register the repository as read-only. This arrangement is useful for analysis clusters and disaster recovery.

The older feature reduced memory use for rarely searched indices but still kept the full data on local disks. The frozen tier with searchable snapshots replaced it, since it addresses the storage cost problem as well as the memory problem.

Not in every case. Savings are largest for large volumes of rarely searched data. Heavy, frequent searching of frozen data can bring request charges, slow experiences, and the need for a larger cache, which reduce the benefit. A licensing cost also applies.

Look at your actual usage. Find the age after which most searches stop asking for the data, and move it to a cheaper tier just after that point. Review the numbers periodically, because habits change.

A searchable snapshot lets Elasticsearch treat a snapshot in object storage as the real home of an index. Because Lucene segments never change, they can be copied to cheap storage once and then read back in pieces whenever a search needs them. Fully mounted indices bring a whole copy to local disk for fast, dependable searches on the cold tier. Partially mounted indices keep only a cache locally and fetch the rest on demand, making the frozen tier dramatically cheaper for data that is rarely searched. Index lifecycle management ties the story together by moving data through the tiers automatically. The price of these savings is slower searches on uncached data, read-only indices, and a repository that must now be protected like production storage. Used with clear expectations, careful sizing, and good monitoring, searchable snapshots let you keep years of history searchable without paying hot-tier prices for it.