|
|
@@ -248,13 +248,14 @@ $ curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -d '{
|
|
|
-----------------------------------
|
|
|
|
|
|
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
|
|
|
+<<indices-open-close,closed>> and has the same number of shards as the index in the snapshot.
|
|
|
+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
|
|
|
+==== 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
|
|
|
@@ -263,7 +264,7 @@ restored in this case and all missing shards will be recreated empty.
|
|
|
|
|
|
|
|
|
[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:
|
|
|
@@ -279,6 +280,29 @@ $ curl -XPOST "localhost:9200/_snapshot/my_backup/snapshot_1/_restore" -d '{
|
|
|
}'
|
|
|
-----------------------------------
|
|
|
|
|
|
+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
|
Igor Motov