Skip to content

Commit 93f32c6

Browse files
committed
Further emphasise filesystem backups don't work
In elastic#33102 we added a warning against using filesystem backups. Experience has shown that the wording we added was insufficiently general and open to misinterpretation. This commit reworks it to be clearer. This commit also clarifies that snapshots are not incremental across repositories.
1 parent 92f8598 commit 93f32c6

File tree

1 file changed

+17
-11
lines changed

1 file changed

+17
-11
lines changed

docs/reference/snapshot-restore/index.asciidoc

Lines changed: 17 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -22,8 +22,10 @@ and other platforms supported by a {plugins}/repository.html[repository plugin].
2222
{es} takes snapshots incrementally: the snapshotting process only copies data
2323
to the repository that was not already copied there by an earlier snapshot,
2424
avoiding unnecessary duplication of work or storage space. This means you can
25-
safely take snapshots very frequently with minimal overhead. However, snapshots
26-
are also logically independent: deleting a snapshot does not affect the
25+
safely take snapshots very frequently with minimal overhead. This
26+
incrementality only applies within a single repository because no data is
27+
shared between repositories. Snapshots are also logically independent from each
28+
other, even within a single repository: deleting a snapshot does not affect the
2729
integrity of any other snapshot.
2830
// end::snapshot-intro[]
2931

@@ -39,15 +41,19 @@ You can use
3941
to automatically take and manage snapshots.
4042

4143
// tag::backup-warning[]
42-
WARNING: You cannot back up an {es} cluster by simply copying
43-
the data directories of all of its nodes. {es} may be making changes to
44-
the contents of its data directories while it is running; copying its data
45-
directories cannot be expected to capture a consistent picture of their contents.
46-
If you try to restore a cluster from such a backup, it may fail and report
47-
corruption and/or missing files. Alternatively, it may appear to have succeeded
48-
though it silently lost some of its data. The only reliable way to back up a
49-
cluster is by using the snapshot and restore functionality.
50-
44+
WARNING: **The only reliable and supported way to back up a cluster is by
45+
taking a snapshot**. You cannot back up an {es} cluster by making copies of the
46+
data directories of its nodes. There are no supported methods to restore any
47+
data from a filesystem-level backup. If you try to restore a cluster from such
48+
a backup it may fail with reports of corruption or missing files or other data
49+
inconsistencies, or it may appear to have succeeded having silently lost some
50+
of your data.
51+
52+
A copy of the data directories of a cluster's nodes does not work as a backup
53+
because it is not a consistent representation of their contents at a single
54+
point in time. You cannot fix this by shutting down nodes while making the
55+
copies, nor by taking atomic filesystem-level snapshots, because {es} has
56+
consistency requirements that span the whole cluster.
5157
// end::backup-warning[]
5258

5359
[discrete]

0 commit comments

Comments
 (0)