前言
如上一篇文章所述，在双盘 btrfs RAID1 发生单盘故障后，我通过将剩余的那块盘转换为单盘模式的方式，成功重新启动了系统。虽然系统暂时恢复了，但此时它已经失去了冗余能力，完全依赖于剩余的那块盘。因此必须尽快重新组建 RAID1，保证系统的冗余能力。
由于 250 GB 的固态在 2026 年已经很罕见了，因此我从库存中翻出了两块 1 TB 的固态硬盘，准备使用它们来替换掉之前的两块 250 GB 的盘，重新组建 RAID1。现将这个过程记录下来，不供模仿，仅资参考。
过程
准备工作
需要的内容：
- 两块更大的 SSD；
- 充足的时间和耐心；
- 细心的操作；
更换硬盘
首先需要将两块新的 SSD 安装到服务器上，移除故障的那块盘。开机确认它们都能被正确识别，并确认新盘和旧盘的设备路径。在我的服务器上，两块新盘分别是 /dev/nvme0n1 和 /dev/nvme1n1，而旧盘是 /dev/nvme2n1。
重新组建 RAID1
首先在两块新盘上创建分区：和最初的两块盘一样，创建一个 EFI 分区和一个用于 btrfs 的分区。创建完成后，将两块新盘的 btrfs 分区加入到当前的 btrfs 文件系统中：
| |
可以看到类似下面的输出：
| |
然后使用 btrfs balance 命令将数据重新分布到两块新盘上，重新组建 RAID1：
| |
当 balance 完成后，使用 sudo btrfs device usage / 命令查看当前的设备使用情况，确认 RAID1 已经重新组建好了：
| |
在我的服务器上，旧盘 /dev/nvme2n1p2 仍然在列表中，但它已经没有任何数据了，剩余空间也全部属于未分配空间。这时就可以安全地移除掉旧盘了：
| |
更新引导配置
虽然 RAID1 已经重新组建好了，但此时两块新盘上还没有 GRUB 引导程序，需要重新安装。首先在两块新盘上创建 EFI 分区，并将它们挂载到 /boot/efi 和 /boot/efi2 目录下，然后安装 GRUB：
| |
然后更新 /etc/fstab 文件，由于替换硬盘并不影响 btrfs 分区的 UUID，因此不需要修改 btrfs 分区的配置；但是需要更新 EFI 分区的配置，改为新的 SSD 的 EFI 分区：
| |
最后，更新 GRUB 配置：
| |
这样，整个系统就已经成功迁移到新的 SSD 上了。
重启
关闭服务器，移除掉旧盘，重新开机，如果一切正常的话，应该能正常启动到系统中了。
结语
通过前文和本文的操作，我们成功解决了 btrfs RAID1 的单盘故障，并且将系统迁移到了一对更大的 SSD 上。整个过程其实并不复杂，但需要非常小心地操作，特别是做好数据备份和电源保障。
这次的经历也证明了在服务器上使用 RAID1 的重要性，虽然它不等于完整的备份，但至少能在单盘故障时保证系统的可用性，给我们足够的时间来进行恢复和迁移，也能够为重要的数据增加一层保险。希望这篇文章能对遇到类似问题的朋友有所帮助。