Restoring Elasticsearch Service Data

Updated on 2024-12-27 GMT+08:00

View PDF

Scenario

Elasticsearch service data needs to be recovered in the following scenarios: Data is modified or deleted unexpectedly and needs to be restored; after an administrator performs a critical operation (such as upgrade or critical data adjustment) on Elasticsearch, an exception occurs or the operation has not achieved the expected result, causing all modules to be faulty; data is migrated to a new cluster.

This section describes how to create an Elasticsearch service data restoration task on FusionInsight Manager. The data can only be manually restored.

NOTICE:

Data can be restored only when the system version during data backup is the same as the current system version.
To restore Elasticsearch service data when services are normal, manually back up the latest service data first and then restore the service data. Otherwise, the Elasticsearch service data that is generated after the data backup and before the data recovery will be lost.
The number of index shards to be restored must be the same as the number of index shards in the snapshot.
During the restoration task execution, the indexes to be restored are automatically closed. After the restoration task is complete, the indexes are automatically opened. If the indexes to be restored do not exist, the indexes are automatically created. Therefore, service operations of the indexes may be affected during the restoration task execution.
The Elasticsearch service data restoration needs to invoke the snapshot interface through the EsNode1 instance. Therefore, ensure that all EsNode1 instances in the cluster are in good health status and can receive requests normally. To ensure successful restoration, do not perform operations such as adding, deleting, stopping, or restarting Elasticsearch instances, stopping or restarting the Elasticsearch service, or stopping or restarting the cluster.

Impact on the System

After the data is restored, the data generated after the data backup and before the data restoration is lost.
After the data is recovered, the Elasticsearch upper-layer applications need to be started.

Prerequisites

The directory for storing the Elasticsearch backup files has been checked.
The Elasticsearch upper-layer applications have been stopped.
You have prepared a standby cluster if you need to restore data remotely from HDFS. If the active cluster is deployed in security mode and the active and standby clusters are not managed by the same FusionInsight Manager, mutual trust has been configured. For details, see Configuring Cross-Manager Mutual Trust Between Clusters. If the active cluster is deployed in normal mode, no mutual trust is required.
The time on the active and standby clusters must be the same, and the NTP service on the active and standby clusters uses the same time source.

Procedure

Log in to FusionInsight Manager, and choose O&M > Backup and Restoration > Backup Management.
In the Operation column of the specified task in the task list, choose More > View History.

In the window that is displayed, select a success record and click View in the Backup Path column to view its backup path information and find the following information:
- Backup Object: indicates the backup data source.
- Backup Path: indicates the full path for storing backup files.
  Select the correct path and copy the full path of backup files in Backup Path.
Choose O&M > Backup and Restoration > Restoration Management.
Click Create.
Set Task Name to the name of the restoration task.
Select the desired cluster from Recovery Object.
In the Restoration Configuration area, select Elasticsearch under Service data.
In the displayed Elasticsearch area, set Path Type to the restoration directory type.

The following restoration directory types are supported:
- RemoteHDFS: indicates that data is restored from the HDFS directory of the standby cluster.
  If you select this option, you also need to configure the following parameters:
  - IP Mode: indicates the mode of the target IP address. The system automatically selects an IP address mode based on the cluster network type, for example, IPv4 or IPv6.
  - Source NameNode IP Address: indicates the service plane IP address of the active NameNode in the standby cluster.
  - Source Path: indicates the full path for storing backup files in HDFS, for example, Backup path/Backup task name_Data source_Task creation time.
  - Restoration Point List: Click Refresh and select an Elasticsearch snapshot that has been backed up in the standby cluster.
- NFS: indicates that backup files are obtained from the NAS through the NFS protocol. If you select this option, you also need to configure the following parameters:
  - IP Mode: indicates the mode of the target IP address. The system automatically selects an IP address mode based on the cluster network type, for example, IPv4 or IPv6.
  - Server IP Address: indicates the IP address of the NAS server.
  - Source Path: indicates the full path of the backup file on the NAS server, for example, Backup path/Backup task name_Data source_Task creation time.
  - Restoration Point List: Click Refresh and select an Elasticsearch snapshot that has been backed up in the NAS.
In the Data Configuration area, select one or more pieces of backed up data for Backup Object based on service requirements.

NOTE:

If the .security_info or .index_owner_info index is selected, disable it in advance. Otherwise, the restoration task may fail.
Specify Force recovery. The value false does not take effect. All backup data is forcibly restored when there are indexes with the same name. If the index contains data added after the backup, the new data will be lost after the data restoration.
Click Verify to check whether the restoration task is configured correctly.
- If the specified directory to be recovered does not exist, the verification fails.
- If the forcible replacement conditions are not met, the verification fails.
Click OK.
In the restoration task list, locate a created task and click Start in the Operation column to execute the restoration task.
- After the restoration is successful, the progress bar is in green.
- After the restoration is successful, the restoration task cannot be re-executed.
- If the restoration task fails during the first execution, rectify the fault and click Retry to re-execute the task.