128 lines
6.3 KiB
Plaintext
128 lines
6.3 KiB
Plaintext
[[snapshots-take-snapshot]]
|
|
== Create a snapshot
|
|
|
|
A repository can contain multiple snapshots of the same cluster. Snapshots are identified by unique names within the
|
|
cluster.
|
|
|
|
Use the <<put-snapshot-repo-api,put snapshot repository API>> to register or update a snapshot repository, and then use the <<create-snapshot-api,create snapshot API>> to create a snapshot in a repository.
|
|
|
|
The following request creates a snapshot with the name `snapshot_1` in the repository `my_backup`:
|
|
|
|
////
|
|
[source,console]
|
|
-----------------------------------
|
|
PUT /_snapshot/my_backup
|
|
{
|
|
"type": "fs",
|
|
"settings": {
|
|
"location": "my_backup_location"
|
|
}
|
|
}
|
|
-----------------------------------
|
|
// TESTSETUP
|
|
////
|
|
|
|
[source,console]
|
|
-----------------------------------
|
|
PUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true
|
|
-----------------------------------
|
|
|
|
The `wait_for_completion` parameter specifies whether or not the request should return immediately after snapshot
|
|
initialization (default) or wait for snapshot completion. During snapshot initialization, information about all
|
|
previous snapshots is loaded into memory, which means that in large repositories it may take several seconds (or
|
|
even minutes) for this request to return even if the `wait_for_completion` parameter is set to `false`.
|
|
|
|
By default, a snapshot backs up all data streams and open indices in the cluster. You can change this behavior by
|
|
specifying the list of data streams and indices in the body of the snapshot request:
|
|
|
|
[source,console]
|
|
-----------------------------------
|
|
PUT /_snapshot/my_backup/snapshot_2?wait_for_completion=true
|
|
{
|
|
"indices": "data_stream_1,index_1,index_2",
|
|
"ignore_unavailable": true,
|
|
"include_global_state": false,
|
|
"metadata": {
|
|
"taken_by": "kimchy",
|
|
"taken_because": "backup before upgrading"
|
|
}
|
|
}
|
|
-----------------------------------
|
|
// TEST[skip:cannot complete subsequent snapshot]
|
|
|
|
Use the `indices` parameter to list the data streams and indices that should be included in the snapshot. This parameter supports
|
|
<<multi-index,multi-target syntax>>, although the options that control the behavior of multi-index syntax
|
|
must be supplied in the body of the request, rather than as request parameters.
|
|
|
|
Data stream backups include the stream's backing indices and metadata, such as
|
|
the current <<data-streams-generation,generation>> and timestamp field.
|
|
|
|
You can also choose to include only specific backing indices in a snapshot.
|
|
However, these backups do not include the associated data stream's
|
|
metadata or its other backing indices.
|
|
|
|
[discrete]
|
|
[[create-snapshot-process-details]]
|
|
=== Snapshot process details
|
|
The snapshot process is incremental. In the process of making the snapshot, {es} analyses
|
|
the list of the data stream and index files that are already stored in the repository and copies only files that were created or
|
|
changed since the last snapshot. This process allows multiple snapshots to be preserved in the repository in a compact form.
|
|
|
|
The snapshot process is executed in non-blocking fashion. All indexing and searching operations can continue to run against the data stream or index
|
|
that is being snapshotted. However, a snapshot represents a point-in-time view
|
|
at the moment when snapshot was created, so no records that were added to the data stream or index after the snapshot process was started
|
|
will be included in the snapshot.
|
|
|
|
The snapshot process starts immediately for the primary shards that have been started and are not relocating at the moment. {es} waits for
|
|
relocation or initialization of shards to complete before snapshotting them.
|
|
|
|
Besides creating a copy of each data stream and index, the snapshot process can also store global cluster metadata, which includes persistent
|
|
cluster settings and templates. The transient settings and registered snapshot repositories are not stored as part of
|
|
the snapshot.
|
|
|
|
While a snapshot of a particular shard is being
|
|
created, this shard cannot be moved to another node, which can interfere with rebalancing and allocation
|
|
filtering. {es} can only move a shard to another node (according to the current allocation
|
|
filtering settings and rebalancing algorithm) after the snapshot process
|
|
is finished.
|
|
|
|
After a snapshot is created, use the <<get-snapshot-api,Get snapshot API>> to retrieve information about a snapshot. See <<snapshots-monitor-snapshot-restore,Monitor snapshot and restore progress>> to learn more about retrieving snapshot status.
|
|
|
|
[discrete]
|
|
[[create-snapshot-options]]
|
|
=== Options for creating a snapshot
|
|
The create snapshot request supports the
|
|
`ignore_unavailable` option. Setting it to `true` will cause data streams and indices that do not exist to be ignored during snapshot
|
|
creation. By default, when the `ignore_unavailable` option is not set and a data stream or index is missing, the snapshot request will fail.
|
|
|
|
By setting `include_global_state` to `false` it's possible to prevent the cluster global state to be stored as part of
|
|
the snapshot.
|
|
|
|
IMPORTANT: The global cluster state includes the cluster's index
|
|
templates, such as those <<create-a-data-stream-template,matching a data
|
|
stream>>. If your snapshot includes data streams, we recommend storing the
|
|
cluster state as part of the snapshot. This lets you later restored any
|
|
templates required for a data stream.
|
|
|
|
By default, the entire snapshot will fail if one or more indices participating in the snapshot do not have
|
|
all primary shards available. You can change this behaviour by setting `partial` to `true`. The `expand_wildcards`
|
|
option can be used to control whether hidden and closed indices will be included in the snapshot, and defaults to `all`.
|
|
|
|
Use the `metadata` field to attach arbitrary metadata to the snapshot,
|
|
such as who took the snapshot,
|
|
why it was taken, or any other data that might be useful.
|
|
|
|
Snapshot names can be automatically derived using <<date-math-index-names,date math expressions>>, similarly as when creating
|
|
new indices. Special characters must be URI encoded.
|
|
|
|
For example, use the <<create-snapshot-api,create snapshot API>> to create
|
|
a snapshot with the current day in the name, such as `snapshot-2020.07.11`:
|
|
|
|
[source,console]
|
|
-----------------------------------
|
|
PUT /_snapshot/my_backup/<snapshot-{now/d}>
|
|
PUT /_snapshot/my_backup/%3Csnapshot-%7Bnow%2Fd%7D%3E
|
|
-----------------------------------
|
|
// TEST[continued]
|
|
|
|
NOTE: You can also create snapshots that are copies of part of an existing snapshot using the <<clone-snapshot-api,clone snapshot API>>. |