anchor.diff:  include::delete-snapshot.asciidoc[]
   include::../slm/index.asciidoc[]
   include::../searchable-snapshots/index.asciidoc[]
  -
  
positive.code: to automatically take and manage snapshots.
  
  // tag::backup-warning[]
  WARNING: You cannot back up an {es} cluster by simply copying
  the data directories of all of its nodes. {es} 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::backup-warning[]
  
  [discrete]
  [[snapshot-restore-version-compatibility]]
  
negative.code: Remote repositories can reside on Amazon S3, HDFS, Microsoft Azure,
  Google Cloud Storage,
  and other platforms supported by a {plugins}/repository.html[repository plugin].
  // end::snapshot-intro[]
  
  {es} takes snapshots incrementally: the snapshotting process only copies data
  to the repository that was not already copied there by an earlier snapshot,
  avoiding unnecessary duplication of work or storage space. This means you can
  safely take snapshots very frequently with minimal overhead. This
  incrementality only applies within a single repository because no data is
  shared between repositories. Snapshots are also logically independent from each
  other, even within a single repository: deleting a snapshot does not affect the
  integrity of any other snapshot.
  
  // tag::restore-intro[]
  You can <<snapshots-restore-snapshot,restore snapshots>> to a running cluster, which includes all data streams and indices in the snapshot
  