0%

NAS崩溃记

​ 家里两台NAS的其中一台蹦了,还包含着重要数据。在恢复数据的过程中,被搞的要死要活,同时深深的体会到了什么叫福无双至,祸不单行。

​ 两台NAS其中一台是蜗牛,运行黑群晖,也是本次的主角,通过公网IP向外提供文件服务,另一台则是近两个月新配的NAS,运行TrueNAS系统,另装一台NAS的原因是蜗牛只有四盘位,而且可靠性不够,之前也出现过掉盘问题,就重新买配件装了一台,为了ZFS文件系统上了TrueNAS,准备哪天把数据迁移过去。那台蜗牛在过去的一年内运行稳定,但我嫌弃小文件读取速度慢,搞了一块240G的SSD作为只读缓存用于加速读取,前一天晚上装进机箱并开启相关配置,第二天发现从外网无法读取服务器内容了,一开始只是以为DDNS出问题了(之前有过类似情况)。

​ 然而回到家打开黑裙后台,一个大大的感叹号挂在消息提醒处,存储空间全部损毁,瞬间头皮发麻,一堆自己经年累月整理的资料全放在上面,而且一开始为了保证可用性(注意,这里说的是可用性而不是可靠性)还组了raid1,大多数资料除此之外都没有备份,人都傻了,愣了一段时间,开始找解决方案。

​ 初步判断可能是挂缓存的过程中某些操作导致系统认为存储出现重大问题,直接关闭了存储空间,也就是我看到的存储空间损毁,硬盘依然能被系统正确识别,smart信息也没问题,说明数据大概率还在,换个方式读取出来就行。事实证明也是如此,查阅相关资料以后发现群晖官方是有提供数据恢复方案的(传送门),把硬盘拆出来,装进一台linux主机,然后运行一些程序就可以读取阵列硬盘内的数据,挑战开始。

​ 第一步就是搞一台linux主机,家里没有,装虚拟机的话硬盘直通又是一个问题,还是物理实机比较靠谱,当时慌得一批,直接去公司把日常工作用机扛了回来,后面有朋友提醒是可以拿ubuntu的livecd直接在蜗牛上操作的,然而当时心态有点崩,而且怀疑问题是由于硬件问题导致的,所以就没敢再拿原机器动手。

​ 电脑扛回来,拆了以后发现电源只有仨硬盘供电口,扣除系统SSD以外我还需要额外三个,两个原数据磁盘以及一块转移数据的备份盘,只能再跑一趟,从朋友那里借来了大4P转SATA供电线,东西装上开机又特么撞到坑了,连sudo apt update都做不到,之前家里是专门拿R2S做了个独立网关,一些科雪上王啥的插件放上面,然后路由器把网关设置过来,这样所有设备都可以不用特殊设置就可以科雪浏览,所以linux主机也就一直没换软件源,然而R2S前两天断电重启的时候挂了,一直没去找原因,不管是换源也好修机器也罢,弄好以后已经是凌晨一点半了,硬盘成功挂载,数据也可以正常读取,看着那些原始文件那叫一个感动,谁特么知道后面还有坑…

​ 第二天开始挪数据,目标是把蜗牛硬盘数据都转移到TrueNAS那台文件服务器上,理论上直接挂个NFS然后直接往里面灌数据就完事了,然而TrueNAS的NFS服务一直用不起来,之前也没找到原因,所以方案B是找个硬盘读出来然后再手动搬运到另一台NAS,也就是我之前塞进机箱的那块备份盘,思路清晰以后就赶紧动手,真是too yuang too simple,实际操作才发现拷贝速度从几十M一直锐减到三四M一秒,而且再也提不上去,首先推测是不是文件管理器直接拖拽的问题,直接用cp命令然后打了个显示速度和进度条的补丁,发现现象依旧;其次猜测可能是由于这块备份盘是叠瓦盘,缓存写爆以后写入掉速,后续和朋友讨论是在linux环境下,使用mount命令貌似默认不会开启硬盘缓存,而是使用主机内存作为缓存,内存用光以后就开始掉速了。不管是哪个原因,3M一秒搞毛线,这要搬到猴年马月……只能又搞了个骚操作,先把数据拷贝到固态硬盘上,然后再从固态转移到备份盘上,总而言之就是先把数据撸出来再说,实际上也确实奏效,固态盘的可用容量只有三百多G,但是要搬运的数据量有接近4个T,只能是缓兵之计,还是得去解决一下NFS挂载的问题。

​ 把TrueNAS论坛关于NFS挂载失败的问题看了个遍,终于找到解决方案(传送门),需要使用maproot命令对分享的目录映射用户以及用户组,举例子:

1
2
cat /etc/exports
/mnt/tank/nextcloud -alldirs -maproot="root":"wheel" -network 192.168.1.0/24

把client端的root用户映射为NAS上的root,client端的root组映射为NAS上的wheel (gid=0) 组。这个参数非常重要,否则会nfsroot链接失败。这是freeBSD上的内容,常用的Ubuntu等debian系可没这玩意。其次,挂载时加上-o tcp,vers=3,skip掉NFS4 and UDP

1
mount -o tcp,vers=3 -vv 192.168.1.167:/mnt/tank/nextcloud /home/username/nextcloud_mounted/

​ NFS服务正常运行后,写入速度有了质的提升,从原来的3M一秒飙升到几十M,虽然说不能跑满千兆线速,但是这已经可以把文件拷贝时间压到一个可以接受的程度了。

​ 我以为这已经完事大吉了,接下来就是等待而已,还是too yuang,生活总是会在不经意间给你惊喜。拷贝到一半,拷贝停止,NFS服务忽然卡住,我的心里瞬间咯噔一下,这又是咋地了,那边崩完这边崩?查看trueNAS后台发现系统无法识别其中一块硬盘了,这块掉线硬盘的表现也很奇怪,听声音感觉到转速由低到高,达到最高转速后忽然发出一声尖刺声,转速又逐步降低,又逐步提高,如此往复。把硬盘拿出来使用USB硬盘盒接入win10电脑,识别很正常,坏道扫描也没有问题,数据能正常读取,怀疑是逻辑坏道,重新格式化以后装回去,现象依旧,反正就是拿出来没问题装回去就挨卵,把目光放到了硬盘的接线上,最后排查到的问题是插在这个硬盘上的电源线有问题,换了个硬盘电源线就ok,我TM??这么小概率的事情也能让我撞上?这个周末我是不是把能踩的坑全踩完了?

​ 在这之后,安安静静的把数据灌完,没再出别的幺蛾子。

后记

​ 经过这一番折腾,现在重新回头看,我是不敢用群辉直接管硬盘了,愈发觉得群辉这系统一点都不健壮,一点小问题就会直接触发一些特殊操作,比如说损毁硬盘空间,但是实际上硬盘本身没有问题,拿到外面还是可以读取的,可能是担心用户误操作导致数据实际受损,所以提前帮你关闭读写,然后让你备份数据?群辉的那些APP确实多,功能丰富,真要用的话也是nfs或者网络硬盘的方式映射过去,底层还是用ZFS比较靠谱。

参考

SOLVED - NFS share mount on Ubuntu 20.04 | TrueNAS Community