RAID 5、RAID 6 或 ZFS 多驱动器丢失：在不破坏奇偶校验的情况下恢复崩溃的 Synology、QNAP 或 TrueNAS 阵列¶

听到 Synology DiskStation、QNAP TS 系列、TrueNAS 服务器或 Linux 的声音 mdadm 存储服务器在报告卷崩溃、池降级/故障或多个驱动器断开连接时连续发出蜂鸣声，这是一种高风险的存储紧急情况。当单个驱动器掉出 RAID 5, Synology 混合 RAID (SHR-1），或 ZFS RAIDZ1 池，阵列以零冗余运行（degraded 状态），通过并行读取每个剩余磁盘来动态重建丢失的块。如果第二个驱动器在数小时后脱机，或者抛出不可恢复的读取错误（URE）在重建到替换磁盘的过程中，奇偶校验数学崩溃，存储池完全脱机。惊慌失措的管理员通常会在接下来的 60 秒内通过单击 初始化 来销毁数 TB 的可恢复数据，然后使用以下命令重新创建阵列 mdadm --create，或强制立即在线重建故障硬件。如果您的硬件RAID卡本身挂掉而不是磁盘挂掉，请切换到 RAID卡死亡、外部配置导入以及为什么千万不要初始化磁盘;如果单个硬盘驱动器发出咔嗒声或拒绝旋转，请咨询 硬盘故障和数据恢复 或 NAS RAID 阵列降级、多个驱动器故障和 ZFS/Btrfs 恢复。如果此存储故障导致医院医学成像失效（PACS）、紧急调度或生命安全基础设施，请拨打您当地的紧急电话号码（911 在美国和加拿大， 112 整个欧盟， 999 在英国）或查看我们的目录 紧急号码。

现在就这样做¶

1. 停止并且不要单击“初始化”、“创建池”、“修复”或运行 mdadm --create 在已删除的驱动器上：单击 Synology DSM 或 QNAP QTS 中的初始化，或运行 mdadm --create 在 Linux 中，写入全新的超级块并开始将所有成员磁盘上的奇偶校验条带清零。掉落的驱动器通常仍然可以使用 99.99% 您的文件完好无损，仅由其事件计数器标记为不同步。
2. 彻底关闭 NAS 或服务器电源（如果正在跨单击驱动器主动重建，则断电）以冻结事件计数器：阵列在部分降级状态下保持在线状态的每一秒，操作系统都会递增超级块 Update Time 和 Events 幸存磁盘上的计数器，而丢弃的磁盘则保持冻结在较旧的事件编号。如果 NAS 尝试在有坏扇区的驱动器上进行自动重建，则继续读取该驱动器可能会剥离磁盘涂层（head crash）。
3. 用物理标记或胶带标记每个驱动器托架插槽（Bay 1, Bay 2, Bay 3, Bay 4) 在滑出任何托盘之前：当 Linux 时 mdadm, LVM2, 和 ZFS 通过每个分区超级块、旧硬件控制器和手册中的 UUID 跟踪驱动器顺序 dmsetup 表重建需要精确的物理槽顺序（0, 1, 2, 3...）。
4. 切勿尝试恢复、强行组装或 fsck 直接在原始成员驱动器上；使用逐位克隆每个驱动器 ddrescue 首先：运行之前 mdadm --assemble --force 或 zpool import -F，通过直接 SATA/SAS（绝不是隐藏的廉价 USB 桥接器）将每个成员磁盘连接到 Linux 工作站 SMART 或 SCT ERC 超时）并克隆它 ddrescue 到健康的备用驱动器或图像文件。
5. 严格以只读模式强制组装克隆数组（--readonly 或 -o readonly=on): 组装时 mdadm 在同时多驱动器下降期间事件计数器漂移分开的阵列，始终通过 --readonly （mdadm --assemble --force --readonly /dev/md0 ...）。在只读模式下，两者都不 mdadm, LVM2, ext4, Btrfs，也不 ZFS 可以覆盖奇偶校验条带或重播破坏性日志。
6. 以只读方式安装后，立即将最重要的数据复制到独立的外部备份驱动器：首先将文档、数据库、虚拟机和照片转移到单独的驱动器，然后从头开始擦除和测试磁盘。

