IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Clean up snapshot repository API Get snapshot API »

› › ›

Create snapshot API

edit

Create snapshot API

edit

Takes a snapshot of a cluster or specified indices.

PUT /_snapshot/my_repository/my_snapshot

Request

edit

PUT /_snapshot/<repository>/<snapshot>

POST /_snapshot/<repository>/<snapshot>

Description

edit

You can use the create snapshot API to create a snapshot, which is a backup taken from a running Elasticsearch cluster.

By default, a snapshot includes all open indices in the cluster, as well as the cluster state. You can change this behavior by specifying a list of indices to back up in the body of the snapshot request.

You must register a snapshot before performing snapshot and restore operations. Use the put snapshot repository API to register new repositories and update existing ones.

The snapshot process is incremental. When creating a snapshot, Elasticsearch analyzes the list of 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, so all indexing and searching operations can run concurrently against the index that Elasticsearch is snapshotting. Only one snapshot process can run in the cluster at any time.

A snapshot represents a point-in-time view of the moment when the snapshot was created. No records that were added to an index after the snapshot process started will be present in the snapshot.

For primary shards that have not been started and are not currently relocating, the snapshot process starts immediately. If shards are in the process of starting or relocating, Elasticsearch waits for these processes to complete before taking a snapshot.

While a snapshot of a particular shard is being created, this shard cannot be moved to another node. Relocating a shard during the snapshot process can interfere with rebalancing and allocation filtering. Elasticsearch can move a shard to another node (according to the current allocation filtering settings and rebalancing algorithm) only after the snapshot process completes.

Besides creating a copy of each index, the snapshot process can also store global cluster metadata, including persistent cluster settings and templates. The transient settings and registered snapshot repositories are not stored as part of the snapshot.

Path parameters

edit

<repository>: (Required, string) Name of the repository to create a snapshot in.
<snapshot>: (Required, string) Name of the snapshot to create. This name must be unique in the snapshot repository.

Request body

edit

ignore_unavailable

(Optional, boolean) If false, the request returns an error for any index that is missing or closed. Defaults to false.

If true, the request ignores and indices in indices that are missing or closed.

indices

(Optional, string) A comma-separated list of indices to include in the snapshot. Multi-index syntax is supported.

By default, a snapshot includes all indices in the cluster. If this argument is provided, the snapshot only includes the specified clusters.

include_global_state

(Optional, boolean) If true, the current cluster state is included in the snapshot. Defaults to true.

The cluster state includes:

Persistent cluster settings
Index templates
Legacy index templates
Ingest pipelines
ILM lifecycle policies

By default, the entire snapshot 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 partial to true.

master_timeout

(Optional, time units) Specifies the period of time to wait for a connection to the master node. If no response is received before the timeout expires, the request fails and returns an error. Defaults to 30s.

metadata

(Optional, string) Attaches arbitrary metadata to the snapshot, such as a record of who took the snapshot, why it was taken, or any other useful data. Metadata must be less than 1024 bytes.

partial

(Optional, boolean) If false, the entire snapshot will fail if one or more indices included in the snapshot do not have all primary shards available. Defaults to false.

If true, allows taking a partial snapshot of indices with unavailable shards.

wait_for_completion

(Optional, boolean) If true, the request returns a response when the snapshot is complete. If false, the request returns a response when the snapshot initializes. Defaults to false.

During snapshot initialization, information about all previous snapshots is loaded into memory. In large repositories, this load time can cause requests to take several seconds (or even minutes) to return a response, even if the wait_for_completion parameter is false.

Examples

edit

The following request takes a snapshot of index_1 and index_2.

PUT /_snapshot/my_repository/snapshot_2?wait_for_completion=true
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "user123",
    "taken_because": "backup before upgrading"
  }
}

The API returns the following response:

{
  "snapshot": {
    "snapshot": "snapshot_2",
    "uuid": "vdRctLCxSketdKb54xw67g",
    "version_id": <version_id>,
    "version": <version>,
    "indices": [],
    "include_global_state": false,
    "metadata": {
      "taken_by": "user123",
      "taken_because": "backup before upgrading"
    },
    "state": "SUCCESS",
    "start_time": "2020-06-25T14:00:28.850Z",
    "start_time_in_millis": 1593093628850,
    "end_time": "2020-06-25T14:00:28.850Z",
    "end_time_in_millis": 1593094752018,
    "duration_in_millis": 0,
    "failures": [],
    "shards": {
      "total": 0,
      "failed": 0,
      "successful": 0
    }
  }
}

« Clean up snapshot repository API Get snapshot API »