记一次 unRaid U盘损坏修复的过程。。。

前言

前段时间 unRAID 系统提示 flash 写失败了，没当回事，以为只是偶发的一次写错误，应该问题不大。

过了几天之后，在整理磁盘空间的时候，突然发现备份目录下有大概十几个的 boot 目录备份包，然而这些备份的压缩包本不应该出现在这里，而且这些压缩包的大小也存在异常，这就意味着 unRAID 已经有超过10天备份失败了。

这里说一下我预设的定时备份任务：每天凌晨 3 点自动打包 /boot 目录，然后通过 rclone 将阿里云盘挂载到本地，通过文件名中的时间戳判断并删除 7 天之前的备份文件，之后将新的备份文件上传到阿里云盘上。

出现了这样的问题，不想折腾都不行了。。。

尝试修复过程

尝试 1 —— 手动打包

因为之前周末电工师傅来换空开，直接拉闸断电了，怀疑会不会是这个导致了异常，于是尝试手动拷贝 /boot 目录，并进行手动打包。

拷贝倒是成功了，flash 中的 /boot 目录直接能拷贝到硬盘的共享目录中，但是打包同样失败了，提示文件损坏，而且文件名是乱码。。。

尝试 2 —— 删除 Nvidia Drive Plugin

上次重启后，英伟达驱动莫名其妙掉了，然后尝试重新下载也提示下载失败，然而本来也是闲置的功能，而且本着能不折腾就不折腾的主旨，也是放任没管。

猜测打包失败会不会和 Nvidia Drive Plugin 下载驱动失败导致的问题，ssh 进入后台后查看 /boot/config/plugin 中这个插件的目录，确实发现了几个大小异常的驱动包，和几个乱码的文件。

rm ./* -rf 回车一敲，以为此次修复完美谢幕。删除后确实打包成功了，但是尝试重启后，直接无法启动了！出现了一堆错误日志，并且 web gui 无法启动，设置了自动挂载的阵列也没有挂载，docker 无法和 docker.sock 通信。。。什么鬼啊！

尝试 3 —— 重新制作 U 盘

排查错误不如我直接重做 U 盘，又快又不用动脑子，结果上官网一看 6.10.3 的下载链接已经从官网上下架了。。。我特意存储的备份系统镜像也在 unRaid 的阵列中。。。

翻箱倒柜找，终于在回收站里找到了之前下载的官方进行包。下载写盘器、写 U 盘、拷贝config、插 U 盘、开机，一气呵成。我嘞个豆。。。怎么还全是 ERROR 啊！！！

尝试 4 —— 解决 ERROR

不得已，只能解决 ERROR 了。

还好 unRAID 提示的还算清楚，仔细一看，嗨，这不是 docker 容器配置的 xml 解析失败了么，提示有格式错误。打开 U盘 中的 xml 检查了一下，确实有几个文件内容中出现了随机乱码的情况，导致格式错误。

将之前阿里云网盘上正确备份的文件下载下来，检查无误后替换错误文件，重启，这下总算是正常启动了。

后续

虽然系统正常了，但是问题的根本原因其实并没有找到。

目前仍然不清楚导致 docker 容器配置 xml 文件内容出现随机乱码的原因，怀疑的方向有几个：一是每天读 flash 进行备份，增大了 flash 出错的风险可能，毕竟 flash 不像硬盘那样耐*；二是拉闸断电导致的异常，不过这个我也没敢尝试复现，真出问题了，代价不小；三是 Nvidia Drive Plugin 出错，导致备份时出错，异常情况下导致 xml 出错。

由于之前备份都失败了，所以并不能确定 xml 出错的时间。几个猜测的点都是比较难去重现的，只能说后续使用上尽量谨慎一些吧。

Nvidia 的驱动插件，本来也是闲置的，所以不考虑重新安装了，而且万一后续有虚拟机直通显卡的需求，还得卸载。

备份策略也做了一定的修改，由原来的直接 tar 命令压缩 /boot 目录，修改为将 /boot/config 目录拷贝至硬盘后再进行压缩备份。备份间隔也从每天，修改为每周。当有较大更新时，则手动触发备份。

折腾

中国有句古话，“来都来了”。

嘿嘿，来都来了，不折腾一下，那不得抓耳挠腮，浑身奇痒难耐啊。所以去老毛子的论坛翻了翻，正好有 6.12.6 的包和 hack 文件。于是乎直接下载，替换，完美启动（老脸一红）！