mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-30 18:33:26 -04:00
2fde28e318
This PR expands the meaning of `include_global_state` for snapshots to include system indices. If `include_global_state` is `true` on creation, system indices will be included in the snapshot regardless of the contents of the `indices` field. If `include_global_state` is `true` on restoration, system indices will be restored (if included in the snapshot), regardless of the contents of the `indices` field. Index renaming is not applied to system indices, as system indices rely on their names matching certain patterns. If restored system indices are already present, they are automatically deleted prior to restoration from the snapshot to avoid conflicts.
This behavior can be overridden to an extent by including a new field in the snapshot creation or restoration call, `feature_states`, which contains an array of strings indicating the "feature" for which system indices should be snapshotted or restored. For example, this call will only restore the `watcher` and `security` system indices (in addition to `index_1`):
```
POST /_snapshot/my_repository/snapshot_2/_restore
{
"indices": "index_1",
"include_global_state": true,
"feature_states": ["watcher", "security"]
}
```
If `feature_states` is present, the system indices associated with those features will be snapshotted or restored regardless of the value of `include_global_state`. All system indices can be omitted by providing a special value of `none` (`"feature_states": ["none"]`), or included by omitting the field or explicitly providing an empty array (`"feature_states": []`), similar to the `indices` field.
The list of currently available features can be retrieved via a new "Get Snapshottable Features" API:
```
GET /_snapshottable_features
```
which returns a response of the form:
```
{
"features": [
{
"name": "tasks",
"description": "Manages task results"
},
{
"name": "kibana",
"description": "Manages Kibana configuration and reports"
}
]
}
```
Features currently map one-to-one with `SystemIndexPlugin`s, but this should be considered an implementation detail. The Get Snapshottable Features API and snapshot creation rely upon all relevant plugins being installed on the master node.
Further, the list of feature states included in a given snapshot is exposed by the Get Snapshot API, which now includes a new field, `feature_states`, which contains a list of the feature states and their associated system indices which are included in the snapshot. All system indices in feature states are also included in the `indices` array for backwards compatibility, although explicitly requesting system indices included in a feature state is deprecated. For example, an excerpt from the Get Snapshot API showing `feature_states`:
```
"feature_states": [
{
"feature_name": "tasks",
"indices": [
".tasks"
]
}
],
"indices": [
".tasks",
"test1",
"test2"
]
```
Co-authored-by: William Brafford <william.brafford@elastic.co>
234 lines
8.5 KiB
Text
234 lines
8.5 KiB
Text
[[restore-snapshot-api]]
|
|
=== Restore snapshot API
|
|
++++
|
|
<titleabbrev>Restore snapshot</titleabbrev>
|
|
++++
|
|
|
|
Restores a <<snapshot-restore,snapshot>> of a cluster or specified data streams and indices.
|
|
|
|
////
|
|
[source,console]
|
|
----
|
|
PUT /_snapshot/my_repository
|
|
{
|
|
"type": "fs",
|
|
"settings": {
|
|
"location": "my_backup_location"
|
|
}
|
|
}
|
|
|
|
PUT /_snapshot/my_repository/my_snapshot?wait_for_completion=true
|
|
|
|
PUT /index_1
|
|
|
|
PUT /index_2
|
|
|
|
PUT /index_3
|
|
|
|
PUT /index_4
|
|
|
|
PUT _snapshot/my_repository/snapshot_2?wait_for_completion=true
|
|
{
|
|
"indices": "index_3,index_4",
|
|
"ignore_unavailable": true,
|
|
"include_global_state": false,
|
|
"metadata": {
|
|
"taken_by": "Elastic Machine",
|
|
"taken_because": "backup testing"
|
|
}
|
|
}
|
|
|
|
POST /index_1/_close?wait_for_active_shards=0
|
|
|
|
POST /index_2/_close?wait_for_active_shards=0
|
|
|
|
POST /index_3/_close?wait_for_active_shards=0
|
|
|
|
POST /index_4/_close?wait_for_active_shards=0
|
|
|
|
----
|
|
// TESTSETUP
|
|
////
|
|
|
|
[source,console]
|
|
----
|
|
POST /_snapshot/my_repository/my_snapshot/_restore
|
|
----
|
|
// TEST[s/_restore/_restore?wait_for_completion=true/]
|
|
|
|
[[restore-snapshot-api-request]]
|
|
==== {api-request-title}
|
|
|
|
`POST /_snapshot/<repository>/<snapshot>/_restore`
|
|
|
|
[[restore-snapshot-api-prereqs]]
|
|
==== {api-prereq-title}
|
|
|
|
* If the {es} {security-features} are enabled, you must have the `manage`
|
|
<<privileges-list-cluster,cluster privilege>> to use this API.
|
|
|
|
[[restore-snapshot-api-desc]]
|
|
==== {api-description-title}
|
|
|
|
Use the restore snapshot API to restore a snapshot of a cluster, including all data streams and indices in the snapshot. If you do not want to restore the entire snapshot, you can select specific data streams or indices to restore.
|
|
|
|
NOTE: You cannot restore a data stream if a stream with the same name already
|
|
exists.
|
|
|
|
You can run the restore operation on a cluster that contains an elected
|
|
<<master-node,master node>> and has data nodes with enough capacity to accommodate the snapshot
|
|
you are restoring. Existing indices can only be restored if they are
|
|
<<indices-close,closed>> and have the same number of shards as the indices in
|
|
the snapshot. The restore operation automatically opens restored indices if
|
|
they were closed and creates new indices if they do not exist in the cluster.
|
|
|
|
If a data stream is restored, its backing indices are also restored.
|
|
Alternatively, you can restore individual backing indices without restoring an
|
|
entire data stream. If you restore individual backing indices, they are not
|
|
automatically added to any existing data stream. For example, if only the
|
|
`.ds-logs-2099.03.08-00003` backing index is restored from a snapshot, it is not
|
|
automatically added to the existing `logs` data stream.
|
|
|
|
include::{es-ref-dir}/snapshot-restore/restore-snapshot.asciidoc[tag=index-settings-data-stream-warning]
|
|
|
|
[[restore-snapshot-api-path-params]]
|
|
==== {api-path-parms-title}
|
|
|
|
`<repository>`::
|
|
(Required, string)
|
|
Name of the repository to restore a snapshot from.
|
|
|
|
`<snapshot>`::
|
|
(Required, string)
|
|
Name of the snapshot to restore.
|
|
|
|
[role="child-attributes"]
|
|
[[restore-snapshot-api-request-body]]
|
|
==== {api-request-body-title}
|
|
|
|
`ignore_unavailable`::
|
|
(Optional, Boolean)
|
|
If `false`, the request returns an error for any data stream or index that is missing or closed. Defaults to `false`.
|
|
+
|
|
If `true`, the request ignores data streams and indices in `indices` that are missing or closed.
|
|
|
|
`ignore_index_settings`::
|
|
(Optional, string)
|
|
A comma-separated list of index settings that should not be restored from a snapshot.
|
|
|
|
`include_aliases`::
|
|
(Optional, Boolean)
|
|
If `true`, index aliases from the original snapshot are restored.
|
|
Defaults to `true`.
|
|
+
|
|
If `false`, prevents aliases from being restored together with associated
|
|
indices.
|
|
|
|
[[restore-snapshot-api-include-global-state]]
|
|
`include_global_state`::
|
|
+
|
|
--
|
|
(Optional, Boolean)
|
|
If `false`, the global state is not restored. Defaults to `false`.
|
|
|
|
If `true`, the current global state is included in the restore operation.
|
|
|
|
The global state includes:
|
|
|
|
* Persistent cluster settings
|
|
* Index templates
|
|
* Legacy index templates
|
|
* Ingest pipelines
|
|
* {ilm-init} lifecycle policies
|
|
* For snapshots taken after 7.12.0, data stored in system indices, such as Watches and task records, replacing any existing configuration (configurable via `feature_states`)
|
|
--
|
|
+
|
|
IMPORTANT: By default, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available. You can change this behavior by setting <<restore-snapshot-api-partial,`partial`>> to `true`.
|
|
|
|
[[restore-snapshot-api-feature-states]]
|
|
`feature_states`::
|
|
(Optional, array of strings)
|
|
A comma-separated list of feature states you wish to restore. Each feature state contains one or more system indices. The list of feature states
|
|
available in a given snapshot are returned by the <<get-snapshot-api-feature-states, Get Snapshot API>>. Note that feature
|
|
states restored this way will completely replace any existing configuration, rather than returning an error if the system index already exists.
|
|
Providing an empty array will restore no feature states, regardless of the value of `include_global_state`.
|
|
+
|
|
By default, all available feature states will be restored if `include_global_state` is `true`, and no feature states will be restored if
|
|
`include_global_state` is `false`.
|
|
|
|
[[restore-snapshot-api-index-settings]]
|
|
`index_settings`::
|
|
(Optional, string)
|
|
A comma-separated list of settings to add or change in all restored indices. Use this parameter to override index settings when restoring snapshots.
|
|
+
|
|
For data streams, these index settings are applied to the restored backing
|
|
indices.
|
|
+
|
|
For more information regarding all the different index-level settings
|
|
that you can specify, see
|
|
<<index-modules,index modules>>.
|
|
|
|
`indices`::
|
|
(Optional, string)
|
|
A comma-separated list of data streams and indices to restore from the snapshot.
|
|
<<multi-index,Multi-index syntax>> is supported.
|
|
+
|
|
By default, a restore operation includes all data streams and indices in the snapshot. If this
|
|
argument is provided, the restore operation only includes the specified data streams and indices.
|
|
|
|
[[restore-snapshot-api-partial]]
|
|
`partial`::
|
|
(Optional, Boolean)
|
|
If `false`, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available. Defaults to `false`.
|
|
+
|
|
If `true`, allows restoring a partial snapshot of indices with unavailable shards. Only shards that were successfully included in the snapshot
|
|
will be restored. All missing shards will be recreated as empty.
|
|
|
|
[[restore-snapshot-api-rename-pattern]]
|
|
`rename_pattern`::
|
|
(Optional, string)
|
|
Defines a rename pattern to apply to restored data streams and indices. Data streams and indices matching the rename pattern will be renamed according to
|
|
<<restore-snapshot-api-rename-replacement,`rename_replacement`>>.
|
|
+
|
|
The rename pattern is applied as defined by the regular expression that
|
|
supports referencing the original text, according to the https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html#appendReplacement-java.lang.StringBuffer-java.lang.String-[`appendReplacement`] logic.
|
|
+
|
|
The request will fail if two or more data streams or indices will be renamed into the same name.
|
|
+
|
|
include::{es-ref-dir}/snapshot-restore/restore-snapshot.asciidoc[tag=rename-restored-data-stream-tag]
|
|
|
|
[[restore-snapshot-api-rename-replacement]]
|
|
`rename_replacement`::
|
|
(Optional, string)
|
|
Defines the rename replacement string. See <<restore-snapshot-api-rename-pattern,`rename_pattern`>> for more information.
|
|
|
|
`wait_for_completion`::
|
|
(Optional, Boolean)
|
|
If `false`, the request returns a response when the restore operation initializes.
|
|
Defaults to `false`.
|
|
+
|
|
If `true`, the request returns a response when the restore operation
|
|
completes.
|
|
|
|
[[restore-snapshot-api-example]]
|
|
==== {api-examples-title}
|
|
|
|
The following request restores `index_1` and `index_2` from `snapshot_2`. The `rename_pattern` and `rename_replacement` parameters indicate any index matching the regular expression `index_(.+)` will be renamed using the pattern `restored_index_$1` when restored.
|
|
|
|
For example, `index_1` will be renamed to `restored_index_1`. `index_2` will be renamed to `restored_index_2`.
|
|
|
|
[source,console]
|
|
----
|
|
POST /_snapshot/my_repository/snapshot_2/_restore?wait_for_completion=true
|
|
{
|
|
"indices": "index_1,index_2",
|
|
"ignore_unavailable": true,
|
|
"include_global_state": false,
|
|
"rename_pattern": "index_(.+)",
|
|
"rename_replacement": "restored_index_$1",
|
|
"include_aliases": false
|
|
}
|
|
----
|
|
|
|
The API returns an acknowledgement if the request succeeds. If the request encounters errors, the response indicates any issues found, such as
|
|
open indices that are blocking the restore operation from completing.
|