服务器日志刷 I/O error（dev sdb）？先把病灶盘钉死再谈修复

服务器业务突然变慢，日志里刷出一串「I/O error, dev sdb, sector 5389560」，很多人第一反应是重启——先忍住。I/O error 已经把两件事告诉你了：哪块盘（sdb）、哪个扇区（5389560）。按下面的顺序把病灶钉死，数据才有最大概率保住。

第一步：dmesg 确认报错集中度

执行 dmesg -T | grep -i "I/O error"，看报错是否集中在 sdb、时间上是偶发还是持续。偶发几条可能是线缆接触或瞬时压力；持续刷屏基本可判盘体故障。同时确认 sdb 对应的是哪块物理盘：lsblk 看分区和挂载、smartctl -i /dev/sdb 对序列号——贴在机箱上的标签对号，别拔错盘。

第二步：smartctl 给盘做体检

smartctl -H /dev/sdb 先看总评，再 smartctl -a /dev/sdb 细看：05（重映射扇区数）、C5（待映射扇区数）、C6（无法修正扇区数）三项，任何一个持续增长都是物理损伤实锤。普通读错误盘还能撑，这三项涨起来的盘不要犹豫。

第三步：抢救顺序——先备份后处置

盘还能读的部分先抢救：优先把重要数据 rsync 到好盘，读不动的目录跳过别死磕。业务盘在 RAID 阵列里的，确认阵列降级状态，按阵列卡提示标记 offline 换盘重建；单盘直挂的，备份完成后立即下线该盘，绝不要带着持续 I/O error 的盘跑业务。

第四步：排除假故障

换线换口是最便宜的验证：SAS/SATA 线松动、背板口供电异常也会报 I/O error。换线后报错消失、SMART 三项干净，那就是线的事，盘留着继续用。

一句话定位：I/O error 不慌，dmesg 钉盘、smartctl 判死、先救数据再换件。企业服务器运维、故障盘更换与数据备份方案，找贵州诚鑫致达——先保数据，再谈修复。

（约 800 字）

企业存储选型参考｜贵州诚鑫致达

做核心业务 SAN 存储与高可靠应用，群晖机型参考：UC3400 · UC3200 · SA3600。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。贵州县域市场：县城及乡镇企业存储、办公网络与监控存储。