决策树：多驱动器 RAID 和 ZFS 池紧急分类¶

使用此流程图确定您的阵列是否遭受逻辑超时下降（TLER / ERC 不匹配）、重建过程中真正的多磁盘坏扇区故障或 ZFS 事务组（TXG）故障：

flowchart TD
    Start["RAID 5 / RAID 6 / SHR / ZFS 池在 2 个以上驱动器丢失后崩溃"] --> StopIO["立即停止所有重建并关闭 NAS"]
    StopIO --> Label["按托架编号（托架 1 到托架 N）标记每个驱动器托盘"]
    Label --> ConnectLinux["通过直接 SATA / HBA 将成员驱动器连接到 Ubuntu Linux 救援主机"]

    ConnectLinux --> CheckSmart["检查 SMART 和只读元数据：smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"dmesg 中是否有任何驱动器发出咔嗒声、拒绝旋转或脱机？"}

    PhysicalHealth -->|"是： RAID 5 中 2 个以上驱动器出现机械/磁头故障"| Cleanroom["停止给磁盘供电 -> 发送到洁净室数据恢复实验室"]
    PhysicalHealth -->|"否：所有驱动器都旋转（可能有待处理的坏扇区或超时丢弃）"| CloneAll["使用 GNU ddrescue 克隆每个成员驱动器（正向传递 -> 反向抓取）"]

    CloneAll --> DisconnectOrig["断开原始驱动器并严格在克隆磁盘/映像上工作"]
    DisconnectOrig --> ArrayType{"使用哪种存储架构？"}

    ArrayType -->|"Synology DSM（SHR/经典 RAID）"| SynologyFlow["通过 mdadm --examine -> 强制组装只读 -> 激活 LVM2 / Btrfs 只读检查事件"]
    ArrayType -->|"QNAP QTS (HAL LVM 薄/厚 RAID)"| QnapFlow["组装 mdadm 只读 -> 激活 DRBD 层（如果存在） -> 扫描自定义 QNAP LVM2 超级块"]
    ArrayType -->|"TrueNAS / ZFS（RAIDZ1 / RAIDZ2 / 镜像）"| ZfsFlow["运行 zpool import -d /dev/disk/by-id -> 导入只读并回滚： zpool import -f -o readonly=on -F"]
    ArrayType -->|"标准 Linux mdadm"| LinuxFlow["比较事件计数器 -> 运行 mdadm --assemble --force --readonly -> 使用 -o ro,noload 挂载文件系统"]

第 1 阶段：为什么强制重建会破坏数据（URE 和同批次级联）¶

要了解为什么单击 修复/重建 或更换一个驱动器并等待 36 小时通常会导致阵列完全崩溃，您必须了解奇偶校验重建如何对老化的磁性介质造成压力，以及消费级台式驱动器从 NAS 机箱中脱落的原因。

1. 不可恢复的读取错误的数学现实（UREs) 在 RAID 5 或 RAIDZ1 重建期间¶

