凌晨站点流量突然上涨，SSH里连续出现“disk I/O error”，数据库进程随即退出；登录控制台又发现整个系统被切成只读。真正棘手的并非服务停机，而是此时贸然重装：坏道、错误日志和尚未落盘的数据可能被一并覆盖。更糟的是，有些VPS只有一块虚拟磁盘，线上直接执行fsck看似能救活系统，实际却可能把仅存的元数据改成第二份损坏。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：onesproxy（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
文件系统只读重挂载是内核发现写入风险后的保护动作。EXT4无法继续提交关键元数据时，会触发错误处理并把文件系统切到ro；日志存在时，EXT4日志重放可以恢复已提交但尚未落盘的事务。XFS的路径不同：XFS元数据校验依靠校验和发现树、日志等结构损坏，通常直接拒绝挂载，要求在未挂载设备上检查修复。因此，“只读”只表示内核限制了破坏范围，并不代表介质健康，更不能改回rw继续硬扛业务。
判断故障层次，要先查内核日志，而不是反复重启。可通过journalctl -k或dmesg -T寻找EXT4-fs error、XFS metadata corruption、medium error等记录，再用findmnt确认挂载状态。若错误集中在同一区域并伴随超时，优先怀疑底层介质；若日志明确指向元数据校验失败，则可能是文件系统自身不一致。两种原因可能同时存在，不能只凭一个fsck提示下结论。
介质侧应使用smartctl -x读取完整属性，重点看重映射计数、待映射扇区、无法读取扇区和通电时间。但VPS暴露的是虚拟磁盘，SMART信息可能被宿主屏蔽或仅反映虚拟设备状态，SMART坏扇区显示为零也不代表宿主硬盘正常。ServLlama可用于汇总磁盘告警和运行记录，但仍需结合控制台工单，请服务商核查宿主机与存储池。切勿用写测试反复“验证坏块”，那会覆盖本就脆弱的数据。
重装前应先停止应用、卸载数据盘；若系统盘无法卸载，就在服务商支持时创建快照。随后用lsblk、blkid核对设备与文件系统，避免把镜像目标误认成源盘。使用ddrescue及日志文件制作只读磁盘镜像，目标文件或磁盘容量不得小于源盘，读取错误先记录，不在源盘上执行修复。完成后检查ddrescue日志中的失败字节，并对镜像做EXT4、XFS只读一致性检查。只有镜像可独立读取、关键文件能校验通过，才可在副本上重放日志或执行修复。常见踩坑包括在线fsck、给原盘写入零值、镜像未验证就重装，以及把“能挂载”误当成“数据完整”。
当文件系统只读重挂载时，内核只是发现写入异常后停止继续写盘，并不代表介质已经可靠。此时不要反复读写原盘，也不要先运行写入式修复工具；坏扇区在重试中可能扩散，破坏原本可恢复的数据。应先记录报错、挂载点、块设备与分区关系，再制作只读磁盘镜像。整盘镜像须保留分区表和超级块；单独分区镜像必须记录偏移，否则后续修复容易错位。
建议使用支持断点续传的 GNU ddrescue 并保存 mapfile；普通 dd 遇到坏扇区会反复重试且没有进度记录。首轮可跳过坏块，再对失败区域低速二次读取，切勿为追求“零错误”无限重试。镜像完成后计算 SHA-256，将镜像挂载为 loop 设备，所有EXT4日志重放和 XFS 修复都只针对副本。若必须从原盘取关键文件，可用带坏块处理能力的工具读出后立即另存。
在副本上先检查、后修复。EXT4 先执行 e2fsck -f -n 镜像，确认报告后再执行 e2fsck -f 镜像，不可在原盘上直接用 -y 强制处理；检查过程会评估并完成必要的EXT4日志重放。XFS 先运行 xfs_repair -n 镜像；若因日志问题无法挂载，应另做副本后使用 xfs_repair -L，并接受丢失未提交事务的代价。XFS元数据校验只能发现不一致，不能凭空还原缺失内容。
最常见的坑，是把 SMART“通过”当成健康证明。SMART 是设备自检，SMART坏扇区、读取错误和静默损坏还需结合 dmesg、属性项及坏块映射判断；坏扇区增加时应停止对原盘的深度扫描。文件系统结构恢复也不等于业务数据正确，数据库、压缩包和备份必须单独验证。
最终检查清单：① 原盘已隔离，镜像、mapfile 各留两份；② 镜像哈希、分区偏移、工具日志齐全；③ EXT4 与 XFS 都先执行 -n 检查后再修复，全程只操作副本；④ 关键文件先复制，再整理挂载、属主和权限；⑤ 重建系统后做数据库校验、归档测试与抽样哈希比对；⑥ 确认连续读取不再产生新错误后，才将旧盘降级为普通存储。
结论是：先隔离故障盘，再以只读镜像承载修复，先校验、后改动，最后按业务重要性验收。这样即使物理坏扇区继续扩大，也不会把最后一份可恢复数据一起消耗掉。
