Restore indices from a snapshotedit

Use the restore snapshot API to restore a snapshot of a cluster or specified indices:

POST /_snapshot/my_backup/snapshot_1/_restore

By default, all indices in the snapshot are restored, but the cluster state is not restored. Use the indices parameter to restore only specific indices. This parameter supports multi-target syntax. To include the global cluster state, set include_global_state to true in the restore request body.

The rename_pattern and rename_replacement options can be also used to rename indices on restore using regular expression that supports referencing the original text, according to the appendReplacement logic.


POST /_snapshot/my_backup/snapshot_1/_restore
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false,              
  "rename_pattern": "index_(.+)",
  "rename_replacement": "restored_index_$1",
  "include_aliases": false

By default, include_global_state is false, meaning the snapshot’s cluster state is not restored.

If true, the snapshot’s persistent settings, index templates, ingest pipelines, and ILM policies are restored into the current cluster. This overwrites any existing cluster settings, templates, pipelines and ILM policies whose names match those in the snapshot.


Partial restoreedit


Changing index settings during restoreedit

Use the index_settings parameter to override index settings during the restore process. For example, the following request will restore the index index_1 without creating any replicas while switching back to the default refresh interval:

POST /_snapshot/my_backup/snapshot_1/_restore
  "indices": "index_1",
  "ignore_unavailable": true,
  "index_settings": {
    "index.number_of_replicas": 0
  "ignore_index_settings": [

Some settings such as index.number_of_shards cannot be changed during the restore operation.

Restoring to a different clusteredit

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 created from one cluster into another cluster by registering the repository that contains the snapshot in the new cluster and starting the restore process.

The topology of the new cluster does not have to match the cluster where the snapshot was created. However, the version of the new cluster must be the same or only one major version newer than the cluster that was used to create the snapshot. For example, you can restore a 5.x snapshot to a 6.x cluster, but not a 5.x snapshot to a 7.x cluster.

If the new cluster has a smaller capacity, consider the following changes:

  • Ensure that the new cluster has enough capacity to store all indices in the snapshot.
  • Change the index settings during the restore operation to reduce the number of replicas.
  • Use the indices parameter to choose only specific indices to restore.

If indices or backing indices in the original cluster were assigned to particular nodes using shard allocation filtering, the same rules will be enforced in the new cluster. If the new cluster does not contain nodes with appropriate attributes that a restored index can be allocated on, the index will not be successfully restored unless these index allocation settings are changed during the restore operation.
