1
1
[[modules-snapshots]]
2
2
== Snapshot And Restore
3
3
4
- The snapshot and restore module allows to create snapshots of individual
5
- indices or an entire cluster into a remote repository like shared file system,
6
- S3, or HDFS. These snapshots are great for backups because they can be restored
7
- relatively quickly but they are not archival because they can only be restored
8
- to versions of Elasticsearch that can read the index. That means that :
4
+ You can store snapshots of individual indices or an entire cluster in
5
+ a remote repository like a shared file system, S3, or HDFS. These snapshots
6
+ are great for backups because they can be restored relatively quickly. However,
7
+ snapshots can only be restored to versions of Elasticsearch that can read the
8
+ indices :
9
9
10
+ * A snapshot of an index created in 5.x can be restored to 6.x.
10
11
* A snapshot of an index created in 2.x can be restored to 5.x.
11
12
* A snapshot of an index created in 1.x can be restored to 2.x.
12
- * A snapshot of an index created in 1.x can **not** be restored to 5.x.
13
-
14
- To restore a snapshot of an index created in 1.x to 5.x you can restore it to
15
- a 2.x cluster and use <<reindex-from-remote,reindex-from-remote>> to rebuild
16
- the index in a 5.x cluster. This is as time consuming as restoring from
17
- archival copies of the original data.
18
-
19
- Note: If a repository is connected to a 2.x cluster, and you want to connect
20
- a 5.x cluster to the same repository, you will have to either first set the 2.x
21
- repository to `readonly` mode (see below for details on `readonly` mode) or create
22
- the 5.x repository in `readonly` mode. A 5.x cluster will update the repository
23
- to conform to 5.x specific formats, which will mean that any new snapshots written
24
- via the 2.x cluster will not be visible to the 5.x cluster, and vice versa.
25
- In fact, as a general rule, only one cluster should connect to the same repository
26
- location with write access; all other clusters connected to the same repository
27
- should be set to `readonly` mode. While setting all but one repositories to
28
- `readonly` should work with multiple clusters differing by one major version,
29
- it is not a supported configuration.
30
13
14
+ Conversely, snapshots of indices created in 1.x **cannot** be restored to
15
+ 5.x or 6.x, and snapshots of indices created in 2.x **cannot** be restored
16
+ to 6.x.
17
+
18
+ Snapshots are incremental and can contain indices created in various
19
+ versions of Elasticsearch. If any indices in a snapshot were created in an
20
+ incompatible version, you will not be able restore the snapshot.
21
+
22
+ IMPORTANT: When backing up your data prior to an upgrade, keep in mind that you
23
+ won't be able to restore snapshots after you upgrade if they contain indices
24
+ created in a version that's incompatible with the upgrade version.
25
+
26
+ If you end up in a situation where you need to restore a snapshot of an index
27
+ that is incompatible with the version of the cluster you are currently running,
28
+ you can restore it on the latest compatible version and use
29
+ <<reindex-from-remote,reindex-from-remote>> to rebuild the index on the current
30
+ version. Reindexing from remote is only possible if the original index has
31
+ source enabled. Retrieving and reindexing the data can take significantly longer
32
+ than simply restoring a snapshot. If you have a large amount of data, we
33
+ recommend testing the reindex from remote process with a subset of your data to
34
+ understand the time requirements before proceeding.
31
35
32
36
[float]
33
37
=== Repositories
34
38
35
- Before any snapshot or restore operation can be performed, a snapshot repository should be registered in
36
- Elasticsearch. The repository settings are repository-type specific. See below for details.
39
+ You must register a snapshot repository before you can perform snapshot and
40
+ restore operations. We recommend creating a new snapshot repository for each
41
+ major version. The valid repository settings depend on the repository type.
42
+
43
+ If you register same snapshot repository with multiple clusters, only
44
+ one cluster should have write access to the repository. All other clusters
45
+ connected to that repository should set the repository to `readonly` mode.
46
+
47
+ NOTE: The snapshot format can change across major versions, so if you have
48
+ clusters on different major versions trying to write the same repository,
49
+ new snapshots written by one version will not be visible to the other. While
50
+ setting the repository to `readonly` on all but one of the clusters should work
51
+ with multiple clusters differing by one major version, it is not a supported
52
+ configuration.
37
53
38
54
[source,js]
39
55
-----------------------------------
@@ -48,7 +64,7 @@ PUT /_snapshot/my_backup
48
64
// CONSOLE
49
65
// TESTSETUP
50
66
51
- Once a repository is registered, its information can be obtained using the following command :
67
+ To retrieve information about a registered repository, use a GET request :
52
68
53
69
[source,js]
54
70
-----------------------------------
@@ -71,18 +87,20 @@ which returns:
71
87
-----------------------------------
72
88
// TESTRESPONSE
73
89
74
- Information about multiple repositories can be fetched in one go by using a comma-delimited list of repository names.
75
- Star wildcards are supported as well. For example, information about repositories that start with `repo` or that contain `backup`
76
- can be obtained using the following command:
90
+ To retrieve information about multiple repositories, specify a
91
+ a comma-delimited list of repositories. You can also use the * wildcard when
92
+ specifying repository names. For example, the following request retrieves
93
+ information about all of the snapshot repositories that start with `repo` or
94
+ contain `backup`:
77
95
78
96
[source,js]
79
97
-----------------------------------
80
98
GET /_snapshot/repo*,*backup*
81
99
-----------------------------------
82
100
// CONSOLE
83
101
84
- If a repository name is not specified, or `_all` is used as repository name Elasticsearch will return information about
85
- all repositories currently registered in the cluster :
102
+ To retrieve information about all registered snapshot repositories, omit the
103
+ repository name or specify `_all` :
86
104
87
105
[source,js]
88
106
-----------------------------------
0 commit comments