Monitor snapshot and restore progress

Use the get snapshot API or the get snapshot status API to monitor the progress of snapshot operations. Both APIs support the wait_for_completion parameter that blocks the client until the operation finishes, which is the simplest method of being notified about operation completion.

Use the _current parameter to retrieve all currently running snapshots in the cluster:

GET /_snapshot/my_backup/_current

Including a snapshot name in the request retrieves information about a single snapshot:

GET /_snapshot/my_backup/snapshot_1

This request retrieves basic information about the snapshot, including start and end time, version of Elasticsearch that created the snapshot, the list of included indices, the current state of the snapshot and the list of failures that occurred during the snapshot.

Similar to repositories, you can retrieve information about multiple snapshots in a single request, and wildcards are supported:

GET /_snapshot/my_backup/snapshot_*,some_other_snapshot

Separate repository names with commas or use wildcards to retrieve snapshots from multiple repositories:

GET /_snapshot/_all
GET /_snapshot/my_backup,my_fs_backup
GET /_snapshot/my*

Add the _all parameter to the request to list all snapshots currently stored in the repository:

GET /_snapshot/my_backup/_all

This request fails if some of the snapshots are unavailable. Use the boolean parameter ignore_unavailable to return all snapshots that are currently available.

Getting all snapshots in the repository can be costly on cloud-based repositories, both from a cost and performance perspective. If the only information required is the snapshot names or UUIDs in the repository and the indices in each snapshot, then the optional boolean parameter verbose can be set to false to execute a more performant and cost-effective retrieval of the snapshots in the repository.

To retrieve more detailed information about snapshots, use the get snapshot status API. While snapshot request returns only basic information about the snapshot in progress, the snapshot status request returns complete breakdown of the current state for each shard participating in the snapshot.

The following request retrieves all currently running snapshots with detailed status information:

GET /_snapshot/_status

By specifying a repository name, it’s possible to limit the results to a particular repository:

GET /_snapshot/my_backup/_status

If both repository name and snapshot name are specified, the request returns detailed status information for the given snapshot, even if not currently running:

GET /_snapshot/my_backup/snapshot_1/_status

The restore process piggybacks on the standard recovery mechanism of Elasticsearch. As a result, standard recovery monitoring services can be used to monitor the state of restore. When the restore operation starts, the cluster typically goes into yellow state because the restore operation works by recovering primary shards of the restored indices. After the recovery of the primary shards is completed, Elasticsearch switches to the standard replication process that creates the required number of replicas. When all required replicas are created, the cluster switches to the green states.

The cluster health operation provides only a high level status of the restore process. It’s possible to get more detailed insight into the current state of the recovery process by using index recovery and cat recovery APIs.

The snapshot and restore framework allows running only one snapshot or one restore operation at a time. If a currently running snapshot was started by mistake, or takes unusually long, it can be stopped using the delete snapshot API. This operation checks whether the deleted snapshot is currently running. If it is, the delete snapshot operation stops that snapshot before deleting the snapshot data from the repository.

DELETE /_snapshot/my_backup/snapshot_1

The restore operation uses the standard shard recovery mechanism. Therefore, any currently running restore operation can be canceled by deleting indices that are being restored. Data for all deleted indices will be removed from the cluster as a result of this operation.

Many snapshot and restore operations are affected by cluster and index blocks. For example, registering and unregistering repositories require global metadata write access. The snapshot operation requires that all indices, backing indices, and their metadata (including global metadata) are readable. The restore operation requires the global metadata to be writable. However, the index level blocks are ignored during restore because indices are essentially recreated during restore. A repository content is not part of the cluster and therefore cluster blocks do not affect internal repository operations such as listing or deleting snapshots from an already registered repository.