Updated on 2025-07-29 GMT+08:00

Restoring the Data of an Elasticsearch Cluster Using a Snapshot

Restore the data captured by a cluster snapshot to the current cluster or another eligible cluster.

Constraints

  • Cluster snapshots will increase CPU usage and disk I/O. You are advised to take cluster snapshots during off-peak hours.
  • If a cluster is in the Unavailable state, you can use the cluster snapshot function only to restore the cluster or view snapshot information.
  • While you are creating a snapshot for a cluster or restoring it using one, you can perform certain operations, including scaling out the cluster (except when the cluster is the destination of a restoration operation), accessing Kibana, viewing metrics, and deleting other snapshots. However, you cannot perform the following operations: restarting or deleting the cluster, deleting a snapshot that is in the Creating or Restoring state, and creating or restoring another snapshot. While a snapshot is being created or restored for a cluster, any automatic snapshot creation task initiated for that cluster will be canceled.
  • Cluster data cannot be queried during snapshot restoration.
  • The destination and source clusters must have the same shards.
  • The version of the destination cluster must be the same as or later than that of the source cluster.

Prerequisites

  • The snapshot list contains snapshots whose Snapshot Status is Available. Storing snapshots in an OBS bucket may incur additional fees. For details, see OBS Billing Overview.

Restoring Data

  1. Log in to the CSS management console.
  2. In the navigation pane on the left, select a cluster type under Clusters. On the displayed cluster list page, click the target cluster name to go to the Cluster Information page.
  3. In the navigation pane on the left, choose Cluster Snapshots.
  4. In the Snapshots area, locate the row that contains the snapshot you want to restore and click Restore in the Operation column.
    Figure 1 Selecting a snapshot
  5. On the Restore page, set restoration parameters.
    Table 1 Restoration settings

    Parameter

    Description

    Index

    Specify the name of the index you want to restore.

    Constraints:

    • The value is a string of 0 to 1024 characters that cannot contain uppercase letters, spaces, or the following special characters: "\<|>/?.
    • When restoring an index whose name is prefixed with .kibana, the index name must be specified.
    • The .opendistro_security index cannot be restored.

    Value range:

    • You can use an asterisk (*) to match multiple indexes. For example, index* indicates that all indexes with the prefix index will be restored. When an asterisk (*) is used for index matching, the .opendistro_security index and any system indexes whose name is prefixed with .kibana are filtered out by default.
    • You can restore indexes by specifying their names, for example, index1,index2,index3.

    Default value:

    By default, this parameter is left blank. That is, no index name is specified, and all indexes will be restored.

    Rename Pattern

    Index name matching rule. Enter a regular expression. Indexes that match the regular expression will be restored. The default value index_(.+) indicates all indexes. The value is a string of 0 to 1024 characters that cannot contain uppercase letters, spaces, or the following special characters: "\<|>/?,.

    NOTE:

    The Rename Pattern and Rename Replacement take effect only when they are both configured at the same time.

    Rename Replacement

    Rule for index renaming. The default value restored_index_$1 indicates that restored_ will be added to the beginning of the names of all restored indexes. The value is a string of 0 to 1024 characters that cannot contain uppercase letters, spaces, or the following special characters: "\<|>/?,.

    NOTE:

    The Rename Pattern and Rename Replacement take effect only when they are both configured at the same time.

    Cluster

    Select the cluster where you want to restore the data to. You can select the current cluster or another.

    • You must specify a cluster whose status is Available. If the status of the current cluster is Unavailable, you cannot restore the snapshot to the current cluster.
    • When you choose to restore data to another cluster, make sure the target cluster has the same or later version than the current cluster, and that the two clusters are in the same region. After a frozen index is restored using a snapshot, the index is stored on the local node and is read-only by default. To make it writable, run the following command to configure the index:
      PUT index_name/_settings
      {
        "index.blocks.write": null
      }
    • Select or deselect Overwrite same-name indexes in the destination cluster. Data restoration using snapshots works by overwriting existing snapshot files. When there are same-name indexes in the destination cluster, you need to select this option in order to restore same-name, same-shard structure indexes. Indexes with a different shard structure cannot be restored. Exercise caution when performing this operation.
  6. Click OK. If restoration succeeds, Task Status of the snapshot in the snapshot list will change to Restoration succeeded, and the data of indexes is generated according to the snapshot information.