回到家躺在椅子上，突然发现什么最可怕？
- A: 得知作业截止时间不是晚上而是中午十二点
- B: 老板在 Slack 给你发了 114514 条消息未读
- C: 偷偷藏着的裙子被妈妈发现
- D: 家里服务器从内网上消失了
发生了肾么事情？
上周日回到了家里，突然发现发现 ping 不到家里的服务器了，过去一看发现似乎是网线松动（灯不亮了），可是插紧以后仍旧 ping 不上，因为懒得搬显示器和键盘具体排查了，干脆直接彻底断电让他自己硬重启了。
重启以后发现群晖迟迟没有上线，也完全 ping 不到，等了五分钟也没有反应，大事不妙！
SRE 开始
在开机过程中，持续开着的 ping 返回了类似下面的内容：
root@proxmox:~# ping 10.99.xx.xx
PING 10.99.xx.xx (10.99.xx.xx) 56(84) bytes of data.
timeout
timeout
...
64 bytes from 10.99.xx.xx: icmp_seq=1926 ttl=64 time=4037ms
64 bytes from 10.99.xx.xx: icmp_seq=1927 ttl=64 time=3037ms
64 bytes from 10.99.xx.xx: icmp_seq=1928 ttl=64 time=2036ms
64 bytes from 10.99.xx.xx: icmp_seq=1929 ttl=64 time=1036ms
64 bytes from 10.99.xx.xx: icmp_seq=1930 ttl=64 time=35ms
timeout
...
timoeut
这就很尴尬了，看上去是机器在启动后一瞬间又挂了，那么基本可以确定群晖出了大问题。
于是第一时间关掉了母鸡上所有的虚拟机，因为我的 k8s 集群的储存也是使用 nfs 挂载的群晖，所以现在整个集群应该已经挂得不成样子了。
对着所有硬盘先来了一顿 smartctl -a ，结果令人欣慰，总共七块硬盘（一块 NVME 系统盘，两块 SSD 母盘，两块 HGST 数据盘，两块准备送他们上路的老盘，全都能 PASSED，至少最糟糕的情况应该还没有发生。
由于症状包括了 ping 成功后突然中断，那么不能排除启动后 ip 发生改变也可能导致类似的情况，但是中断了无法检查，黑群晖的引导也导致我们无法看到群晖自己的 log，只能尝试使用 Synology Assistant，但是修改并没有什么卵用，状态也会卡在 Connection Failed/ Ready 这样的奇怪状态，由此基本判断系统挂壁，需要急救。
群晖的储存结构
群晖的储存结构一共分为了三个部分：
- 引导固件，白群晖应该位于主板上，黑群晖一般是 USB 或是 SD 卡，虚拟机的情况则可以是转制的虚拟硬盘，固件只负责提供一些基础服务（例如刷机和寻找下面储存的真系统启动），也不会修改；
- 每一块硬盘最前的两个分区（我的情况下是 4.4），一同通过 madm 组成了 RAID1 用来安装真正的系统，也就是理论上只要有一个是好的，那么整个就是系统就能正常运行；
- 硬盘的剩余区域，单块分区或是使用 mdadm 提供软 raid，然后格式化为 ext4 或是 btrfs 用于实际数据储存。
下一步自然是应该确认硬盘上的数据是否还完整，群晖直接挂载了所有四块老盘，给群晖的机器先挂上了一个 ubuntu live iso，然后进 shell 尝试只读挂载那上面的三个分区，大致查看了一下数据，应该问题不大，那至少数据是安全的，那么下一步应该就是如何恢复系统了，由于挂载时真系统的阵列并没有出现，怀疑系统已经损坏。
尝试从备份修复
刚才也说了群晖会在每块硬盘上都留下自己的分身，那么也就是了理论上任何一块硬盘正常，我们都应该能正常启动系统。为了更好地利用这个功能，我一直挂载了一块容量较小的虚拟硬盘，并把应用程序也安装在其中，并使用 proxmox 备份，准备应对的应该也就是现在这个情况。
但是将最新的备份还原后，系统的症状并没有改变，还是同样的错误；尝试了一个月前的备份，依旧无法启动；单独尝试挂载任意一块实体硬盘，也是一样的卡死。
所以可能系统很早就出现了问题，只是一直没有重启，导致问题没有暴露出来；也可能是因为没有办法安装 qemu-agent，导致备份实际上不完整而不可用。但这些都已经没用了，现在能做的只有想办法重新安装系统，希望能够保留数据，由于忘了把配置导出，所以完全还原已经是不可能了，但只要数据还完整，就没有大问题。
尝试重新安装
重新安装一个全新的群晖并没有难度，可是并不知道如何不让已有的数据丢失，这时那块虚拟硬盘又有了意义，虚拟磁盘可以被 clone，于是可以进行没有风险的尝试，成功后再对物理硬盘操作。
- 第一个尝试是安装全新的群晖，再将旧盘挂载，结果是只要旧盘没有处理的挂载上虚拟机，启动就会失败；
- 第二个尝试是将前面所述的两个用来保存群晖系统分区删除，结果是如果直接用来安装系统，则会全盘清除，如果挂载到新系统，则无法识别内容需要初始化，初始化后数据报废；
- 最后还是从网上搜索得到了一个解决方案，只格式化前两个分区，这次能够直接启动了，固件认为系统损毁，于是可以正常地重新安装系统，同时可能因为分区表并没有问题，系统也不会主动破坏，数据也得到了保留。
在虚拟硬盘上成功后，又添加了两块送终的物理盘做同样的处理，系统也可以发现系统分区损毁，由群晖修复后恢复正常；将最后两块物理盘处理后，所有数据终于恢复正常可以访问。但是由于配置没有备份，之后又花了一定的时间重新配置了账户、同步、定时备份等功能。
后记
在群晖恢复后，其他的虚拟机也都重新被启动，经过了一段时间，集群等等也哦度顺利恢复。
这次的故障恢复给了一些启示：
- 并不是备份正常运行就可以高枕无忧了，至少应该定期确认能够正常从备份恢复，也就是灾容一定要进行测试，否则真正发生问题后并不能确定哪些是可靠的；
- 最好还是需要有一个冷备，以及 onsite 备用储存，否则如果这次的情况真的有硬盘损坏或是阵列都是，数据安全无法保证；
- 存储以后有条件还是一定不用群晖了（无论是黑的白的），等到我有一个四平米恒温恒湿的机房后，我一定上单独的 truenas 物理机解决存储问题！