在 4 驱动器中 RAID 5 或 ZFS RAIDZ1 池、数据和奇偶校验块（P）使用异或（XOR) 计算 (D1 XOR D2 XOR D3 = P）。如果驱动器 2 完全失效，则阵列的剩余冗余为零。要将驱动器 2 重建到全新的替换磁盘上，NAS 必须同时读取驱动器 1、驱动器 3 和 驱动器 4 上从字节 0 到磁盘末尾的每个扇区（Reconstructed D2 = D1 XOR D3 XOR P）。

考虑一下当这些驱动器是四年前从同一制造批次购买的四个 12 TB（12,000 GB）硬盘驱动器时会发生什么： - 重建 12 TB 需要读取 36 terabytes （2.88 x 1014 单个位）在最大热负载和机械负载下连续运行 24 至 48 小时。 - 消费类硬盘通常带有不可恢复的读取错误（URE) 规格 1 error in 1014 bits （12.5 terabytes），并且老化的驱动器会产生无声的潜在扇区错误（Current_Pending_Sector）位于多年未读取的磁盘冷区域。 - 当 驱动器 3 遇到一个不可读的 4 KB（0.004 兆字节）坏扇区，而 驱动器 2 仍然丢失或半重建时， XOR 方程有两个未知数 (D2 和 D3）。

2. 为什么台式机硬盘没有 TLER / SCT ERC 超过 1 个坏扇区被完全踢出¶

以下是在 Synology、QNAP 和 Linux 上导致灾难性多驱动器丢失的陷阱 mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

请注意实际发生的情况：驱动器 3 并未失效。它有 99.999999% 健康扇区，只有 1 或 2 个不可读的 4 KB 扇区（8 kilobytes 出于 12 terabytes）。然而因为 mdadm 由于 30 秒命令超时，将驱动器 3 从阵列中踢出，整个卷显示为 崩溃。如果您克隆驱动器 3 ddrescue （它会优雅地跳过 8 KB 的坏扇区并复制其他 12 TB）并以只读方式强制组装阵列，您几乎可以恢复 100% 的文件。

3. 为什么你绝对不能跑步 mdadm --create 或点击“初始化”¶

当阵列崩溃时，网上流传着两个具有破坏性的谣言： - 误解 1：“使用完全相同的驱动器顺序重新创建阵列 mdadm --create." 即使与 --assume-clean，现代版本的 mdadm 默认为不同 Data Offset 值取决于内核和 mdadm 释放（2048 sectors 与 262144 sectors）。当 mdadm --create 写了一个新版本 1.2 超级块的偏移量错误或块大小不匹配，它会覆盖 LVM2 物理卷标头或 ext4 超级块位于卷的前面。 - 误区 2：“拔出刚刚掉落的第二个驱动器，将其重新插入，然后单击“修复”。” 如果 驱动器 1 三天前退出（因此其数据已过时 3 天）且 驱动器 3 在 10 分钟前退出（因此其数据为最新数据），则拉出并重新插入错误的驱动器或强制重建 驱动器 1 标记为“活动”且 驱动器 3 标记为“备用”会导致 NAS **使用 3 天前过时的奇偶校验条带覆盖最新阵列，从而损坏每个目录和文件过去 72 小时内修改过。

第 2 阶段：检查超级块和 Event Linux 救援主机上安全计数器¶

要安全地挽救崩溃的 Synology、QNAP、TrueNAS 或 Linux 阵列，请移除所有成员驱动器（标记其托架编号后）并将它们连接到运行 Ubuntu 22.04 LTS / 24.04 LTS 的台式电脑或服务器（甚至从 Live USB 记忆棒启动）。

第1步：在Ubuntu中安装取证救援工具包¶

在 Ubuntu 救援机器上打开终端并安装所需的实用程序：

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

步骤 2：映射每个驱动器号、序列号和分区布局¶

列出所有连接的块设备及其硬件序列号，这样您就不会将救援磁盘与源 NAS 磁盘混淆：

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

查看典型 Synology DSM、QNAP 或 TrueNAS 驱动器的分区表：

第三步：检查 mdadm --examine 查看阵列崩溃的原因（事件计数器矩阵）¶

在 Synology、QNAP 或 Linux 上 mdadm 阵列，检查用户数据分区上的 RAID 元数据（例如，分区 3 /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3）无需安装或修改任何内容：

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

比较所有四个驱动器的输出：

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

仔细阅读这个法医故事： 1. /dev/sdc3 （Device Role 1) 有一个 Events 计数 479012 从两天前开始（Oct 29）。两天前，该驱动器首先退出，此后一直处于离线状态。 2. /dev/sdb3 （Role 0） 和 /dev/sde3 （Role 3) 两者都有 Events : 482190 在 14:12:09。 3. /dev/sdd3 （Role 2) 有 Events : 482188 在 14:12:04，仅 5 秒，落后 2 个事件 sdb3 和 sde3。 4. 结论：您必须使用 ** 重建数组sdb3 （Role 0), sdd3 （Role 2），以及 sde3 （Role 3)** （其事件计数器仅相隔 2 个刻度），而 离开 sdc3 （Role 1）完全退出。

