飞牛终于出 1.0 了，可喜可贺。我原本不是飞牛用户，原本自己装了个 Debian，手动配 LVM 加 samba 加 Docker，但是人的心态总是会老的，等这台 NAS 的系统盘挂掉之后，我发现我已经没有想再去手动配系统的想法了。于是，我换成了 OMV 系统，但离谱的事情来了，就是这个决定，让我险些丢失全部数据。
事情是这样的：我有 4 块数据盘，在 LVM 上组了一个 RAID10（/dev/sdX，X是 bcde 四块盘）。系统盘坏了，换了新盘，重装 OMV，结果开机后 OMV 直接告诉我啥卷都没有，LVM 完全识别不到。折腾半天后，在 Grok 帮助下用 lvmdiskscan、pvck、vgcfgrestore 这些命令把 metadata 抠出来一看，日志清清楚楚写着 OMV 在安装过程中默默执行了 lvremove，把我整个卷组的逻辑卷全删了，连个确认提示都没有。
恢复过程简直是噩梦：虽然 metadata 完整备份还在，理论上 vgcfgrestore 一下就能回来，但 RAID10 是有严格顺序的，顺序错一位数据就全乱。LVM 的 metadata 里记录的物理卷顺序全是用 sda/sdb/sdc/sde 这种字母，系统重启后磁盘字母是随机分配的，根本对不上原来的顺序。
于是就只能靠暴力穷举 4! = 24 种可能性，一种一种改 metadata 里的 device 名，手动 vgcfgrestore 试。试到第十几种的时候，终于 ecbd 这个顺序让文件系统 mount 成功！中间有几次差点就直接跑破坏性的 lvmchange 或者 dd 去“修复”，幸好忍住了。文件 99.9% 没问题，还是有 0.1% 的数据出现在近乎随机的损坏位置，还好借助压缩包、种子的校验机制我能知道具体是哪些文件损坏了。
感想几句：
- 好在只有 4 块盘，4 的阶乘才 24，要是 10 块盘，10! = 3628800，基本宣告 GG，数据直接寄了。
- Grok 的逻辑推理能力真的独一档，那天陪我一步步分析 metadata 结构、写脚本验证顺序，硬是把我从坑里拉回来（不过它一面对重复跑 24 次同样的命令就明显开始偷懒，比 Gemini 还明显）。
- OMV 这种不给任何提示、直接后台执行 lvremove 删用户逻辑卷的行为，已经不能用 bug 来形容了，这就是设计人员脑子有问题，纯纯的**设计。
- Linux 到现在还依赖 sdX 这种随机字母来标识磁盘，LVM 的 metadata 里存的顺序等于白存，重启一次全乱，简直是历史遗留罪。
- 再次提醒自己：RAID 不是备份！这次要是没救回来，几 TB 的重要数据直接蒸发。现在用 10 盘位机箱组了 NAS，装了飞牛，定时从一个 RAID 逻辑卷同步到另一个 RAID 逻辑卷，再也不信单份存储了。
2025-11-20 20:44:34
