挽救计划

用一台N5105搭建了24小时开机的hermes后，无病无灾地运行了一个多月。9月初的一天，没有任何征兆，突然就挂了，一开始是微信交互页面显示离线，接着到Tailscale里发现N5105的连接也变成了灰色。回到家赶紧重启，直接卡在命令行界面进不去了，看样子是固态盘挂了，顿时感觉大事不妙。马上拿出笔记本，运行wsl，启动hermes，在它的指引之下用Debian的U盘启动盘启动后，扫描果然是固态盘的引导区出现问题，好在经过反复确认，数据应该还在，于是在hermes的指导下，千辛万苦地终于将镜像备份出来，然后从闲置笔记本上拆了一块固态盘，扫描诊断没有问题后，把镜像恢复了上去。恢复以后进Debian的图形界面途中又卡住了，备份镜像是DD命令，坏块填充为0直接搬过来了，于是又是改启动命令修复坏块，终于抢救了过来。坏得不多，也就是坏了4个4K的块，但正好坏在引导区，又恰好没有弄坏hermes的关键设置和一个月来生成的各种文档。也算是不幸中之万幸。

吃一堑长一智，赶紧安排hermes制作定期备份脚本，每周三次把hermes的设置和各种项目文档保存到NAS里。

过了两天，又出问题了。

早上打开微信，hermes的微信网关又挂了。不是直接无法连接的挂，是你下任何命令它都只有一句话：state.db出问题了，需要修复。手机上的juiceSSH无法连接N5105：好死不死地把N5105设置为只能通过密钥连接，而哪个好人家会想起来在手机上的SSH上设置密钥啊......于是本着本着无知者无畏的精神，直接把NAS里的备份里的同名文件倒腾出来覆盖上去，然后......就死得更严重了。

还是只有回家来修。还是用笔记本上的hermes修好的。总之一句话：覆盖state.db不是不行，而是动手前要把所有hermes进程关掉，否则数据就会对应不上，自动判断严重故障。笔记本上的hermes同时发现一个问题：N5105上的hermes在生成备份脚本时犯了一个低级错误，备份数据库前没有进行一致性快照处理，在数据库还在吞吐数据的时候就水灵灵地来了个热备份，所以，它备份的那个数据库就是个坏了的数据库......

总结经验教训：

• 二手主机里的固态盘，在用之前一定要检测健康度和坏块情况。鬼知道前主人是怎么折磨这块SSD的。
• 一体化的工控无风扇小主机，不代表真的就不需要风扇。一直以为外壳就是个巨大的一体化散热片，所以虽然摸上去挺烫也没有给它上风扇，这不，遭报应了么。
• 一定要第一时间考虑备份机制，不要等到数据丢了或可能要丢了才来着急忙慌。
• 不同机子上的hermes聪明程度不一样，我感觉笔记本上的hermes就是要比N5105上的hermes聪明些。所以，关键的工作结果，最好让另一个hermes来复核一遍。丈八高的烛台，照得见别人，照不见自己么。