硬件故障恢复

• 1: 驱动器故障恢复
• 2: 节点故障恢复
• 3: 站点故障恢复

1 - 驱动器故障恢复

MinIO 支持将故障驱动器热替换为新的健康驱动器。 MinIO 会检测这些驱动器并对其执行自愈，无需在节点级或部署级执行重启。 MinIO 自愈 仅发生在被替换的驱动器上，大多数情况下对部署性能影响很小或几乎可以忽略。

MinIO 自愈会确保恢复到驱动器上的所有数据保持一致且正确。

以下步骤提供了更详细的驱动器替换流程。 这些步骤假定你使用的是一个 MinIO 部署，其中每个节点都按照 文档中的前置条件，通过 /etc/fstab 配合逐盘标签来管理驱动器。

1) 卸载故障驱动器

使用 umount 卸载每块故障驱动器。例如，以下命令会卸载位于 /dev/sdb 的驱动器：

umount /dev/sdb

2) 替换故障驱动器

从节点硬件中移除故障驱动器，并将其替换为已知健康的驱动器。替换驱动器 必须 满足以下要求：

• 已按 XFS 格式化 且为空。
• 相同的驱动器类型（例如 HDD、SSD、NVMe）。
• 性能相同或更高。
• 容量相同或更大。

使用容量更大的替换驱动器并不会增加集群总存储量。 MinIO 会以 服务器池 中 最小 驱动器的容量，作为该 服务器池 内所有驱动器的上限。

以下命令会将驱动器格式化为 XFS，并为其分配一个与故障驱动器一致的标签。

mkfs.xfs /dev/sdb -L DRIVE1

MinIO 强烈建议 使用基于标签的挂载方式，以确保驱动器顺序在系统重启后仍保持一致。

3) 审查并更新 fstab

检查 /etc/fstab 文件，并按需更新，使故障驱动器对应条目指向新格式化的替换盘。

• 如果使用基于标签的驱动器分配方式，请确保每个标签都指向正确的新格式化驱动器。
• 如果使用基于 UUID 的驱动器分配方式，请根据新格式化驱动器更新每个挂载点对应的 UUID。你可以使用 lsblk 查看驱动器 UUID。

例如，考虑以下配置：

$ cat /etc/fstab

  # <file system>  <mount point>  <type>  <options>         <dump>  <pass>
  LABEL=DRIVE1     /mnt/drive1    xfs     defaults,noatime  0       2
  LABEL=DRIVE2     /mnt/drive2    xfs     defaults,noatime  0       2
  LABEL=DRIVE3     /mnt/drive3    xfs     defaults,noatime  0       2
  LABEL=DRIVE4     /mnt/drive4    xfs     defaults,noatime  0       2

基于前述示例命令，由于 /mnt/drive1 处的替换驱动器与故障驱动器使用相同的 DRIVE1 标签，因此 fstab 无需修改。

4) 重新挂载替换后的驱动器

使用 mount -a 重新挂载本流程开始时卸载的驱动器：

mount -a

该命令应完成对所有替换驱动器的重新挂载。

5) 监控 MinIO 的驱动器识别与自愈状态

重新挂载驱动器后，使用 mc admin logs 命令 或 在 systemd 管理的安装中使用 journalctl -u minio，监控服务端日志输出。 输出中应包含识别到每块已格式化且为空驱动器的消息。

使用 mc admin heal 监控部署整体的 自愈 状态。 MinIO 会积极地对替换驱动器执行自愈，以确保部署快速从降级状态恢复。

6) 后续步骤

继续监控集群中是否出现更多驱动器故障。某些批次的驱动器可能会在接近的时间窗口内集中失效。 若部署中的驱动器故障率高于预期，应安排专项维护，集中替换已知存在问题的驱动器批次。 可考虑使用 MinIO SUBNET，与 MinIO Engineering 协作获取此类操作的指导。

2 - 节点故障恢复

如果某个 MinIO 节点发生完全硬件故障（例如所有驱动器、数据等全部丢失），则该节点在重新加入部署后会开始执行 自愈操作。 MinIO 自愈仅发生在被替换的硬件上，通常不会影响部署性能。

MinIO 自愈会确保恢复到驱动器上的所有数据保持一致且正确。

替换节点的硬件应与故障节点大体相近。 使用更好的硬件不会带来负面性能影响。

