Skip to main content
本产品推出了新版本。
简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

将对象数据还原到系统驱动器完好无损的存储卷

贡献者

在系统驱动器完好无损的存储节点上恢复存储卷后,您可以还原存储卷发生故障时丢失的对象数据。

您需要的内容
  • 您必须确认已恢复的存储节点的连接状态为 * 已连接 图标警报绿色复选标记 在网格管理器的*节点>*概述*选项卡上。

关于此任务

可以从其他存储节点,归档节点或云存储池还原对象数据,前提是已配置网格的 ILM 规则,以便可以使用对象副本。

重要说明 如果 ILM 规则配置为仅存储一个复制副本,而该副本位于出现故障的存储卷上,则您将无法恢复对象。
重要说明 如果某个对象的唯一剩余副本位于云存储池中,则 StorageGRID 必须将多个请求问题描述 到云存储池端点以还原对象数据。在执行此操作步骤 之前,请联系技术支持以帮助估算恢复时间范围和相关成本。
备注 如果对象的唯一剩余副本位于归档节点上,则会从归档节点检索对象数据。由于从外部归档存储系统检索数据会产生延迟、因此从归档节点将对象数据还原到存储节点所需的时间比从其他存储节点还原副本要长。

要还原对象数据、请运行 repair-data 脚本。此脚本将开始还原对象数据的过程,并与 ILM 扫描配合使用以确保满足 ILM 规则。您可以对使用不同的选项 repair-data 脚本、根据您是还原复制的数据还是删除编码的数据、如下所示:

  • 复制数据:根据您是需要修复整个节点还是仅修复节点上的特定卷、可以使用两个命令来还原复制的数据:

    repair-data start-replicated-node-repair
    repair-data start-replicated-volume-repair
  • 擦除编码(EC)数据:根据您是需要修复整个节点还是仅修复节点上的特定卷、可以使用两个命令来还原擦除编码的数据:

    repair-data start-ec-node-repair
    repair-data start-ec-volume-repair

    在某些存储节点脱机时、可以开始修复擦除编码的数据。修复将在所有节点均可用后完成。您可以使用以下命令跟踪纠删编码数据的修复情况:

    repair-data show-ec-repair-status
备注 EC 修复作业会临时预留大量存储。可能会触发存储警报,但会在修复完成后解决。如果没有足够的存储空间用于预留, EC 修复作业将失败。无论作业失败还是成功, EC 修复作业完成后都会释放存储预留。

有关使用的详细信息、请参见 repair-data 脚本、输入 repair-data --help 从主管理节点的命令行。

