Elasticdump and Snapshot and Restore are usually presented as rivals, as if you had to pick a side before moving any Elasticsearch data. They are not really rivals. One is the cluster’s own backup machinery, working directly on the segment files the cluster already stores. The other is a document-level mover that talks to a cluster through its REST APIs and carries JSON documents from one place to another. Because the two tools work at completely different layers, each one is excellent at jobs the other handles badly, and most confusion about them comes from expecting one tool to do the other’s work.
The short version is this. If you need a backup of a cluster, a disaster-recovery copy, or a fast migration between compatible versions, snapshots are the answer — they are the only backup method Elastic actually supports. If you need to cross a version boundary, move data between Elasticsearch and OpenSearch, extract only part of an index, reshape documents on the way, or end up with a file that a human or another tool can read, that is ElasticDump’s territory. The sections below explain the mechanics behind that rule of thumb, so you can apply it to the cases that fall in between.
Two tools, two layers
A useful way to keep the two apart is to ask what each one actually moves.
Snapshot and Restore moves the cluster’s internal storage. An Elasticsearch index lives on disk as Lucene segment files, and a snapshot copies those files, largely as they are, into a repository. Restoring a snapshot means putting those segment files back into a cluster, which is why restores are fast: the destination does not have to re-read, re-analyze, and re-index every document, because the index arrives already built.
ElasticDump moves documents. It reads them out of the source through the Search API — using the Scroll API, or search_after with a point in time on newer versions — and writes them into the destination through the normal indexing APIs. The destination then indexes every document itself, under its own version’s rules. That extra work is exactly why ElasticDump is slower on very large indices, and also why it is so flexible: anything that can be read and re-indexed can cross version and product boundaries that a raw segment copy cannot.
Everything else in this comparison follows from that single difference.
What Snapshot and Restore actually is
Snapshot and Restore is built into Elasticsearch itself. Before you can take a snapshot you must register a snapshot repository with the cluster — a place where the segment files will be stored. A repository can be a shared filesystem, or object storage such as S3, Azure Blob Storage, or Google Cloud Storage, plus HDFS, with some repository types provided by plugins.
A snapshot is a backup taken from a running cluster. You can snapshot the whole cluster or selected indices and data streams. Within a repository, snapshots are incremental: the first snapshot copies everything, and later snapshots only store data that earlier snapshots have not already copied. That makes frequent snapshots cheap. The incrementality only works inside one repository, though — it does not carry across repositories.
Elastic’s own documentation is blunt about where snapshots sit in the hierarchy: “The only reliable and supported way to back up a cluster is by taking a snapshot.” Copying a node’s data directory by hand is explicitly unsupported and can silently lose data. This is the single most important fact in this article: whatever else you use ElasticDump for, it does not change the fact that snapshots are the supported backup mechanism for a cluster.
Restores are more flexible than people often assume. You can restore a whole snapshot or just specific indices from it, and during a restore an index can be renamed and some of its settings altered. Snapshot Lifecycle Management (SLM) rounds out the picture by automating the routine work — taking snapshots on a schedule and retaining them according to a policy. Scheduled, incremental, supported backup is a solved problem inside Elasticsearch, and the solution is snapshots.
What ElasticDump does instead
ElasticDump is an external command-line tool that treats a cluster as a source of documents rather than a store of segment files. It connects over HTTP, reads documents in batches, and either writes them to another cluster or writes them out as files. There is nothing to register on the cluster and nothing to configure on the destination beyond having somewhere for the documents to land.
Because the destination re-indexes everything, one tool covers a wide range of targets: Elasticsearch 5 and later, and OpenSearch, which ElasticDump has supported since version 6.76.0. The same command shape works for a same-version copy, a jump across major versions, or a move between the two products — situations where segment files from one side simply cannot be loaded by the other.
ElasticDump also works at a granularity snapshots do not attempt:
- Subsets. A
--searchBodyquery restricts the copy to matching documents — one tenant, one date range, one document type — instead of whole indices. - Transforms. A
--transformscript can change documents mid-move: rename a field, compute a value, or strip sensitive fields out of a copy destined for a development environment. - Readable output. A dump file is line-delimited JSON — one document per line — or CSV. You can open it, grep it, diff it, check it into version control, or feed it to a completely different tool.
The cost of all this is speed and completeness. Every document is read, transferred, and indexed again, so moving a huge index takes far longer than copying its segments. And ElasticDump copies indices and their associated objects — mappings, settings, analyzers, aliases, templates — not cluster-level state. It is a mover, not a backup system.
Two operational details matter in practice. First, an interrupted dump is not necessarily a lost dump: a run can be resumed from the last scroll ID while that scroll context is still alive, or restarted from a known line offset in the output file. Second, ElasticDump does not fail loudly on every write error — its option for ignoring Elasticsearch write errors defaults to on, so a run can report success while some documents were rejected at the destination. Whichever of these tools you use for a copy, comparing document counts on both sides afterwards is part of the job, not an optional extra. When a copy runs index-to-index, the order also matters: analyzer first, then mapping, then data, so the destination index is created with the right analysis chain and field types before documents arrive and get dynamically mapped into the wrong shape.
Side-by-side comparison
| Snapshot and Restore | ElasticDump | |
|---|---|---|
| What it moves | Lucene segment files (the index as stored) | Documents, read and re-indexed via REST APIs |
| Backup status | The only backup method Elastic supports | A portable copy; not a cluster backup strategy |
| Setup | Requires a registered snapshot repository | Nothing to register; runs from the command line |
| Incremental | Yes, within a repository | No; each run is a fresh logical copy |
| Scheduling | Built in, via Snapshot Lifecycle Management | None; you schedule it yourself |
| Speed on large indices | Fast — no re-indexing on restore | Slower — every document is re-indexed |
| Version compatibility | Compatible versions only | Elasticsearch 5+ and OpenSearch with one tool |
| Subsets | Whole indices (restorable individually) | Query-filtered subsets via --searchBody |
| Transforms | None — data restored as it was | Per-document changes via --transform |
| Output format | Internal repository format | Line-delimited JSON or CSV files |
| Cluster-level state | Captured as part of a supported backup | Not captured |
Where snapshots win
Real backup and disaster recovery. If the question is “how do I get this cluster back after a failure,” the answer is snapshots, full stop. They are the only supported route, they capture the cluster in a form Elastic will stand behind, and SLM means the backups happen on schedule without anyone remembering to run them.
Scale and speed. On large indices, copying segment files beats re-indexing documents by a wide margin, and incremental snapshots make the second, third, and fiftieth backup of a slowly changing cluster cheap. A nightly ElasticDump run over the same data re-reads and re-writes everything, every time.
Full-cluster state. A snapshot is a backup of the cluster, not just of the documents in it. When the recovery scenario is “rebuild what we had,” that completeness, combined with segment-speed restore, is what you want.
Compatible-version migration. Moving between compatible Elasticsearch versions — the standard upgrade path, for example — snapshots are the natural vehicle, and Elastic’s migration guidance uses them. One constraint from that guidance is worth knowing: the new cluster should be the same size as or larger than the old one.
Where ElasticDump wins
Crossing versions and products. A snapshot preserves an index in its original version’s form; it cannot reshape that data for a newer version’s mapping rules, and restoring requires compatible versions on both clusters. ElasticDump sidesteps the problem by re-indexing, which is why it can carry data across major-version gaps and between Elasticsearch and OpenSearch in either direction. If your move involves the fork between the two products, the background in ElasticSearch vs OpenSearch explains why the boundary sits where it does.
Extracting a subset. When you need last month’s orders, or one customer’s documents, or a small sample for a test environment, a snapshot of the whole index is the wrong unit of work. A query-scoped ElasticDump run copies exactly the documents that match and nothing else.
Changing the data on the way. Renaming fields, dropping fields, anonymizing values for a non-production copy — a snapshot faithfully reproduces the original, which is the opposite of what you want here. ElasticDump’s per-document transform exists precisely for this.
Producing a file other tools can read. A snapshot repository is an internal store: the files in it are only meaningful to a compatible Elasticsearch cluster restoring them. An ElasticDump file is plain line-delimited JSON. Anyone who has needed to inspect, diff, or process index data outside Elasticsearch will appreciate the difference. For a worked example of the document-level approach, see how to copy data from one Elasticsearch cluster to another.
No cluster-side setup. ElasticDump needs no repository registration and no repository storage to manage. For a one-off extraction, that zero-setup property matters.
A decision guide by scenario
- “I need backups of our production cluster.” Snapshots, scheduled with SLM. Nothing else is a supported backup.
- “We are upgrading Elasticsearch to a compatible version.” Snapshots — the documented migration path.
- “We are moving from Elasticsearch to OpenSearch, or jumping several major versions.” ElasticDump, because the versions or products are not snapshot-compatible.
- “I need a copy of one index, or part of one, on my laptop / in a dev cluster.” ElasticDump, with
--searchBodyif you only need a subset. If the underlying question is getting documents out of an index in the first place, how to get all data from an Elasticsearch index walks through the available methods. - “We must scrub personal data out of the copy.” ElasticDump — transforms happen during the move; a snapshot cannot change the data it carries.
- “The index is enormous and time matters.” Snapshots, assuming version compatibility. Re-indexing terabytes document by document is the slow path.
- “I want an extra, human-readable safety copy outside the cluster.” ElasticDump files alongside your snapshots are a reasonable extra layer — as a complement, not a replacement.
Three misconceptions worth dropping
“ElasticDump is the backup tool; snapshots are for migration.” This is almost exactly backwards. Snapshots are Elastic’s only supported backup; ElasticDump is primarily a mover whose files happen to make a useful portable copy.
“A snapshot repository is like a database dump I can open and inspect.” It is not. The repository holds internal segment files that only a compatible cluster can restore. If you want to look at your data in a file, that is an ElasticDump output.
“Snapshots can’t move a single index.” They can — a restore can target specific indices from a snapshot, rename them, and adjust some settings on the way in. What snapshots cannot do is jump incompatible versions or change the data during the move. The constraint is compatibility, not granularity.
FAQ
Can ElasticDump replace snapshots as my backup?
No. Elastic states that snapshots are the only reliable and supported way to back up a cluster. ElasticDump files are a handy portable copy and a genuine extra safety layer, but they do not capture cluster state and are not a backup strategy on their own.
Which is faster for a very large index?
Snapshots, and it is not close. A restore copies segment files without re-indexing, while ElasticDump reads every document out and indexes it again on the destination. The gap grows with index size.
Can I restore just one index from a snapshot?
Yes. Restores can target specific indices, and you can rename an index and alter some settings during the restore. The real limitation is version compatibility between the snapshot and the cluster restoring it.
Can snapshots move data from Elasticsearch to OpenSearch?
Only where the versions are compatible — the two products share a 7.10.2 ancestor, so snapshots from that era can cross over. Beyond that boundary, the products have diverged, and a document-level re-index with ElasticDump is the practical route.
Can I open a snapshot to check what is inside it?
Not in any useful way. A snapshot repository is an internal segment store, readable only by Elasticsearch restoring it. If you need data you can inspect directly, dump it to a line-delimited JSON file instead.
So should I just pick one tool and forget the other?
That framing is the original mistake. The two tools answer different questions — “how is this cluster protected?” and “how do I get this data somewhere else, in a different shape?” A setup can need either answer, both, or neither, and choosing one tool to cover both jobs usually means the backup job is the one quietly left undone.
Conclusion
Elasticdump belongs in your toolkit as the portable, flexible mover: it crosses version and product boundaries, extracts subsets, transforms documents in flight, and produces files that anything can read. Snapshot and Restore belongs in your toolkit as the backup system: supported, incremental, schedulable, and fast, so long as both ends stay within compatible versions. Most real setups end up using both — snapshots quietly protecting the cluster every night, and ElasticDump brought out for the migrations, extractions, and one-off copies that a segment-level backup was never designed to do.