恢复教程

当单盘故障发生在RAID1阵列里，很多人第一个反应是“没关系，有镜像”，但现实往往比直觉更复杂。RAID1的本质是镜像：所有数据同时写到两块或多块盘上，当一块盘挂掉，另一块理论上还能继续提供数据读取，保证业务不中断。文件系统是否会切换为只读，取决于内核如何处理I/O错误、阵列管理器（如mdadm）如何降级以及文件系统本身对元数据异常的容忍度。

简单说：RAID1能极大降低数据不可用的概率，但不能万无一失地“防止”文件系统变为只读。先从三个常见触发点看起。

第一类触发点是物理I/O错误。假设一块盘在写入时发生了不可恢复的错误，内核在多次重试后可能把该块标记为错误。RAID层会把该盘从活动集合中移除，阵列进入降级模式。如果镜像盘健康，数据仍可读写，但如果写操作同时发生在多盘且某些元数据写入只完成到部分磁盘，文件系统可能检测到不一致，从而为保护数据完整性而切换为只读模式。

第二类是元数据损坏。元数据包括超级块、inode表、日志等。即使数据块有镜像，关键元数据若在整个阵列中被破坏，文件系统在挂载或运行时发现异常会触发只读保护，避免进一步写入造成无法恢复的损坏。RAID1对数据块镜像有好处，但元数据的一致性检查更多依赖文件系统自身和底层的日志机制。

第三类是阵列管理和驱动层的反应。不同的系统在面对故障时策略不同：有的会立即降级并继续服务，有的会在检测到不一致后让文件系统进入只读以等待人工干预或自动修复。运维常见的误区是把RAID1当作“永远在线”的保险箱，忽视了监控和自动化处理。如果没有及时替换故障盘、没有定期检查阵列一致性、没有监控SMART报告，长期运行中小故障可能累积成大问题，最终迫使文件系统保护性地只读。

从用户角度来说，理解这些机制很重要：RAID1提供的是冗余与可用性的提升，而不是对所有级别故障的绝对免疫。要将RAID1的优点最大化，需要结合良好的运维实践——实时报警、快速替换、定期scrub（校验）以及重建策略，才能把单盘故障带来的风险降到最低，从而降低文件系统进入只读的几率。

接下来的部分会深入说明在真实环境中如何处理单盘故障，如何诊断导致只读的根本原因，以及一些可实施的预防和恢复步骤。

通常dmesg会记录内核对I/O错误的反应，而mdadm会显示哪些设备被标记为故障或正在重建。根据这些信息，可以判断是单盘物理故障、阵列元数据不一致，还是文件系统自身的日志问题。

恢复流程应当预先定义并演练。常见步骤包括：一、立刻将故障盘下线，避免对阵列造成更多写入错误；二、确认镜像盘健康，查看是否存在坏块或文件系统错误；三、在确认为阵列降级且文件系统仍然可读的情况下，尽快替换故障盘并启动重建；四、如果文件系统已被挂载为只读，优先做只读数据备份，评估是否可以在只读状态下运行关键服务，或是否需要离线进行修复。

修复时需谨慎：对挂有重要数据的文件系统直接强制修复可能带来数据丢失，必要时先做全面备份再执行修复命令。

预防措施也并非复杂难行：定期监控SMART指标、配置邮件或监控告警、设置自动替换策略和热备盘、定期执行阵列scrub来提前发现不一致、在非高峰期模拟故障演练，让团队熟悉降级和重建流程。还有一点常被忽视：文件系统选择与挂载选项也影响只读触发的概率。

例如带有强日志机制的文件系统在异常断电或部分写入失败时，往往能更好地恢复；而某些特殊挂载参数会改变当底层返回I/O错误时内核的行为。

讲一点策略性建议：把RAID1当作“第一道防线”，而非“万能护盾”。合理的数据保护策略应当包含备份（离线或远程）、异地复制以及紧急恢复计划。RAID1可以显著提高可用性，但真正的连续可用依赖多个层次的保障。运维团队和决策者应把精力放在监控、演练和自动化上，把不确定性降到最小。

只要提前准备到位，单盘故障更多是运维流程的考验，而不是业务停摆的祸根。