anchor.diff:  -----------------------------------
   // CONSOLE
   
  -If a repository name is not specified, or `_all` is used as repository name Elasticsearch will return information about
  -all repositories currently registered in the cluster:
  +To retrieve information about all registered snapshot repositories, omit the
  +repository name or specify `_all`:
   
   [source,js]
   -----------------------------------
  
positive.code: -----------------------------------
  // TESTRESPONSE
  
  Information about multiple repositories can be fetched in one go by using a comma-delimited list of repository names.
  Star wildcards are supported as well. For example, information about repositories that start with `repo` or that contain `backup`
  can be obtained using the following command:
  
  [source,js]
  -----------------------------------
  
negative.code: [[modules-snapshots]]
  == Snapshot And Restore
  
  You can store snapshots of individual indices or an entire cluster in
  a remote repository like a shared file system, S3, or HDFS. These snapshots
  are great for backups because they can be restored relatively quickly. However,
  snapshots can only be restored to versions of Elasticsearch that can read the
  indices:
  
  * A snapshot of an index created in 5.x can be restored to 6.x.
  * A snapshot of an index created in 2.x can be restored to 5.x.
  * A snapshot of an index created in 1.x can be restored to 2.x.
  
  Conversely, snapshots of indices created in 1.x **cannot** be restored to
  5.x or 6.x, and snapshots of indices created in 2.x **cannot** be restored
  to 6.x.
  
  Snapshots are incremental and can contain indices created in various
  versions of Elasticsearch. If any indices in a snapshot were created in an
  incompatible version, you will not be able restore the snapshot.
  
  IMPORTANT: When backing up your data prior to an upgrade, keep in mind that you
  won't be able to restore snapshots after you upgrade if they contain indices
  created in a version that's incompatible with the upgrade version.
  
  If you end up in a situation where you need to restore a snapshot of an index
  that is incompatible with the version of the cluster you are currently running,
  you can restore it on the latest compatible version and use
  <<reindex-from-remote,reindex-from-remote>> to rebuild the index on the current
  version. Reindexing from remote is only possible if the original index has
  source enabled. Retrieving and reindexing the data can take significantly longer
  than simply restoring a snapshot. If you have a large amount of data, we
  recommend testing the reindex from remote process with a subset of your data to
  understand the time requirements before proceeding.
  
  [float]
  === Repositories
  
  You must register a snapshot repository before you can perform snapshot and
  restore operations. We recommend creating a new snapshot repository for each
  major version. The valid repository settings depend on the repository type.
  
  If you register same snapshot repository with multiple clusters, only
  one cluster should have write access to the repository. All other clusters
  connected to that repository should set the repository to `readonly` mode.
  
  NOTE: The snapshot format can change across major versions, so if you have
  clusters on different major versions trying to write the same repository,
  new snapshots written by one version will not be visible to the other. While
  setting the repository to `readonly` on all but one of the clusters should work
  with multiple clusters differing by one major version, it is not a supported
  configuration.
  
  [source,js]
  -----------------------------------
  