anchor.diff:  [float]
   === Stopping currently running snapshot and restore operations
   
  -The snapshot and restore framework allows running only one snapshot or one restore operation at a time. If currently
  -running snapshot was executed by mistake or takes unusually long, it can be terminated using snapshot delete operation.
  -The snapshot delete operation checks if deleted snapshot is currently running and if it does, the delete operation stops
  -such snapshot before deleting the snapshot data from the repository.
  +The snapshot and restore framework allows running only one snapshot or one restore operation at a time. If a currently
  +running snapshot was executed by mistake, or takes unusually long, it can be terminated using the snapshot delete operation.
  +The snapshot delete operation checks if the deleted snapshot is currently running and if it does, the delete operation stops
  +that snapshot before deleting the snapshot data from the repository.
   
   The restore operation uses the standard shard recovery mechanism. Therefore, any currently running restore operation can
   be canceled by deleting indices that are being restored. Please note that data for all deleted indices will be removed
  
positive.code: previous snapshots is loaded into the memory, which means that in large repositories it may take several seconds (or
  even minutes) for this command to return even if the `wait_for_completion` parameter is set to `false`.
  
  By default snapshot of all open and started indices in the cluster is created. This behavior can be changed by
  specifying the list of indices in the body of the snapshot request.
  
  [source,js]
  
negative.code: changed since the last snapshot. That allows multiple snapshots to be preserved in the repository in a compact form.
  Snapshotting process is executed in non-blocking fashion. All indexing and searching operation can continue to be
  executed against the index that is being snapshotted. However, a snapshot represents the point-in-time view of the index
  at the moment when snapshot was created, so no records that were added to the index after the snapshot process was started
  will be present in the snapshot. The snapshot process starts immediately for the primary shards that has been started
  and are not relocating at the moment. Elasticsearch waits for
  relocation or initialization of shards to complete before snapshotting them.
  