|
@@ -1,29 +1,32 @@
|
|
|
[[modules-snapshots]]
|
|
|
== Snapshot And Restore
|
|
|
|
|
|
+// tag::snapshot-intro[]
|
|
|
A snapshot is a backup taken from a running Elasticsearch cluster. You can take
|
|
|
a snapshot of individual indices or of the entire cluster and store it in a
|
|
|
repository on a shared filesystem, and there are plugins that support remote
|
|
|
repositories on S3, HDFS, Azure, Google Cloud Storage and more.
|
|
|
|
|
|
-Snapshots are taken incrementally. This means that when creating a snapshot of
|
|
|
-an index Elasticsearch will avoid copying any data that is already stored in
|
|
|
-the repository as part of an earlier snapshot of the same index. Therefore it
|
|
|
-can be efficient to take snapshots of your cluster quite frequently.
|
|
|
-
|
|
|
-Snapshots can be restored into a running cluster via the restore API. When
|
|
|
-restoring an index it is possible to alter the name of the restored index as
|
|
|
-well as some of its settings, allowing a great deal of flexibility in how the
|
|
|
-snapshot and restore functionality can be used.
|
|
|
-
|
|
|
-WARNING: It is not possible to back up an Elasticsearch cluster simply by
|
|
|
-taking a copy of the data directories of all of its nodes. Elasticsearch may be
|
|
|
-making changes to the contents of its data directories while it is running, and
|
|
|
-this means that copying its data directories cannot be expected to capture a
|
|
|
-consistent picture of their contents. Attempts to restore a cluster from such a
|
|
|
-backup may fail, reporting corruption and/or missing files, or may appear to
|
|
|
-have succeeded having silently lost some of its data. The only reliable way to
|
|
|
-back up a cluster is by using the snapshot and restore functionality.
|
|
|
+Snapshots are taken incrementally. This means that when it creates a snapshot of
|
|
|
+an index, Elasticsearch avoids copying any data that is already stored in the
|
|
|
+repository as part of an earlier snapshot of the same index. Therefore it can be
|
|
|
+efficient to take snapshots of your cluster quite frequently.
|
|
|
+
|
|
|
+You can restore snapshots into a running cluster via the
|
|
|
+<<restore-snapshot,restore API>>. When you restore an index, you can alter the
|
|
|
+name of the restored index as well as some of its settings. There is a great
|
|
|
+deal of flexibility in how the snapshot and restore functionality can be used.
|
|
|
+
|
|
|
+WARNING: You cannot back up an Elasticsearch cluster by simply taking a copy of
|
|
|
+the data directories of all of its nodes. Elasticsearch may be making changes to
|
|
|
+the contents of its data directories while it is running; copying its data
|
|
|
+directories cannot be expected to capture a consistent picture of their contents.
|
|
|
+If you try to restore a cluster from such a backup, it may fail and report
|
|
|
+corruption and/or missing files. Alternatively, it may appear to have succeeded
|
|
|
+though it silently lost some of its data. The only reliable way to back up a
|
|
|
+cluster is by using the snapshot and restore functionality.
|
|
|
+
|
|
|
+// end::snapshot-intro[]
|
|
|
|
|
|
[float]
|
|
|
=== Version compatibility
|
|
@@ -519,6 +522,7 @@ When a repository is unregistered, Elasticsearch only removes the reference to t
|
|
|
the snapshots. The snapshots themselves are left untouched and in place.
|
|
|
|
|
|
[float]
|
|
|
+[[restore-snapshot]]
|
|
|
=== Restore
|
|
|
|
|
|
A snapshot can be restored using the following command:
|