步骤
  1. 登录到主管理节点:

    1. 输入以下命令: ssh admin@primary_Admin_Node_IP

    2. 输入中列出的密码 Passwords.txt 文件

    3. 输入以下命令切换到root: su -

    4. 输入中列出的密码 Passwords.txt 文件

      以root用户身份登录后、提示符将从变为 $ to #

  2. 使用 /etc/hosts file、用于查找已还原存储卷的存储节点的主机名。要查看网格中所有节点的列表、请输入以下内容: cat /etc/hosts

  3. 如果所有存储卷都发生故障,请修复整个节点。(如果只有部分卷出现故障、请转至下一步。)

    重要说明 您无法运行 repair-data 同时对多个节点执行的操作。要恢复多个节点,请联系技术支持。
    • 如果您的网格包含复制的数据、请使用 repair-data start-replicated-node-repair 命令 --nodes 用于修复整个存储节点的选项。

      此命令将修复名为 SG-DC-SN3 的存储节点上复制的数据:

      repair-data start-replicated-node-repair --nodes SG-DC-SN3
      备注 还原对象数据后,如果 StorageGRID 系统找不到复制的对象数据,则会触发 * 对象丢失 * 警报。可能会在整个系统的存储节点上触发警报。您应确定丢失的发生原因 以及是否可以恢复。请参见有关 StorageGRID 监控和故障排除的说明。
    • 如果网格包含纠删编码数据、请使用 repair-data start-ec-node-repair 命令 --nodes 用于修复整个存储节点的选项。

      此命令将修复名为SG-DC-SN3的存储节点上的纠删编码数据:

      repair-data start-ec-node-repair --nodes SG-DC-SN3

      此操作将返回唯一 repair ID 这就说明了这一点 repair_data 操作。请使用此 repair ID 跟踪的进度和结果 repair_data 操作。恢复过程完成后,不会返回任何其他反馈。

    备注 在某些存储节点脱机时、可以开始修复擦除编码的数据。修复将在所有节点均可用后完成。
    • 如果您的网格同时包含复制的数据和纠删编码的数据、请运行这两个命令。

  4. 如果只有部分卷出现故障,请修复受影响的卷。

    以十六进制格式输入卷 ID 。例如: 0000 是第一个卷和 000F 是第16个卷。您可以指定一个卷,一个卷范围或多个不属于一个序列的卷。

    所有卷必须位于同一个存储节点上。如果需要还原多个存储节点的卷,请联系技术支持。

    • 如果网格包含复制的数据、请使用 start-replicated-volume-repair 命令 --nodes 用于标识节点的选项。然后添加 --volumes--volume-range 选项、如以下示例所示。

      单个卷:此命令可将复制的数据还原到卷 0002 在名为SG-DC-SN3的存储节点上:

      repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0002

      卷范围:此命令会将复制的数据还原到范围内的所有卷 0003 to 0009 在名为SG-DC-SN3的存储节点上:

      repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volume-range 0003-0009

      多个卷不在一个序列中:此命令会将复制的数据还原到卷 00010005,和 0008 在名为SG-DC-SN3的存储节点上:

      repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0001,0005,0008
      备注 还原对象数据后,如果 StorageGRID 系统找不到复制的对象数据,则会触发 * 对象丢失 * 警报。可能会在整个系统的存储节点上触发警报。您应确定丢失的发生原因 以及是否可以恢复。请参见有关 StorageGRID 监控和故障排除的说明。
    • 如果网格包含纠删编码数据、请使用 start-ec-volume-repair 命令 --nodes 用于标识节点的选项。然后添加 --volumes--volume-range 选项、如以下示例所示。

      单个卷:此命令可将擦除编码数据还原到卷 0007 在名为SG-DC-SN3的存储节点上:

      repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 0007

      卷范围:此命令将擦除编码数据还原到范围内的所有卷 0004 to 0006 在名为SG-DC-SN3的存储节点上:

      repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volume-range 0004-0006

      多个卷不在一个序列中:此命令会将经过纠删编码的数据还原到卷 000A000C,和 000E 在名为SG-DC-SN3的存储节点上:

      repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 000A,000C,000E

      repair-data 操作返回唯一 repair ID 这就说明了这一点 repair_data 操作。请使用此 repair ID 跟踪的进度和结果 repair_data 操作。恢复过程完成后,不会返回任何其他反馈。

    备注 在某些存储节点脱机时、可以开始修复擦除编码的数据。修复将在所有节点均可用后完成。
    • 如果您的网格同时包含复制的数据和纠删编码的数据、请运行这两个命令。

  5. 监控复制数据的修复情况。

    1. 选择*节点*>*正在修复的存储节点*>* ILM *。

    2. 使用"评估"部分中的属性确定修复是否已完成。

      修复完成后、waiting - all属性指示0个对象。

    3. 要更详细地监控修复过程、请选择*支持*>*工具*>*网格拓扑*。

    4. 选择*网格*>*正在修复的存储节点*>* LDR*>*数据存储*。

    5. 结合使用以下属性,尽可能确定复制的修复是否已完成。

      备注 可能存在 Cassandra 不一致,并且无法跟踪失败的修复。
      • * 尝试修复( XRPA ) * :使用此属性跟踪复制修复的进度。每当存储节点尝试修复高风险对象时,此属性都会增加。如果此属性的增加时间不超过当前扫描期间(由 * 扫描期间 - 估计 * 属性提供),则表示 ILM 扫描未在任何节点上发现任何需要修复的高风险对象。

        备注 高风险对象是指可能完全丢失的对象。这不包括不满足其 ILM 配置的对象。
      • * 扫描期间 - 估计值( XSCM ) * :使用此属性可估计何时对先前载入的对象应用策略更改。如果 * 已尝试修复 * 属性的增加时间未超过当前扫描期间,则复制的修复很可能已完成。请注意,扫描期限可能会更改。* 扫描期限 - 估计( XSCM ) * 属性适用场景 整个网格,是所有节点扫描期限的最大值。您可以查询网格的 * 扫描时间段 - 估计 * 属性历史记录以确定适当的时间范围。

  6. 监控纠删编码数据的修复、然后重试可能已失败的任何请求。

    1. 确定纠删编码数据修复的状态:

      • 使用此命令可查看特定的状态 repair-data 操作:

        repair-data show-ec-repair-status --repair-id repair ID
      • 使用此命令可列出所有修复:

        repair-data show-ec-repair-status

        输出将列出信息、包括 repair ID、用于先前和当前正在运行的所有修复。

      root@DC1-ADM1:~ # repair-data show-ec-repair-status
      
       Repair ID Scope  Start Time  End Time  State  Est Bytes Affected/Repaired Retry Repair
      ========================================================================================
       949283 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:27:06.9 Success 17359 17359 No
       949292 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:37:06.9 Failure 17359 0     Yes
       949294 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:47:06.9 Failure 17359 0     Yes
       949299 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:57:06.9 Failure 17359 0     Yes
    2. 如果输出显示修复操作失败、请使用 --repair-id 选项以重试修复。

      此命令使用修复ID 83930030303133434重试失败的节点修复:

      repair-data start-ec-node-repair --repair-id 83930030303133434

      此命令使用修复ID 83930030303133434重试失败的卷修复:

    repair-data start-ec-volume-repair --repair-id 83930030303133434
相关信息

"管理 StorageGRID"