Snapshot and restore

A snapshot is a backup taken from a running Elasticsearch cluster. You can take snapshots of an entire cluster, including all its data streams and indices. You can also take snapshots of only specific data streams or indices in the cluster.

You must register a snapshot repository before you can create snapshots.

Snapshots can be stored in either local or remote repositories. Remote repositories can reside on Amazon S3, HDFS, Microsoft Azure, Google Cloud Storage, and other platforms supported by a repository plugin.

Elasticsearch takes snapshots incrementally: the snapshotting process only copies data to the repository that was not already copied there by an earlier snapshot, avoiding unnecessary duplication of work or storage space. This means you can safely take snapshots very frequently with minimal overhead. This incrementality only applies within a single repository because no data is shared between repositories. Snapshots are also logically independent from each other, even within a single repository: deleting a snapshot does not affect the integrity of any other snapshot.

You can restore snapshots to a running cluster, which includes all data streams and indices in the snapshot by default. However, you can choose to restore only the cluster state or specific data streams or indices from a snapshot.

You can use snapshot lifecycle management to automatically take and manage snapshots.

A copy of the data directories of a cluster’s nodes does not work as a backup because it is not a consistent representation of their contents at a single point in time. You cannot fix this by shutting down nodes while making the copies, nor by taking atomic filesystem-level snapshots, because Elasticsearch has consistency requirements that span the whole cluster. You must use the built-in snapshot functionality for cluster backups.

A snapshot contains a copy of the on-disk data structures that comprise an index or a data stream’s backing indices. This means that snapshots can only be restored to versions of Elasticsearch that can read the indices.

The following table indicates snapshot compatibility between versions. The first column denotes the base version that you can restore snapshots from.

The following conditions apply for restoring snapshots and indices across versions:

Each snapshot can contain indices created in various versions of Elasticsearch. This includes backing indices created for data streams. When restoring a snapshot, it must be possible to restore all of these indices into the target cluster. If any indices in a snapshot were created in an incompatible version, you will not be able restore the snapshot.

If you end up in a situation where you need to restore a snapshot of a data stream or index that is incompatible with the version of the cluster you are currently running, you can restore it on the latest compatible version and use reindex-from-remote to rebuild the data stream or index on the current version. Reindexing from remote is only possible if the original data stream or index has source enabled. Retrieving and reindexing the data can take significantly longer than simply restoring a snapshot. If you have a large amount of data, we recommend testing the reindex from remote process with a subset of your data to understand the time requirements before proceeding.