Elastic Searchable Snapshots Explained: Warm vs Cold vs Frozen (and fm-clone-*)

Intro

Elastic searchable snapshots are one of the cleanest ways to slash storage cost and one of the easiest ways to confuse an otherwise sane engineer.

Teams enable frozen or cold tiers, flip a setting, and suddenly:

• warm vs cold “feels the same”
• snapshots look like magic (or witchcraft)
• new indices show up with names like fm-clone-…
• disk usage spikes at the worst possible time

This guide explains what’s actually happening under the hood, how warm/cold/frozen differ with and without searchable snapshots, and what to do when the cluster starts doing “mysterious clone things.” If you’re evaluating Elasticsearch Consulting Services, this is exactly the kind of problem Hyperflex solves daily, storage optimization without breaking observability, security, or search performance.

External references used in this post come from Elastic’s official docs and engineering blogs. (Elastic)

What “warm”, “cold”, and “frozen” really mean in Elastic

At a high level, data tiers are about aligning hardware cost with access patterns:

• Hot: heavy ingest + frequent search
• Warm: less ingest, still queried
• Cold: rarely queried, optimized for cost
• Frozen: very rarely queried, cheapest searchable storage

Elastic’s own docs are blunt about the key tradeoff: frozen data may require fetching from the snapshot repository, so searches are typically slower than cold. (Elastic)

The part people miss: cold/frozen aren’t just “slower disks.” They’re often a different storage model when searchable snapshots are involved. (Elastic)

What changes when you enable Elastic searchable snapshots

Searchable snapshots let Elastic mount a snapshot as a searchable index. The big win: you can reduce local disk usage dramatically for older, read-only data. (Elastic)

Two important truths:

• Cold and frozen tiers use searchable snapshots as the cost lever. (Elastic)
• This feature has licensing requirements (Elastic marks it as Enterprise in the docs). (Elastic)

So if someone says “cold vs warm feels the same,” it’s often because searchable snapshots aren’t actually in play (disabled, misconfigured repository, or using regular indices in cold).

Fully mounted vs partially mounted: the real difference (cold vs frozen)

Elastic effectively gives you two “mount styles”:

Cold tier: fully mounted searchable snapshots

A cold tier can keep fully mounted searchable snapshot indices. When you do this, Elastic emphasizes a big economic benefit: replica-free fully mounted snapshots can cut node/disk needs roughly in half compared to regular indices that need replicas. (Elastic)

Frozen tier: partially mounted searchable snapshots

Frozen uses partially mounted indices that pull data from the snapshot repository as needed. That’s why it’s cheaper as it keeps far less local data but it is slower for search. (Elastic)

Elastic has even published performance benchmarking on searchable snapshots/frozen behavior, which is worth skimming if you’re deciding whether frozen is “too slow” for your use case. (Elastic)

Why you see fm-clone-* indices (and why it can spike storage)

If you enable searchable snapshots in lifecycle policies, you may notice indices created with a prefix like fm-clone-….

Here’s the core idea: force-merge is often used when data becomes read-only, because it reduces segments and can reclaim space from deletes. (Elastic)
But force-merging every copy (primaries + replicas) can be wasteful.

Elastic has a long-running engineering theme around “can we force-merge fewer copies?” (because merging is expensive). (GitHub)
And in modern workflows around searchable snapshots, cloning can appear as part of how the system performs heavy operations efficiently before snapshotting/mounting.

So why the temporary storage spike?

• A clone is a clone. It exists as another index while the operation completes.
• In practice, you can see a period where reported store sizes look duplicated, then normalize later.

This is also why teams ask for control over behavior like force-merge-on-clone (including requests to opt out via UI/API). (GitHub)

Operational takeaway: if you’re tight on hot-tier disk, searchable snapshot transitions (and the clone/merge work that can come with them) can be the straw that breaks the camel’s SSD.

Warm vs cold if you turn off searchable snapshots

This is the exact question you pasted, and the honest answer is:

If searchable snapshots are off, then:

• Cold becomes “regular indices on cheaper/slower hardware,” not a different storage model.
• You usually still need replicas for resilience the way you always did.
• Warm vs cold differences may look mostly like hardware + allocation rules, not a magic disk reduction.

If searchable snapshots are on, then cold/frozen can stop behaving like “just another tier” and start behaving like “mounted from snapshots,” which is where the cost savings (and the gotchas) come from. (Elastic)

So the “difference” depends less on the tier name and more on whether your lifecycle is using the searchable snapshot action and a correctly configured repository. (Elastic)

A practical tiering decision framework

Use this as a simple rule set:

Choose warm when

• Data is queried regularly (dashboards, investigations, recurring reports)
• You still want decent search performance without premium hot-tier cost

Choose cold when

• Queries are occasional
• You want cheaper storage but still reasonable query speed
• You’re ready to make older data read-only and lifecycle-managed (Elastic)

Choose frozen when

• Queries are rare and mostly “break glass in case of incident”
• Cost matters more than latency
• You have a snapshot repository you trust and have tested (Elastic)

Elastic’s own framing is basically: hot/warm are for ingest + search, cold/frozen are for store. (Elastic)

Troubleshooting checklist (the stuff that saves weekends)

1) “I enabled frozen but don’t understand the repository setup”

Searchable snapshots require a snapshot repository (S3/GCS/Azure/NFS, etc.) and lifecycle wiring. Elastic calls this out directly for the cold/frozen tiers. (Elastic)

2) “Snapshots are running slow, can I see details?”

Start by validating repository health and shard count/segment count. Force-merge and snapshot behavior can become painfully slow when shards are huge or extremely fragmented. (Elastic)

3) “/_snapshot/_status is empty but I do have snapshots”

This can be normal depending on what’s currently running vs completed; _status focuses on in-progress snapshot activity in many workflows. (If you need a blog sequel: “snapshot APIs that lie by omission” is a fun one.)

4) “We moved data to cold for a year, now heap is high/circuit breakers”

Tiering is not a substitute for sizing. If hot is overloaded (ingest rate, shard counts, query patterns), the cluster will still suffer. Use ILM to manage rollover/shards and keep hot healthy. (Elastic)

Final takeaway

If you remember one thing, make it this:

Warm/cold/frozen are not just labels. The real behavioral jump happens when Elastic searchable snapshots are enabled and your lifecycle starts mounting indices from a snapshot repository. That’s when you get the cost savings and that’s also when you might see fm-clone-*, temporary disk spikes, and “why is this index doing that?” moments.

Hyperflex helps teams design tiering and ILM policies that don’t implode under real ingest rates and we do it as Elasticsearch Consulting Services, focused on practical outcomes: lower cost, predictable performance, and fewer surprises.

Hyperflex helps teams scale Elastic fast with confidence. Contact us to explore how we can support your Elastic journey.

(For official Elastic references on tiers and searchable snapshots, start here.) (Elastic)

‍