Skip to content

Commit b57cb83

Browse files
committed
[DOCS] Added info about snapshotting your data before an upgrade.
1 parent 4e1ff8d commit b57cb83

File tree

1 file changed

+49
-31
lines changed

1 file changed

+49
-31
lines changed

docs/reference/modules/snapshots.asciidoc

Lines changed: 49 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -1,39 +1,55 @@
11
[[modules-snapshots]]
22
== Snapshot And Restore
33

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:
99

10+
* A snapshot of an index created in 5.x can be restored to 6.x.
1011
* A snapshot of an index created in 2.x can be restored to 5.x.
1112
* 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.
3013

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.
3135

3236
[float]
3337
=== Repositories
3438

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.
3753

3854
[source,js]
3955
-----------------------------------
@@ -48,7 +64,7 @@ PUT /_snapshot/my_backup
4864
// CONSOLE
4965
// TESTSETUP
5066

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:
5268

5369
[source,js]
5470
-----------------------------------
@@ -71,18 +87,20 @@ which returns:
7187
-----------------------------------
7288
// TESTRESPONSE
7389

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`:
7795

7896
[source,js]
7997
-----------------------------------
8098
GET /_snapshot/repo*,*backup*
8199
-----------------------------------
82100
// CONSOLE
83101

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`:
86104

87105
[source,js]
88106
-----------------------------------

0 commit comments

Comments
 (0)