anchor.diff:  
   
   [float]
  -=== Changing index settings during restore
  +==== Changing index settings during restore
   
   Most of index settings can be overridden during the restore process. For example, the following command will restore
   the index `index_1` without creating any replicas while switching back to default refresh interval:
  
positive.code: -----------------------------------
  
  The restore operation can be performed on a functioning cluster. However, an existing index can be only restored if it's
  <<indices-open-close,closed>>. The restore operation automatically opens restored indices if they were closed and creates new indices if they
  didn't exist in the cluster. If cluster state is restored, the restored templates that don't currently exist in the
  cluster are added and existing templates with the same name are replaced by the restored templates. The restored
  persistent settings are added to the existing persistent settings.
  
  [float]
  === Partial restore
  
  By default, the entire restore operation will fail if one or more indices participating in the operation don't have
  snapshots of all shards available. It can occur if some shards failed to snapshot for example. It is still possible to
  
negative.code: }'
  -----------------------------------
  
  Please note, that some settings such as `index.number_of_shards` cannot be changed during restore operation.
  
  [float]
  ==== Restoring to a different cluster
  
  The information stored in a snapshot is not tied to a particular cluster or a cluster name. Therefore it's possible to
  restore a snapshot made from one cluster into another cluster. All that is required is registering the repository
  containing the snapshot in the new cluster and starting the restore process. The new cluster doesn't have to have the
  same size or topology.  However, the version of the new cluster should be the same or newer than the cluster that was
  used to create the snapshot.
  
  If the new cluster has a smaller size additional considerations should be made. First of all it's necessary to make sure
  that new cluster have enough capacity to store all indices in the snapshot. It's possible to change indices settings
  during restore to reduce the number of replicas, which can help with restoring snapshots into smaller cluster. It's also
  possible to select only subset of the indices using the `indices` parameter.  Prior to version 1.5.0 elasticsearch
  didn't check restored persistent settings making it possible to accidentally restore an incompatible
  `discovery.zen.minimum_master_nodes` setting, and as a result disable a smaller cluster until the required number of
  master eligible nodes is added.  Starting with version 1.5.0 incompatible settings are ignored.
  
  If indices in the original cluster were assigned to particular nodes using
  <<shard-allocation-filtering,shard allocation filtering>>, the same rules will be enforced in the new cluster. Therefore
  if the new cluster doesn't contain nodes with appropriate attributes that a restored index can be allocated on, such
  index will not be successfully restored unless these index allocation settings are changed during restore operation.
  
  [float]
  === Snapshot status
  