升级koishi导致变砖(not found)已经很多次了，特别是通过docker部署的，遇到这种问题只能重装，每次重装后配置QQ登录都巨麻烦
建议koishi主程序加入恢复(救援)模式，通过访问指定地址进入，例如 http://ip地址:端口号/rescue/，省去每次变砖都要重新安装配置的麻烦
3 个赞
安全模式的想法在 2022 年年末被提出，调研了一段时间后决定搁置。
调研的结果，在绝大部分需要使用安全模式的情况下，安全模式都不能解决需要解决的问题。
- 例 1：升级依赖导致 Koishi 炸毁。这种情况下你无法通过安全模式恢复，因为不管是你还是安全模式都不知道怎么修改依赖才能修复。
- 例 2：修改配置导致 Koishi 炸毁。这种情况下你无法通过安全模式恢复，因为要还原配置需要使用 config 插件，config 插件启动后会扫描安装的所有插件，导致实例炸毁。
对于任意一种能够使用安全模式修复的情况，你总能列举出相同情况下安全模式无法修复的情况。 例如，
- 如果你想使用安全模式修复普通插件，那么安全模式无法修复依赖控制台的插件；
- 如果你想用安全模式恢复插件配置，那么安全模式无法恢复 config 插件的配置；
- 如果你想回退依赖版本，那么安全模式无法恢复 market 插件的版本。
这就意味着在上述所有情况下安全模式都无法运行，也就意味着安全模式无法解决绝大多数用户的问题。
得出此结论之后，我们于 2022 年末-2023 年初这段时间完善了备份/还原机制。 现在，任意方式启动的 Koishi 实例均能在一条命令之内完成备份。如果你不知道自己所处的环境如何进行备份，请阅读对应环境的文档。
如果你对安全模式的实现有好的想法，欢迎提出安全模式的设计思路或直接贡献代码。
1 个赞
如果恢复/救援模式不可行，那么是否可以在koishi中允许用户创建备援模式，即执行后复制一份一模一样的koishi环境，默认启动主环境，如果升级失败，用户可切换为后备环境，删掉升级失败的主环境。如果升级成功，后备环境用户可作为回滚到旧版本时使用，也可选择删除。
或者参考虚拟机，允许用户创建koishi快照或还原点，如果升级失败变砖，可通过快照回滚到之前的版本
或者更进一步，在koishi中加入负载均衡功能，这样一个机器人环境被风控或崩溃，则自动切换到备用机器人环境，不影响业务正常使用（负载均衡功能与第一条的区别是，第一条建议是主备环境部署在同一台服务器，负载均衡允许部署在不同的服务器，但是通过心跳功能相互检测）
2 个赞
请仔细阅读我的回复。
1 个赞
能不能安装的时候就保留一个正常版本（安装后的默认版本），遇到问题就可以直接回滚（
2 个赞
我选择手动备份（
2 个赞