群晖套件损坏，无法进行修复

参考：https://www.myluoluo.com/synology-rebuild-pgsql-database.html、https://imnks.com/9796.html

       注意，以下内容仅供参考，本人不对本文操作下的任何后果承担任何责任，建议阅读完本文后再进行操作。

　　近期，由于要跑实验平台，我将nas平台进行了升级，由i7 4960HQ升级到了QTJ0。由于想试试SA6400的核显硬解，就将系统从DS3617XS 7.1.42962换到了SA6400 7.1.42962，但是，由于不知名的原因，SA6400经常会在半夜死机，表现为路由器后台看不到群晖IP（证明系统内网络层都已经崩溃），来到群晖旁边，能看到有时硬盘还会有I/O，但此时系统已经无法访问，包括手动给UPS断电，也无法触发群晖的紧急模式来卸载存储空间。

　　首先，我怀疑是CPU的问题，因为我CPU是QTJ0（I9-10980HK ES）开盖7950裸压die，固定在4.7G频率下（因为我用的ES魔改CPU，群晖读不出来正确的CPU型号，CPU频率是由bios控制的，bios跑多少就是多少，差不多是9980K的性能），加微星z370M 迫击炮，酷兽夜枭3200 32*2 固定在2400模式下。之前做稳定性测试的时候，我用了aida64 PFU、CPU-Z稳定性测试、cinebench-r20都进行了压测，全部都是通过的，然后我稍微给CPU加压了0.05V，希望能够稳住。

　　然后，运行了不到2天，又死机了，这次我还是不信邪，继续给CPU加压，但是并没有什么卵用，我烤CPU的时候，加入了prime95第二项和内存测试：MemTest86、TestMem5、aida64内存测试，都是通过的。

　　在第3次死机的时候，我想到了可能是核显的问题，于是我增加了核显测试环节，结果也是通过的，我很纳闷，不应该是核显的问题吧，群晖现在都没有套件和docker能够调用核显，怎么会是核显的问题呢？Jeffrey我没开啊，怪了。

　　在第4次死机的时候，我看了下系统日志，判断不出来是什么问题，我想既然是半夜死机，半夜的时候VMM上的虚机在跑PCDN业务，下行会拉满1000M下行，CPU负载可能瞬时很高，那我把虚拟机都关了让nas试下空载看看还会不会死机。结果依旧。

　　在第5次死机的时候，刚好是春节期间，我离开了工作的城市回了老家，nas又死机了，我想着既然我一时半会儿不能手动关机（之前nas死机我都是连上键盘，按ctrl+alt+delete来进行重启，大概按5s左右nas会自动重启，并且资料都在）那就先断电吧，一直这样卡死在哪也不是个办法，于是我手动给连接着nas的智能插座断了电。

　　等到我再次把nas开机的时候，发现存储空间正常，共享文件夹也都在，但我存在另一件令很离谱的事情：nas现存的大部分套件都显示损毁，并且修复的时候提示运行失败，且无法再次安装或卸载这些套件，在套件页面直接点击新套件，提示运行失败，手动上传新套件的安装包，可以安装上去，但是运行时提示运行失败，需要修复，点击修复提示运行失败，可以卸载新安装的套件，但是旧的套件无法进行更新、卸载与修复。

　　我找遍了网上的所有方法，不管是进入矿神大佬的删除套件安装包然后安装别的套件的方法（/volume1/@appstore），还是重建pgsql的方法，都没有任何效果，运行套件都是显示修复失败以及命令运行失败，用命令行安装和看安装日志也是显示显示272等错误，在网上根本搜索不到怎么解决，我绝望了，难不成我真的要放弃群晖这个系统或者把我所有的套件全部删除了（/var/packages/）？真要把全部套件都删了，那我玩了这么多年的群晖，这些套件是我的全部精华啊，真没了不就得从头开始了，我不忍心啊

　　然后我按照网上的方法，想了下，既然是旧套件无法通过web页面进行安装和卸载，那我删除/volume1/@appstore目录下的套件安装包，再删除/var/packages/目录下的套件数据，应该就能够把这个套件当新套件来用了吧，应该是能够正常运行的。于是我把/volume1/@appstore、/var/packages/这两个目录手动备份到volume2。

　　我拿了Apache2.4这个套件试了下，先删/volume1/@appstore/Apache2.4的套件安装包，再删除了/var/packages/Apache2.4的套件数据，然后使用web页面手动上传Apache2.4的安装包进行安装，再等待了几十分钟之后，我发现Apache2.4显示成功安装，并且能够正常打开运行。

　　然而，现实再次给我泼了一盆凉水，我尝试用上面的方法修复以下套件，全部都是显示成功安装，但全部都无法打开，并且显示需要修复，点击修复提示运行失败：FileStation、active backup for business、synology photos、drive、download station、video station、virtual machine manager、docker。其中我最在意的是这两个套件：docker和VMM，如果这两个套件没了，相当于我丢失了整个群晖生态，因为我非常多的应用和服务都是跑在这两个套件里面的： KVM、kali、homebox、transmission、qinglong、zerotier、win7、win10、win server、grafana、jellyfin、Prometheus 、EVE-ng、ESXI、PCDN等等，可以说这些容器和虚机就是我这台nas的半条命，我搭了这么久的群晖，全部的资产就在这里面的，就算其他套件没了、系统设置没了，我都能够接受

