USB-ZFS风险盘vol1(部署于fnos99)

一块插在 NAS 上的希捷移动硬盘被格式化成 ZFS 当数据盘用:已累计 16 个永久数据错误,池元数据受损,退役迁移是唯一正解。

访问方式

• 挂载点 /vol1(池名 trim_d6e6c72b-817a-4293-8177-daa5369cacca)
• SSH:ssh -p 1208 yunmai@100.64.0.15,只读看池:sudo zpool status -v(yunmai 有免密 sudo)

技术架构

• 硬件:/dev/sda,型号 Seagate Expansion(USB 外置移动盘),1.8T,单盘无冗余,USB 直插(供电/休眠是 ZFS 数据损坏的典型诱因)
• 文件系统:ZFS 单设备池,ONLINE 但带伤;scrub 上次 2026-09-11(repaired 0B),错误在 09/27、09/30、10/01 快照中持续出现
• 每日 01:00 自动快照(UTC_08-*),但快照与数据同盘,救不了这块盘

数据(存储/备份情况,重点标注风险盘)

• 使用率仅 2%(36G/1.8T),迁移成本很低
• 已确认损坏的文件(zpool status -v 实测,共 16 项):
• 1000/docker/filebrowser/database/filebrowser.db(现网+2个快照,3处)—— FileBrowser 应用数据库
• 1000/豆包云主机工作区/workspace/chats/2026-09-29/new-chat-44/ 下会员网络图 html/md(现网+3个快照,8处)
• docs/服务器迁移归档/kaku2025/整机备份_2026-09-30/02_站点文件/la.maiyou.vip.tar.gz、ymsxy.maiyou.co.tar.gz —— kaku2025 服务器整机备份归档本体损坏
• 池元数据 <0x0>(1处,最危险,意味着损坏可能继续扩散)
• 同盘还存有:vms(虚拟机)、@sync、vol3_backup_0913、vol3_live_backup_20260922 等备份目录 —— 备份放在坏盘上等于没备份

使用方法

• 短期:只读,尽快把可读数据拷出;停止一切向 /vol1 的写入(新备份、新快照)
• 迁移优先级:filebrowser.db(应用在用)> vms > vol3 备份 > 豆包工作区(有源端)

维护方式(启停/日志/配置)

• 池状态:sudo zpool status -v;错误清单随 scrub 更新
• 导出池(确认退役时):sudo zpool export trim_d6e6c72b-817a-4293-8177-daa5369cacca
• 飞牛后台对应"存储空间1"的移除入口(操作前先导出池)

现状与风险

• 高:16 个永久数据错误且跨快照扩散,涉及应用库、工作区文件、服务器备份归档
• 高:单盘 USB 无冗余,任何一次掉电/接触不良都可能全池消失
• 中:kaku2025 整机备份(迁移期归档)已损,备份完整性链条断裂
• 低:36G 数据量小,损失面可控,窗口还在

优化建议(3-6条,给可直接执行的命令)

1. 立即抢救可读数据:mkdir -p /vol2/fnos99_vol1_救援 && rsync -a --info=progress2 /vol1/ /vol2/fnos99_vol1_救援/ 2>/vol2/救援错误日志.txt(错误文件会跳过并记录)
2. 校验 kaku2025 归档哪些还能用:for f in /vol2/fnos99_vol1_救援/1000/豆包云主机工作区/workspace/docs/服务器迁移归档/kaku2025/整机备份_2026-09-30/02_站点文件/*.tar.gz; do tar -tzf "$f" >/dev/null 2>&1 && echo "OK $f" || echo "损坏 $f"; done
3. 迁移 vms 与备份目录后停写:sudo zpool set autoexpand=off ... 前先 mv 业务目录;确认无进程占用:lsof +D /vol1 | head
4. 换盘重建:把数据迁到 /vol2 或新 SATA 盘后,飞牛后台删除该存储空间,USB 盘退化为冷备
5. 关闭该盘每日快照(避免快照链继续记录坏数据),飞牛后台快照策略里调整
6. 校验完成后复核池错误是否停止增长(隔 7 天):sudo zpool status -v | grep -A3 errors