替换驱动器的硬件也应与故障驱动器大体相近。 例如，应使用相同容量的另一块 SSD 来替换故障 SSD。 虽然你可以使用容量更大的驱动器，但 MinIO 会以 服务器池 中 最小 驱动器的容量，作为该 pool 内所有驱动器的上限。

以下步骤提供了更详细的节点替换流程。 这些步骤假定你使用的是一个 MinIO 部署，其中每个节点都按照 文档中的前置条件 配置了 DNS 主机名。

1) 启动替换节点

请确保新节点已经按照行业、监管或组织内部标准与要求，完成所有必要的安全、固件和操作系统更新。

新节点的软件配置 必须 与部署中其他节点保持一致，包括但不限于操作系统和内核版本及其配置。 异构软件配置可能导致部署中出现意料之外或不期望的行为。

2) 更新新节点的主机名解析

可选 仅当替换节点的 IP 地址与故障主机不同时时，才需要执行此步骤。

确保原先关联到故障节点的主机名现在解析到新节点。

例如，如果 https://minio-1.example.net 之前解析到故障主机，那么它现在应解析到新主机。

3) 下载并准备 MinIO Server

按照 部署流程 下载并运行 MinIO server，并使用与部署中其他节点一致的配置。

• 所有节点上的 MinIO server 版本 必须 一致
• 所有节点上的 MinIO service 与 environment file 配置 必须 一致

4) 将节点重新加入部署

在该节点上启动 MinIO server 进程，并使用 mc admin logs 监控其输出；如果是 systemd 管理的安装，则可以使用 journalctl -u minio 监控 MinIO service 日志。

服务端输出应表明它已经检测到部署中的其他节点，并开始执行 自愈操作。

使用 mc admin heal 监控部署整体的自愈状态。 MinIO 会积极地对该节点执行自愈，以确保部署快速从降级状态恢复。

5) 后续步骤

继续监控部署，直到自愈完成。 如果部署持续或反复出现节点故障，应安排专项维护以定位根因。 可考虑使用 MinIO SUBNET，与 MinIO Engineering 协作获取此类操作的指导。

3 - 站点故障恢复

尽管整个站点丢失属于重大事故，MinIO 仍可将其影响控制在相对较小且可恢复的范围内。 站点恢复方式取决于该站点使用的复制方案。

站点复制自愈会自动将现有站点中的 IAM 设置、存储桶、存储桶配置和对象添加到新站点，无需额外操作。

如果其他健康站点上仍保留任何存储桶复制规则，则无法配置站点复制。 存储桶复制与站点复制互斥。

如果你准备从存储桶复制切换到站点复制，则必须先在健康站点上移除所有存储桶复制规则，然后再配置站点复制。

将不健康对等站点恢复到 Site Replication

站点复制 可让两个或更多 MinIO 部署在 IAM 策略、存储桶、存储桶配置、对象及对象元数据方面保持同步。 如果某个对等站点由于重大灾害或长期停电等原因失效，你可以使用剩余健康站点来恢复 可复制数据。

以下流程适用于站点丢失前已启用 站点复制 的场景，并可用于恢复数据。 本流程假设一个或多个对等站点已 完全丢失，而不是由于复制滞后、网络延迟或部署短暂停机所导致的延后。

1. 使用带 --force 选项的 mc admin replicate rm 命令，将故障站点从 MinIO 站点复制配置中移除。

   以下命令会强制将一个不健康的对等站点从复制配置中移除：

   mc admin replicate rm HEALTHY_PEER UNHEALTHY_PEER --force

   • 将 HEALTHY_PEER 替换为复制配置中任一健康对等站点的 alias
   • 将 UNHEALTHY_PEER 替换为不健康对等站点的 alias

   站点复制配置中的所有健康对等站点都会自动更新并移除该不健康对等站点。 你可以使用 mc admin replicate info 命令验证新的站点复制配置。

2. 按照 站点复制要求 部署一个新的 MinIO 站点。

   • 不要上传任何数据，也不要在既定要求之外对部署进行其他配置。
   • 验证新的 MinIO 部署运行正常，并且与其他对等站点具备双向连通性。
   • 确保新站点与现有对等站点使用相同的 server 版本
   注意

   警告

   mc admin replicate rm --force 命令只会作用于站点复制配置中在线或健康的节点。 被移除的离线 MinIO 部署仍会保留其原始复制配置，因此如果该部署恢复正常运行，它仍会继续向已配置的对等站点执行复制操作。

   如果你计划复用这些硬件重新加入站点复制配置，那么在重新初始化 MinIO 并将该站点重新加入复制配置之前，必须彻底清空该部署的驱动器。

