Updated on 2024-11-29 GMT+08:00

Restoring Containers Metadata

Scenario

Restore Containers metadata in the following scenarios: Data is modified or deleted accidentally, or needs to be recovered; data exceptions occur or the change results are not as expected after major operations such as upgrade or data migration are performed on Containers; all modules are faulty and become unavailable; data is migrated to a new cluster.

You can create a restoration task on FusionInsight Manager to restore Containers metadata. Only manual restoration tasks are supported.

  • Data can be restored only when the system version during data backup is the same as the current system version.
  • To restore Containers metadata when services are running properly, manually back up the latest Containers metadata before restoration. Otherwise, the Containers metadata generated after the data backup and before the data restoration will be lost.
  • You are advised to restore the metadata of Containers and RTDService at the same time. If only the RTDService metadata is backed up and restored, RTDService needs to be brought offline and then online. If only the Containers metadata is backed up and restored, the service management status may be inconsistent with the running status.
  • After the Containers service is restored, if the prediction variables, model variables, and decision engines of the corresponding event sources have been brought online, you need to manually bring them online again after the restoration.

Impact on the System

  • After the metadata is restored, the data generated after the data backup and before the data restoration is lost.
  • After the metadata is restored, the upper-layer applications of Containers need to be restarted.

Prerequisites

  • You have checked the path for storing Containers metadata backup files.
  • You have prepared a standby cluster if you need to restore data remotely from HDFS. If the active cluster is deployed in security mode (with Kerberos authentication enabled) and the active and standby clusters are not managed by the same FusionInsight Manager, mutual trust must be configured. For details, see Configuring Cross-Manager Mutual Trust Between Clusters. If the active cluster is deployed in normal mode (with Kerberos authentication disabled), mutual trust is not required.

Procedure

  1. On FusionInsight Manager, choose O&M > Backup and Restoration > Backup Management.
  2. In the Operation column of the specified task in the task list, click More and select 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.

  3. On FusionInsight Manager, choose O&M > Backup and Restoration > Restoration Management.
  4. Click Create.
  5. Set Task Name to the name of the restoration task.
  6. Select the desired cluster from Recovery Object.
  7. In Restoration Configuration, select Containers under Metadata and other data.
  8. Set Path Type of Containers to a restoration directory type.

    The configurations vary based on backup directory types:

    • LocalDir: indicates that data is restored from the local disk of the active management node.

      If you select this option, you also need to set Source Path, which indicates the backup file to be restored, for example, Backup task name_Data source_Task execution time.tar.gz.

    • LocalHDFS: indicates that the backup files are stored in the HDFS directory of the current cluster.
      If you select this option, you also need to configure the following parameters:
      • Source Path: indicates the full path for storing backup files in HDFS, for example, Backup path/Backup task name_Task creation time/Version_Data source_Task execution time.tar.gz.
      • Source NameService Name: indicates the NameService name that corresponds to the backup directory when a restoration task is executed. The default value is hacluster.
    • 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:
      • Source NameService Name: indicates the NameService name of the backup data cluster, for example, hacluster. You can obtain it from the NameService Management page of HDFS of the standby cluster.
      • 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 Active NameNode IP Address: indicates the service plane IP address of the active NameNode in the standby cluster.
      • Source Standby NameNode IP Address: indicates the service plane IP address of the standby NameNode in the standby cluster.
      • Source NameNode RPC Port: indicates the value of dfs.namenode.rpc.port in the HDFS basic configuration of the destination cluster.
      • Source Path: indicates the full path of HDFS directory for storing backup data of the standby cluster, for example, Backup path/Backup task name_Data source_Task creation time/Data source_Task execution time.tar.gz.

  9. Click OK.
  10. In the restoration task list, locate the row where the created task is, and click Start in the Operation column. In the dialog box that is displayed, click OK to start 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.