3.2.7 典型运维场景与故障处理（扩容、迁移、损坏修复）

在磁盘与分区管理中，典型运维场景集中在扩容、迁移和损坏修复。操作前应确认业务窗口、备份策略与回滚方案，避免在未验证写入安全的情况下直接变更生产盘。

原理草图：典型扩容与迁移流程

一、扩容场景（新增盘 / 现有分区扩大）
1. 新增磁盘扩容挂载点（示例：/data）

# 1) 识别新盘（预期看到新盘 /dev/sdb）
lsblk
blkid

# 2) 分区（GPT）并创建主分区
parted -s /dev/sdb mklabel gpt
parted -s /dev/sdb mkpart primary 0% 100%

# 3) 格式化（XFS）
mkfs.xfs -f /dev/sdb1

# 4) 挂载与持久化
mkdir -p /data
mount /dev/sdb1 /data
echo "UUID=$(blkid -s UUID -o value /dev/sdb1) /data xfs defaults 0 0" >> /etc/fstab

# 5) 验证
df -hT /data

关键命令解释
- parted -s：非交互批量执行；mklabel gpt 选择 GPT 分区表。
- mkfs.xfs -f：强制格式化；生产需确认无数据。
- blkid：获取 UUID，避免设备名变化导致挂载失败。

现有分区扩容（非 LVM，XFS 在线扩容示例）

# 假设云盘已在控制台扩容，先刷新内核识别
echo 1 > /sys/class/block/sdb/device/rescan
lsblk

# 扩大分区（将 /dev/sdb1 扩到最大）
parted -s /dev/sdb resizepart 1 100%

# 扩大文件系统（XFS 在线）
xfs_growfs /data

# 验证
df -hT /data

注意事项
- EXT4 使用 resize2fs /dev/sdb1，XFS 使用 xfs_growfs <挂载点>。
- MBR 分区有 2T 限制与主分区数量限制，建议迁移至 GPT。

排错：扩容后空间未增长

# 1) 设备是否识别到新容量
lsblk -b /dev/sdb

# 2) 分区是否已调整
parted /dev/sdb print

# 3) 文件系统是否已扩展
xfs_info /data | grep -i blocks

常见原因
- 未 rescan 或分区未 resize。
- 扩了分区但未扩文件系统。
- 挂载点错误或多路径设备未刷新。

二、迁移场景（盘到盘 / 业务无感）
1. 文件级迁移（推荐）

# 1) 新盘准备并挂载到 /mnt/newdata
mkdir -p /mnt/newdata
mount /dev/sdb1 /mnt/newdata

# 2) rsync 全量迁移
rsync -aHAX --delete /data/ /mnt/newdata/

# 3) 校验文件数与容量
diff -r /data /mnt/newdata | head
df -hT /data /mnt/newdata

参数解释
- -aHAX：保留权限、硬链接、ACL 与 xattr。
- --delete：目标端同步删除，保持一致。

块级迁移（整盘/分区镜像）

# 将 /dev/sda1 镜像到 /dev/sdb1（会覆盖目标）
dd if=/dev/sda1 of=/dev/sdb1 bs=64M status=progress conv=fsync

# 迁移后修复 UUID 冲突（示例：ext4）
tune2fs -U random /dev/sdb1

注意
- dd 会覆盖目标数据，务必确认目标为空。
- 生产建议使用 partclone，效率更高、风险更低。

业务无感迁移示意

sequenceDiagram
  participant APP as 应用
  participant OLD as 旧盘(/data)
  participant NEW as 新盘(/mnt/newdata)
  APP->>OLD: 读写
  OLD->>NEW: rsync 增量同步
  APP->>OLD: 暂停写入窗口
  OLD->>NEW: 最终同步
  NEW->>APP: 切换挂载点

三、磁盘损坏修复（诊断、修复、止损）
1. 故障判定（SMART + 内核日志）

# SMART 健康度与坏道趋势
smartctl -a /dev/sdb | egrep -i "Reallocated|Pending|Offline|Error"

# 内核日志排查 I/O 错误
dmesg -T | egrep -i "I/O error|blk_update_request|sd .* error"

文件系统修复（卸载后执行）

# EXT4 修复
umount /dev/sdb1
fsck -y /dev/sdb1

# XFS 修复
umount /dev/sdb1
xfs_repair /dev/sdb1

坏块扫描与标记（仅 EXT 系列）

# 扫描坏块（只读）
badblocks -sv /dev/sdb1 > /tmp/badblocks.list

# 将坏块写入文件系统坏块表
e2fsck -l /tmp/badblocks.list /dev/sdb1

数据恢复与止损

# 只读挂载尝试拷贝关键数据
mount -o ro /dev/sdb1 /mnt/recover
rsync -a /mnt/recover/ /backup/recover/

四、风险控制与最佳实践
- 变更前进行快照或完整备份并验证可恢复性。
- 分区与文件系统变更建议在低峰进行，并设定回滚时间点。
- 制定统一的磁盘命名与挂载规范，避免设备名变化导致挂载失败。
- 重要数据建议采用 RAID 或 LVM 增强可维护性与恢复能力。

五、练习（建议在测试机完成）
1. 新增一块虚拟磁盘，将其分区为 GPT 并挂载到 /data，写入 /etc/fstab 后重启验证自动挂载。
2. 将 /data 扩容 5GB：完成 rescan、resizepart 与文件系统扩容。
3. 使用 rsync 将 /data 迁移到 /mnt/newdata，验证文件数量一致。
4. 模拟 I/O 报错：在日志中定位错误信息并给出修复方案（EXT 或 XFS）。