第 3 阶段：逐位克隆每个驱动器 GNU ddrescue¶

跑步前 mdadm --assemble --force 或 zpool import -F，克隆每个所需的驱动器（特别是最后由于坏扇区而退出的驱动器，例如 /dev/sdd 在上面的示例中）到相同或更大容量的健康空驱动器，或者到原始 .img 文件存储在大容量存储空间中。

第 1 步：为什么 ddrescue 必须带有地图文件¶

标准型 dd 在第一个坏扇区时中止，或者与 conv=noerror,sync 浪费数小时在损坏的磁道上磨削读取头，同时对相邻的良好数据进行零填充兆字节。 GNU ddrescue 适用于智能多阶段通道： 1. 第 1 阶段（复制阶段）：以全顺序速度复制磁盘的所有健康、快速响应区域（150 MB/s 到 250 MB/s），立即跳过任何缓慢或无法读取的块，以便驱动器在获得之前不会过热或死亡 99.99% 好的数据。 2. 第 2 遍（修剪阶段）：从正面和背面读取每个坏块的精确边缘（reverse direction）将损坏的区域隔离到精确的 4 KB 硬件扇区。 3. 第 3 步（抓取阶段）：轻轻地重试损坏的扇区，而无需重置总线。

第 2 步：运行 2 阶段 ddrescue 克隆命令¶