3. 将 替换后的对等站点加入 复制配置。

   使用 mc admin replicate add 命令，将新站点加入复制配置：

   mc admin replicate add HEALTHY_PEER NEW_PEER

   • 将 HEALTHY_PEER 替换为复制配置中任一健康对等站点的 alias
   • 将 NEW_PEER 替换为新对等站点的 alias

   站点复制配置中的所有健康对等站点都会自动更新，将新对等站点纳入配置。 你可以使用 mc admin replicate info 命令验证新的站点复制配置。

4. 使用 mc admin replicate resync 对新对等站点执行重同步。

   mc admin replicate resync start HEALTHY_PEER NEW_PEER

   • 将 HEALTHY_PEER 替换为复制配置中任一健康对等站点的 alias
   • 将 NEW_PEER 替换为新对等站点的 alias

5. 验证复制状态。

   使用以下命令跟踪复制状态：

   • mc admin replicate status - 提供复制的整体状态和进度
   • mc replicate status - 提供存储桶级和全局复制状态

主动式存储桶复制重同步

对于故障发生前已启用 存储桶复制 的场景，你可以使用 mc replicate resync 将数据恢复到新站点。 先创建一个新站点替换故障部署，然后将现有健康、且已启用存储桶复制的部署中的数据同步到新站点。

1. 部署一个新的 MinIO 站点。
2. 按需配置 IAM 和用户。
3. 在有数据的站点上，使用 mc admin bucket remote add 命令创建新的 remote target，并记录输出中的 ARN。
4. 在有数据的站点上，使用上一步命令返回的 ARN 作为参数执行 mc replicate resync start，在新站点上重建存储桶。
5. 等待重同步完成（可使用 mc replicate resync status 检查）。
6. 从新的 MinIO 站点向现有目标存储桶配置存储桶复制规则。
7. (Optional) 删除目标部署中的存储桶复制规则，以恢复 active-passive 复制场景。

被动式存储桶复制重同步

存储桶复制 可以通过将目标存储桶中的数据复制到新的 MinIO 站点，直接恢复站点内容。

作为被动过程，存储桶复制在站点恢复场景中可能无法达到理想的恢复速度。

存储桶复制依赖标准复制 scanner 队列，而该队列不会优先于其他过程执行。 如果恢复流程对 SLA/SLO 要求更严格，请按前文所述使用基于 mc replicate resync 命令的主动式存储桶复制流程。

存储桶复制规则会将对象、其 version ID、版本以及其他元数据复制到目标存储桶。 如果站点丢失前已启用存储桶复制，那么 MinIO 可以将带有这些属性的对象恢复到新的 MinIO 站点。

1. 部署一个新的 MinIO 站点。

2. 按需配置 IAM 和用户。

3. 在剩余的目标存储桶部署上，为每个存储桶创建指向新 MinIO 站点的存储桶复制规则。

4. 等待复制完成。

5. 从新的 MinIO 站点向现有目标存储桶配置存储桶复制规则。

6. (Optional) 删除目标部署中的存储桶复制规则，以恢复 active-passive 复制场景。

   如果你希望继续保持存储桶之间的 active-active 复制，请不要删除用于恢复数据的这些部署中的存储桶复制规则。 在 active-active 复制中，任一位置上对象的变更都会影响另一位置上的对象。

镜像

MinIO 的镜像（mirroring）可以从任意兼容 S3 的存储系统复制对象。

无论源端如何，镜像（mirroring）只会复制每个对象的最新版本，不包含版本控制元数据。 因此你无法通过这种方式恢复这些属性。

当你只需要恢复对象的最新版本时，请使用 mc mirror。 如果你是从另一个 MinIO 部署复制数据，并希望恢复对象的版本历史及版本元数据，则应在这些机制原本已启用的前提下使用存储桶复制或站点复制。

1. 部署一个新的 MinIO 站点。
2. 按需配置 IAM 和用户。
3. 在新站点上创建存储桶。
4. 使用 mc cp CLI 命令，将镜像位置中的内容复制到新的 MinIO 站点。