　　然后我想到，既然是死机+意外断电导致群晖套件损坏，那么是不是系统的核心组件受损，导致套件的安装与修复出现问题？那我重装系统能不能解决这个问题呢？

　　然后，我重做引导，重新安装了下SA6400 7.1.1 42962 update 1，在安装界面选择保留资料；然后我进入DSM桌面，等待所有套件加载出来之后一看，完全没用。

　　既然重装SA 6400没用，那么应该是群晖核心的系统分区受损了，需要完全铲除原来的分区再重新安装我直接将群晖的系统分区删掉，然后再重装系统能不能行呢。我进入rr引导界面，直接在高级功能里面选择删除群晖系统分区。PS：删除系统分区后可以进行降级。警告，此操作会导致你的系统丢失所有套件，并且系统控制面板内除了共享文件夹还在之外的所有设置都将清除，请慎重操作！！并做好资料备份，存储空间和共享文件夹会不会被清空暂未清楚。

　　反正既然都这样子了，我也狠下心来，直接选择了清除系统分区；然后我将系统换成了DS3617XS 7.1.1 42962 update 6，上传DSM安装包之后，选择清除系统配置。说实话，在安装的时候，我心里是很凄凉的，我已经做好了丢失所有套件的准备，唉，还能怎么办呢，我怎么会遇到这种情况都怪我手贱，但只要存储空间和共享文件夹还在，其他套件生态都还能东山再起，只是又得耗费不少时间。

　　等待了10几分钟后，我打开了DSM的设置页面，重新配置NAS的名称和管理员账号，然后进入DSM桌面，首先看存储空间，存储空间都正常，raid1、raid5都在，只是M2存储空间提示损毁，不过里面也没啥东西，控制面板里面的共享文件夹也都在，多少松了口气；但是看到所有的套件都是空白的，只有系统自带的几个套件，多少有点说不出的滋味；我打开套件中心，点击hyper backup安装，能够正常安装上，但是需要重新配置同步目录，设置完全跟新的套件一样。

　　我点击安装active backup for business，安装好之后，点击打开，居然还是提示需要修复，然后再修复失败，我真的是无语了，我都删除系统分区了都还是不行，看来真的要删除整个/var/packages/目录了。

　　我SSH到/var/packages/，直接rm -rf *，想着先这样试下吧，反正我有备份；我再切到/volume1/@appstore，发现只存在一个我刚刚安装的hyper backup目录。

　　我再次打开web套件页面，安装active backup for business，发现可以安装并打开，我一看，好家伙，套件设置居然都还在，我之前设置了两台电脑进行备份，在我打开套件之后居然在运行备份，PC上传每秒110多兆；我惊喜万分，难不成docker和VMM也是这种情况？我马上安装了docker，在等待了半个小时之后，docker居然运行成功了，并且我设置开机启动的容器也都还在！！

　　我赶紧安装VMM，希望VMM也是一样的情况；一打开，发现存储池和镜像都是空空的，我像是被泼了一盆凉水，但我还是不敢相信，想着先添加存储池看下什么情况；我选择添加volume1，发现系统提示：该存储池存在虚拟机数据，是否需要导入/舍弃；我选择导入，等待了10几分钟后，我惊喜的发现我的虚机居然又出现了，我赶紧把剩下的三个存储池也导入到VMM中，发现所有的虚机和我上传的镜像都还在！！并且虚机状态全部正常！！

       总结下来，docker和VMM这两个套件，应用数据虽说在/var/packages/有存在，但在系统分区和/var/packages/被删除的时候，他们仍然能够恢复，证明他们已经不止在一个地方有备份，应该是在硬盘上有隐藏分区，而且该隐藏分区应该是独立于DSM系统分区之外的空间，连删除系统分区重装系统删除套件数据之后，这两个套件都能恢复，群晖确实是有两把刷子。

       这两个套件能够保住，我松了口气，其他的套件重装下就行，像drive、cloud sync、photos这些，虽然文件都在共享文件夹里，但还得重新同步需要不少时间；让我意外的是，photos在安装好之后居然开始重新进行索引，并且人脸识别正常，照片也都能够正常分类。但其他套件就没这么幸运了，drive、cloud sync 、web station、webdav server等十个套件全部需要重新设置，顺带一提，我不使用第三方套件，因为之前在迁移系统的时候第三方套件全部迁移失败，不知道是不是只有我是这样情况；所以第三方套件的功能我都是跑在docker和VMM下面，这样方便管理和迁移。

       到现在为止，黑裙已经运行了10来天，非常的稳定，没有出现死机/卡顿的情况，看来在我这套魔改平台上，SA6400的稳定性还是有很大的问题，希望未来各位大佬再优化优化。

       还有，玩魔改平台一定别手贱！NAS的稳定性最重要！