始终指定 mapfile (sdd_rescue.map）。如果即将消失的源驱动器断开连接并需要重新启动， ddrescue 读取映射文件并从其停止的确切字节处恢复，而无需重新读取单个已复制的扇区：

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

第 4 阶段：重建 Synology DSM (SHR-1 / SHR-2 / 经典 RAID)、QNAP 和 Linux mdadm¶

一旦您的克隆驱动器（或只读循环设备）准备就绪并且原始 NAS 驱动器已安全拔出，请按照适合您平台的准确非破坏性组装顺序进行操作。

场景 A：标准 Linux mdadm 或 Synology Classic RAID (RAID 5 / RAID 6）¶

1. 停止任何部分 md Ubuntu 可能尝试启动的数组：

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. 强制组装克隆的分区（sdb3, sdd3, sde3, 省略已死很久的 sdc3）在严格只读模式：

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   观察输出： mdadm 将报告 forcing event count in /dev/sdd3(2) from 482188 up to 482190 和 mdadm: /dev/md2 has been started with 3 drives (out of 4)。
3. 验证阵列是否处于活动状态并已标记 (auto-read-only) 或 (read-only):

   cat /proc/mdstat
   

场景 B：Synology Hybrid RAID (SHR-1 和 SHR-2）与 LVM2 和 Btrfs / ext4¶

Synology 的 SHR (Synology Hybrid RAID) 是 100% 标准 Linux mdadm + LVM2 （Logical Volume Manager）： - 当 SHR 池中的所有驱动器大小相同（例如，四个 8 TB 驱动器）时，Synology 会创建一个 mdadm RAID 5 分区（md2 在每个驱动器的分区 3 上）并放置一个 LVM2 卷组（vg1000 或 vg1）在上面 md2。 - 当 SHR 池中的驱动器具有混合大小（例如，两个 8 TB 驱动器和两个 16 TB 驱动器）时，Synology 会创建两个独立的驱动器 mdadm 数组： md2 跨分区 5 (8 TB RAID 5 中所有 4 个驱动器上的切片）以及 md3 跨分区 6（剩余的 8 TB 在 RAID 1 中的两个 16 TB 驱动器上进行切片），然后加入 md2 + md3 成一个单一的 LVM2 卷组（vg1000）。

强制组装后在 Ubuntu 上以只读方式挂载 Synology SHR 卷 /dev/md2 （和 /dev/md3 如果是混合尺寸 SHR）： 1. 扫描 Synology LVM2 物理卷和卷组：

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

场景 C：Synology DSM 7+ 卷加密或共享文件夹加密（eCryptfs）¶

• 共享文件夹加密（@sharename@ 文件夹包含 ECRYPTFS_FNEK_ENCRYPTED... 文件名）： 复制整个 @encrypted_share@ 文件夹关闭 /mnt/synology_rescue 首先，然后使用您的 Synology 加密密码在 Ubuntu 上安装并解密它，或者 .key 文件：

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• DSM 7.2+ 全卷加密 (LUKS）： 如果 /dev/vg1000/lv 节目 TYPE="crypto_LUKS" 在 blkid，使用以下命令将其解锁为只读 .rkey 创建卷时下载的恢复密钥文件：

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

场景 D：QNAP QTS (LVM2 Thin Provisioning 和 DRBD 层）¶

现代 QNAP NAS 设备（QTS 4.3+ / 5.x) 插入一个内部单节点 DRBD 设备（/dev/drbd1）之间 /dev/md1 和 LVM2 卷组（vg1）。 1. 首先强制组装 QNAP 数据分区（/dev/sd[b-e]3) 只读到 /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

第 5 阶段：拯救 TrueNAS 和 Linux ZFS 池（RAIDZ1, RAIDZ2, RAIDZ3）¶

如果您的存储服务器运行 TrueNAS CORE、TrueNAS SCALE、Proxmox VE 或 Ubuntu ZFS，则恢复不会使用 mdadm。相反，ZFS 结合了卷管理器和写时复制（CoW）文件系统集成到围绕Uberblocks和顺序事务组构建的单个事务架构中（TXGs）。

步骤 1：检查 4 个 ZFS vdev 标签（L0, L1, L2, L3) 在每个克隆磁盘上¶

每个 ZFS 成员分区存储池配置的四个相同副本以及最后 128 个 Uberblocks 的数组（分区前面的两个标签， L0 和 L1，最后有两个标签， L2 和 L3）。运行 zdb -l 在每个克隆分区上检查池状态和最高提交的事务组（txg）：

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

比较 txg: 所有克隆驱动器的数量。就像 mdadm的 Events 计数器，如果一个磁盘在断电或第二个磁盘掉电前 5 分钟掉线，则其 txg 将略低于其余磁盘。

步骤 2：以严格只读模式导入 ZFS 池 (-o readonly=on）¶

首先检查可导入池，而不通过安装任何东西 sudo zpool import -d /dev/disk/by-id。切勿以读写模式导入损坏或多磁盘删除的 ZFS 池。当导入时 -o readonly=on，ZFS 不会尝试启动重新同步，不会写入新的 Uberblock，并且如果空间映射损坏（spacemap) 在写分配期间遇到：

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

第三步：如果 zpool import 失败了 I/O error 或 corrupted data，使用 TXG 回滚（-F 和 -T）¶

如果两个驱动器在大量写入突发期间在几秒钟内彼此断开，则最新的事务组（TXG N）在幸存的奇偶校验条带上可能不完整，而 TXG N-1 或 TXG N-2 （提前 5 到 15 秒写入）在 Uberblock 环形缓冲区内 100% 完好无损。

1. 测试非破坏性试运行回滚预览（-F -n）：

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   如果 ZFS 报告 Would be able to return pool to its state as of <timestamp>，运行只读回滚导入，无需 -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. 如果 -F 仍然无法安装最新的 Uberblocks，列出历史 Uberblock TXG 编号 zdb 并导入特定的旧 TXG (-T）：

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   选择一个 txg 崩溃前 30 到 60 秒的数字（例如， txg = 9481020）并以只读模式导入在该确切时间点冻结的池：

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

第 6 阶段：恢复后验证并防止未来重建级联¶

一旦您 100% 复制了已恢复的数据 /mnt/synology_rescue 或 /mnt/zfs_rescue 到独立的备份目标上，请在将 NAS 重新投入使用之前遵循以下硬件和配置清单：

• 切勿在同一天从同一零售商处购买所有 NAS 驱动器：来自同一制造批次的驱动器共享相同的磁头批次和固件，导致它们在重建过程中在数小时内出现故障。混合批次或制造商（Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG）。
• 仅使用 NAS/企业硬盘 TLER / SCT ERC 启用（或提高Linux mdadm 桌面驱动器的 SCSI 超时）：适用于 Linux 中的消费类驱动器 mdadm，使用一个 udev 规则来提高 /sys/block/sdX/device/timeout 来自 30 秒到 180 秒所以 mdadm 等待内部扇区重新映射而不是删除驱动器。
• 迁移驱动器大于的阵列 8 TB 来自 RAID 5 / SHR-1 / RAIDZ1 到 RAID 6 / SHR-2 / RAIDZ2: 与 12 TB 到 24 TB 驱动器，单奇偶校验重建时间超过 30 小时，使得双奇偶校验 (RAID 6 / SHR-2 / RAIDZ2）对于在重新同步期间出现坏扇区很重要。
• 每月安排 Data Scrubbing （mdadm check / zpool scrub）和扩展 SMART 测试：每月清理修复潜在扇区错误（Current_Pending_Sector），同时所有驱动器都在线。
• 请记住，RAID 是高可用性，而不是备份：遵循 3-2-1备份策略 带有离线副本。

地区紧急电话号码和机构协议¶

影响医疗保健网络、紧急通信或法定个人记录的存储中断需要立即升级：

• 美国和加拿大：拨打911 如果存储崩溃导致医院临床系统瘫痪（EHR / PACS）或派遣。报告针对 NAS 的勒索软件 (DeadBolt, LockBit, Akira) 至 CISA (1-844-Say-CISA / cisa.gov/report), 联邦调查局 IC3 (ic3.gov)，或 加拿大网络安全中心 (1-833-CYBER-88）。
• 英国：拨打999 用于影响生命安全或紧急 NHS 护理的紧急情况。根据英国 GDPR，评估永久未备份的个人数据丢失是否需要通知 ICO（0303 123 1113) 72 小时内。
• 欧盟：拨打112 整个欧盟。 NIS2 指令下的实体必须在 24 小时内向其国家 CSIRT 报告重大运营中断，永久个人数据可用性丢失会触发 GDPR 第 33 条 在 72 小时内报告。
• 澳大利亚和新西兰：拨打000 在澳大利亚或 111 在新西兰；向 ACSC 报告基础设施或勒索软件 NAS 事件（1300 CYBER1) 或 新西兰 CERT (0800 237 869）。
• 印度和亚太地区：拨打112 在印度进行紧急响应；向 CERT-In 报告基础设施存储事件（incident@cert-in.org.in) 在强制的 6 小时窗口内。

常见问题¶

为什么 mdadm --assemble --force 拒绝启动我的 RAID 5 阵列 not enough to start the array？¶

在 4 驱动器中 磁盘阵列5 数组，至少 4 个驱动器中的 3 个 必须传递给 mdadm --组装 --force。运行 sudo mdadm --检查 /dev/sd[a-z]3 检查第三个驱动器被拒绝的原因：要么您传递整个磁盘而不是分区（/dev/sdd 而不是 /dev/sdd3），它的超级块被标记为 备用 由于重建中断，或者 Ubuntu 的自动组装程序将一个驱动器锁定为非活动状态 /dev/md127 设备（运行 sudo mdadm --stop --scan 首先，然后重新运行 mdadm --assemble --force --readonly）。

如果驱动器开始重建（Recovery = 12%）在第二个驱动器退出之前？¶

如果驱动器 2 坏了，您插入了替换驱动器 2，然后在 12% 重建进度 驱动器 3 由于坏扇区而脱机， 不要使用 12% 重建的替换驱动器 2。相反，克隆原始的 驱动器3 与 解救。由于驱动器 3 在重建停止于 12% 之前完全处于最新状态，因此使用驱动器 1 强制组装阵列只读， 解救 驱动器 3 和驱动器 4 的克隆（保留驱动器 2）可为您提供一致的阵列。

如果 NAS 电源或主板坏了，我可以将 Synology 或 QNAP 硬盘放入全新的 NAS 机箱吗？¶

是的，两个 Synology (硬盘迁移）和威联通（直接 NAS 迁移）将 RAID 配置存储在驱动器本身上。然而， 如果两个或更多驱动器已经脱落（`Volume Crashed`) 在机箱损坏之前，请勿在新的 NAS 机箱内启动它们，因为迁移向导可能会覆盖分区或触发破坏性重建。首先在 Ubuntu 上拯救只读数据。

我如何知道删除的驱动器是否可以安全地克隆 ddrescue 与需要洁净室实验室相比？¶

将驱动器连接到 SATA，打开电源，边看边听 10 秒 须藤 dmesg -w。如果驱动器发出有节奏的咔哒声、刮擦声或嗡嗡声，向上旋转然后向下旋转，或者将容量报告为 0乙 / 4.1GB 在 LSBLK，读/写头发生物理故障：立即切断电源并使用洁净室实验室。如果驱动器旋转平稳，则表明其已满容量 LSBLK，并且仅记录 当前待定扇区 或超时错误，克隆它 解救。

什么是“RAID 5 写孔”以及它是如何产生的 ZFS 或 Btrfs 停电时避免它？¶

在传统的 磁盘阵列5 / 磁盘阵列6 如果没有日志，更新条带需要将数据块和奇偶校验块同时写入两个磁盘。如果写入过程中断电，数据和奇偶校验将不再匹配（ 写孔）。 ZFS （`RAIDZ`）和 Btrfs 使用 Copy-on-Write 消除写入漏洞（`CoW`），将每个新条带写入未使用的块中，并仅在完整条带位于磁盘上后更新 Uberblock/root 指针。

我可以使用吗 dmsetup 覆盖来测试 RAID 参数而不修改克隆的驱动器？¶

是的，您可以创建写时复制（`CoW`) 覆盖在只读循环设备之上 (`losetup --read-only`）使用Linux dm安装程序 （`snapshot` 目标）由稀疏文件支持 /tmp。任何写入来自 mdadm --组装 --force 或 fsck-y 进入一次性的 /tmp 覆盖文件，让您可以在需要时在 1 秒内重置。

相关指南¶

• NAS RAID 阵列降级、多个驱动器故障和 ZFS/Btrfs 恢复
• RAID卡死亡、外部配置导入以及为什么千万不要初始化磁盘
• 硬盘故障和数据恢复
• SSD和NVMe突然只读模式、0%备用块和TRIM禁用救援
• Linux、macOS 或 Windows 上意外的“rm -rf”或“Shift+Delete”：立即只读重新挂载
• 计算机备份、3-2-1 策略和灾难恢复
• 按国家/地区划分的紧急电话号码

来源和官方指导¶

• Linux Raid 维基 (raid.wiki.kernel.org) & Linux 内核组织：恢复失败的软件 RAID (mdadm --assemble --force --readonly 和事件计数器不匹配）。
• 自由软件基金会（GNU Project): GNU ddrescue 手册：从故障介质恢复取证数据。
• OpenZFS 文档 (openzfs.github.io): ZFS 池导入恢复 (zpool import -F、只读导入，以及 zdb 检查）。
• Synology Inc.：Synology 知识中心：当 Synology NAS 出现故障时，如何使用 PC 恢复数据（mdadm + LVM2 安装）。
• 美国国家标准技术研究院（NIST）（美国）：特别出版物 800-209：存储基础设施安全指南。