anchor.diff:  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. However, snapshots
  -are also logically independent: deleting a snapshot does not affect the
  +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.
  -// end::snapshot-intro[]
   
   // tag::restore-intro[]
   You can <<snapshots-restore-snapshot,restore snapshots>> to a running cluster, which includes all data streams and indices in the snapshot
  
positive.code: include::delete-snapshot.asciidoc[]
  include::../slm/index.asciidoc[]
  include::../searchable-snapshots/index.asciidoc[]
  
  
negative.code: to automatically take and manage snapshots.
  
  // tag::backup-warning[]
  WARNING: **The only reliable and supported way to back up a cluster is by
  taking a snapshot**. You cannot back up an {es} cluster by making copies of the
  data directories of its nodes. There are no supported methods to restore any
  data from a filesystem-level backup. If you try to restore a cluster from such
  a backup, it may fail with reports of corruption or missing files or other data
  inconsistencies, or it may appear to have succeeded having silently lost some
  of your data.
  // end::backup-warning[]
  
  A copy of the data directories of a cluster's nodes does not work as a backup
  because it is not a consistent representation of their contents at a single
  point in time. You cannot fix this by shutting down nodes while making the
  copies, nor by taking atomic filesystem-level snapshots, because {es} has
  consistency requirements that span the whole cluster. You must use the built-in
  snapshot functionality for cluster backups.
  
  [discrete]
  [[snapshot-restore-version-compatibility]]
  