Docs
ues
Elasticsearch
Data Backup and Recovery
Data Recovery

Data Recovery

If the data backup function of UES is used to generate a snapshot of the cluster, the snapshot API of Elasticsearch(ES for short) can be used to restore the data in the snapshot to the specified UES cluster. (The data recovery method described below is also applicable to UES cluster snapshots generated by other means.)

Preparation

1. Verify that the snapshot repository is accessible

If you need to restore data from a snapshot generated using the UES data backup function, you must ensure the following:

(1) The US3 storage space bound at the time of repository registration can be accessed normally, and the snapshot files stored in it are intact.

(2) The token used for authorization access to the aforementioned US3 storage space bound when registering the repository is in normal status, i.e. it has not been deleted since the repository creation, has all necessary permissions such as upload, download, delete, file list, and is currently valid.

2. Confirm whether the version of the snapshot is compatible with the version of the target UES cluster

Since the index data structure of different versions of UES clusters may differ, the index data in the snapshot can only be restored to UES clusters that can correctly identify and read these indexes. Regarding the compatibility of snapshot versions and cluster versions, the basic rules given by Elastic are: it can be restored normally when versions are the same, and the snapshots created by lower version clusters can be restored to higher version clusters with major version number differences not exceeding 1, i.e.:

(1) Snapshots created in 6.x version clusters can be restored to 7.x version clusters.

(2) Snapshots created in 5.x version clusters can be restored to 6.x version clusters.

(3) Snapshots created in 2.x version clusters can be restored to 5.x version clusters.

(4) Snapshots created in 1.x version clusters can be restored to 2.x version clusters.

Apart from this, snapshots created by high version clusters cannot be restored to low version clusters, and snapshots created by low version clusters cannot be restored to high version clusters that span 2 or more major version numbers.

The version information of the snapshots generated using the UES data backup function can be viewed through the UES console: Data Backup -> Snapshot Management -> Snapshot Details, or the “View all snapshots in the specified repository” command introduced below.

Operation Steps

The operation steps described below are performed in the Kibana Console of the UES cluster. Function Entrance: Log in to the UES Console, click on the “Open Kibana” button on the right side of the target cluster in the cluster list, enter the Kibana Console, click on Dev Tools in the left navigation bar, and enter and execute the appropriate commands in the Console box.

Note: In the command examples below, the content in the angle brackets < > needs to be replaced with the corresponding content (remove the angle brackets).

1. View all snapshot repositories of the current cluster

Command example:

GET /_snapshot/_all

Command return result example:

ParameterDescription
my_first_repositoryRepository name, to be used in subsequent commands.
typeType of the storage system of the repository, “ufile” indicates the use of US3 object storage.
bucketThe name of the US3 storage space in which the repository is located.
base_pathThe storage path of the snapshot in the aforementioned US3 storage space.

2. View all snapshots in the specified repository

Command example:

GET /_snapshot/<my_first_repository>/_all

Command return result example:

ParameterDescription
snapshotSnapshot name, to be used in subsequent commands.
versionSnapshot version, this can be used to judge compatibility with the cluster.
indicesIndices included in the snapshot, you can specify to restore only part of the indices when recovering.

3. Recover index data from specified snapshot

Note: If the index to be recovered already exists in the target cluster, make sure that this index has been closed, and it has the same number of shards as the index with the same name in the snapshot, otherwise the recovery operation cannot be executed.

Command example:

POST /_snapshot/<my_first_repository>/<daily_backup_202003281600>/_restore

Command return result example:

Since this command is asynchronous, the data recovery task will be executed in the background once the above information is returned. If you wish to monitor the data recovery process, you can add the wait_for_completion parameter after the above command, which will block the client until the operation is completed and then return information.

Command example with more parameters:

POST /_snapshot/<my_first_repository>/<daily_backup_202003281600>/_restore?wait_for_completion=true
{
    "indices": "index_2,index_3",
    "ignore_unavailable": true,
    "include_global_state": true,
    "rename_pattern": "index_(.+)",
    "rename_replacement": "restored_index_$1"
}
ParameterDescription
indicesSpecifies the snapshot name that needs to be restored, supports multi-index syntax.
ignore_unavailableControls whether to ignore unavailable index.
include_global_stateControls whether to restore the global state of the cluster.
rename_patternUse regular expressions to match indexes to be renamed.
rename_replacementSpecifies the renaming rule.

Command return result example:

Reference Information

For more information on creating snapshots, restoring data from snapshots, querying snapshot information, etc., please refer to the official Elasticsearch documentation:

Snapshot And Restore