index.asciidoc 8.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192
  1. [[snapshot-restore]]
  2. = Snapshot and restore
  3. A snapshot is a backup of a running {es} cluster. You can use snapshots to:
  4. * Regularly back up a cluster with no downtime
  5. * Recover data after deletion or a hardware failure
  6. * Transfer data between clusters
  7. * Reduce your storage costs by using <<searchable-snapshots,searchable
  8. snapshots>> in the cold and frozen data tiers
  9. [discrete]
  10. [[snapshot-workflow]]
  11. == The snapshot workflow
  12. {es} stores snapshots in an off-cluster storage location called a snapshot
  13. repository. Before you can take or restore snapshots, you must
  14. <<snapshots-register-repository,register a snapshot repository>> on the cluster.
  15. {es} supports several repository types with cloud storage options, including:
  16. * AWS S3
  17. * Google Cloud Storage (GCS)
  18. * Microsoft Azure
  19. After you register a snapshot repository, you can use
  20. <<snapshot-lifecycle-management,{slm} ({slm-init})>> to automatically take and
  21. manage snapshots. You can then <<snapshots-restore-snapshot,restore a snapshot>>
  22. to recover or transfer its data.
  23. [discrete]
  24. [[snapshot-contents]]
  25. == Snapshot contents
  26. By default, a snapshot of a cluster contains the cluster state, all data
  27. streams, and all indices, including system indices. The cluster state includes:
  28. include::apis/restore-snapshot-api.asciidoc[tag=cluster-state-contents]
  29. You can also take snapshots of only specific data streams or indices in the
  30. cluster. A snapshot that includes a data stream or index automatically includes
  31. its aliases. When you restore a snapshot, you can choose whether to restore
  32. these aliases.
  33. Snapshots don't contain or back up:
  34. * Transient cluster settings
  35. * Registered snapshot repositories
  36. * Node configuration files
  37. [discrete]
  38. [[feature-state]]
  39. === Feature states
  40. A feature state contains the indices and data streams used to store
  41. configurations, history, and other data for an Elastic feature, such as {es}
  42. security or {kib}.
  43. A feature state typically includes one or more <<system-indices,system indices
  44. or system data streams>>. It may also include regular indices and data streams
  45. used by the feature. For example, a feature state may include a regular index
  46. that contains the feature's execution history. Storing this history in a regular
  47. index lets you more easily search it.
  48. [discrete]
  49. [[how-snapshots-work]]
  50. == How snapshots work
  51. Snapshots are automatically deduplicated to save storage space and reduce network
  52. transfer costs. To back up an index, a snapshot makes a copy of the index's
  53. <<near-real-time,segments>> and stores them in the snapshot repository. Since
  54. segments are immutable, the snapshot only needs to copy any new segments created
  55. since the repository's last snapshot.
  56. Each snapshot is also logically independent. When you delete a snapshot, {es}
  57. only deletes the segments used exclusively by that snapshot. {es} doesn't delete
  58. segments used by other snapshots in the repository.
  59. [discrete]
  60. [[snapshots-shard-allocation]]
  61. === Snapshots and shard allocation
  62. A snapshot copies segments from an index's primary shards. When you start a
  63. snapshot, {es} immediately starts copying the segments of any available primary
  64. shards. If a shard is starting or relocating, {es} will wait for these processes
  65. to complete before copying the shard's segments. If one or more primary shards
  66. aren't available, the snapshot attempt fails.
  67. Once a snapshot begins copying a shard's segments, {es} won't move the shard to
  68. another node, even if rebalancing or shard allocation settings would typically
  69. trigger reallocation. {es} will only move the shard after the snapshot finishes
  70. copying the shard's data.
  71. [discrete]
  72. [[snapshot-start-stop-times]]
  73. === Snapshot start and stop times
  74. A snapshot doesn't represent a cluster at a precise point in time. Instead, each
  75. snapshot includes a start and end time. The snapshot represents a view of each
  76. shard's data at some point between these two times.
  77. [discrete]
  78. [[snapshot-restore-version-compatibility]]
  79. == Snapshot compatibility
  80. To restore a snapshot to a cluster, the versions for the snapshot, cluster, and
  81. any restored indices must be compatible.
  82. [discrete]
  83. [[snapshot-cluster-compatibility]]
  84. === Snapshot version compatibility
  85. [cols="6"]
  86. |===
  87. | 5+^h| Cluster version
  88. ^h| Snapshot version ^| 2.x ^| 5.x ^| 6.x ^| 7.x ^| 8.x
  89. ^| *1.x* -> ^|{yes-icon} ^|{no-icon} ^|{no-icon} ^|{no-icon} ^|{no-icon}
  90. ^| *2.x* -> ^|{yes-icon} ^|{yes-icon} ^|{no-icon} ^|{no-icon} ^|{no-icon}
  91. ^| *5.x* -> ^|{no-icon} ^|{yes-icon} ^|{yes-icon} ^|{no-icon} ^|{no-icon}
  92. ^| *6.x* -> ^|{no-icon} ^|{no-icon} ^|{yes-icon} ^|{yes-icon} ^|{no-icon}
  93. ^| *7.x* -> ^|{no-icon} ^|{no-icon} ^|{no-icon} ^|{yes-icon} ^|{yes-icon}
  94. |===
  95. You can't restore a snapshot to an earlier version of {es}. For example, you
  96. can't restore a snapshot taken in 7.6.0 to a cluster running 7.5.0.
  97. ifeval::["{release-state}"!="released"]
  98. [[snapshot-prerelease-build-compatibility]]
  99. NOTE: This documentation is for {es} version {version}, which is not yet
  100. released. The compatibility table above applies only to snapshots taken in a
  101. released version of {es}. If you're testing a pre-release build of {es} then you
  102. can still restore snapshots taken in earlier released builds as permitted by
  103. this compatibility table. You can also take snapshots using your pre-release
  104. build, and restore them using the same build. However once a pre-release build
  105. of {es} has written to a snapshot repository you must not use the same
  106. repository with other builds of {es}, even if the builds have the same version.
  107. Different pre-release builds of {es} may use different and incompatible
  108. repository layouts. If the repository layout is incompatible with the {es} build
  109. in use then taking and restoring snapshots may result in errors or may appear to
  110. succeed having silently lost some data. You should discard your repository
  111. before using a different build.
  112. endif::[]
  113. [discrete]
  114. [[snapshot-index-compatibility]]
  115. === Index compatibility
  116. A cluster is only compatible with indices created in the previous major version
  117. of {es}. Any data stream or index you restore from a snapshot must be compatible
  118. with the current cluster's version. If you try to restore an index created in an
  119. incompatible version, the restore attempt will fail.
  120. A snapshot can contain indices created in a previous major version. For example,
  121. a snapshot of a 6.x cluster can contain an index created in 5.x. If you try to
  122. restore the 5.x index to a 7.x cluster, the restore attempt will fail. Keep this
  123. in mind if you take a snapshot before upgrading a cluster.
  124. As a workaround, you can first restore the data stream or index to another
  125. cluster running the latest version of {es} that's compatible with both the index
  126. and your current cluster. You can then use
  127. <<reindex-from-remote,reindex-from-remote>> to rebuild the data stream or index
  128. on your current cluster. Reindex from remote is only possible if the index's
  129. <<mapping-source-field,`_source`>> is enabled.
  130. Reindexing from remote can take significantly longer than restoring a snapshot.
  131. Before you start, test the reindex from remote process with a subset of the data
  132. to estimate your time requirements.
  133. [discrete]
  134. [[other-backup-methods]]
  135. == Other backup methods
  136. // tag::backup-warning[]
  137. **Taking a snapshot is the only reliable and supported way to back up a
  138. cluster.** You cannot back up an {es} cluster by making copies of the data
  139. directories of its nodes. There are no supported methods to restore any data
  140. from a filesystem-level backup. If you try to restore a cluster from such a
  141. backup, it may fail with reports of corruption or missing files or other data
  142. inconsistencies, or it may appear to have succeeded having silently lost some of
  143. your data.
  144. // end::backup-warning[]
  145. A copy of the data directories of a cluster's nodes does not work as a backup
  146. because it is not a consistent representation of their contents at a single
  147. point in time. You cannot fix this by shutting down nodes while making the
  148. copies, nor by taking atomic filesystem-level snapshots, because {es} has
  149. consistency requirements that span the whole cluster. You must use the built-in
  150. snapshot functionality for cluster backups.
  151. include::register-repository.asciidoc[]
  152. include::take-snapshot.asciidoc[]
  153. include::restore-snapshot.asciidoc[]
  154. include::../searchable-snapshots/index.asciidoc[]