记一次 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 文件。于是乎直接下载,替换,完美启动(老脸一红)!