sealdice-core
sealdice-core copied to clipboard
sealdice
使备份功能覆盖可写/所有文件
我的标准是：可能被core写入的文件都值得备份。
按此标准，应该包括：
- （现有的）dice.yaml、serve.yaml、sqlite、文案模版
- 所有自定义回复
yaml - 插件的配置项
plugin-configs.json - 插件的buntdb AOF
storage.db（值得商榷，可能体积很大）
我的标准是：可能被core写入的文件都值得备份。
我倾向于全量备份，或者至少开放出全量备份的能力。
作为备份应该尽最大可能恢复备份时的数据状态，只读文件也应该是当时的状态之一。
体积问题确实值得注意，但是在拥有自动清理的情况下我认为这个占用是可以接受的。
目前考虑是两个选择：
- 默认全量备份，可以通过提供勾选来控制备份范围。
- 自动备份是轻量的，手动触发的（包括但不限于UI上点击备份）是全量的。
我的标准是：可能被core写入的文件都值得备份。
我倾向于全量备份，或者至少开放出全量备份的能力。
作为备份应该尽最大可能恢复备份时的数据状态，只读文件也应该是当时的状态之一。
体积问题确实值得注意，但是在拥有自动清理的情况下我认为这个占用是可以接受的。
目前考虑是两个选择：
- 默认全量备份，可以通过提供勾选来控制备份范围。
- 自动备份是轻量的，手动触发的（包括但不限于UI上点击备份）是全量的。
提一点拙见：我比较赞同选择1的后半句『可以通过提供勾选来控制备份范围』，但我倾向默认备份是『轻量备份』，即程序启动时已预先设定一个最小的备份范围。而用户后续可通过UI勾选，自行设定更大的备份范围，若用户勾选的备份范围覆盖了磁盘占用较大的部分，除了提醒用户可能造成磁盘大量占用外，还应推荐用户开启『自动清理』。至于『自动备份』与『手动备份』的范围，个人认为应当一致。
程序预先已经勾选的备份项（最小备份范围）是否允许用户取消勾选？
但我倾向默认备份是『轻量备份』，即程序启动时已预先设定一个最小的备份范围。而用户后续可通过UI勾选，自行设定更大的备份范围，若用户勾选的备份范围覆盖了磁盘占用较大的部分，除了提醒用户可能造成磁盘大量占用外，还应推荐用户开启『自动清理』。
在 UI 上对勾选范围的不同做不同的提醒是个好主意，这个我觉得蛮有必要。
至于默认是轻量还是全量，这个就是磁盘占用优先，还是数据完整性优先的考虑。
我是这么认为的，一是默认情况下我们应该完整的保留用户数据，防止在没调整过该设置，但又因为意外情况需要备份的用户，能完整地恢复数据（多出来的可以轻易删掉，但少掉的是没法找回的）。二是目前自动清理似乎是个默认行为（存疑，似乎直接升级的用户默认关闭），在有自动清理的情况下磁盘占用的优先级并不是那么高（如果不是默认行为我们应该想办法将其改为默认）。
程序预先已经勾选的备份项（最小备份范围）是否允许用户取消勾选？
不应该，我们应当限制一个最低的备份范围。因为如果确认不需要任何备份，应该是采取关闭该功能的方式。
先实现一个（低于）最小备份的版本，覆盖所有自定义回复 yaml 和 plugin-configs.json，但不包括 storage.db。
这部分内容应当是没有争议的
2024-05-28 讨论结果
需求细化
- 全量备份比最小备份应当增加以下内容, 并保留扩展性
- JS 插件 和 插件数据库
- 牌堆
- 帮助文档
- 敏感词库
- 人名文件 (names)
- 图片资源 (images 目录)
- 只使用一个自动备份, 允许调整备份范围
- 手动备份每次弹出选框要求选择范围
- 备份文件名中要体现备份内容, 使用一个 pow2 数值来标记, 用 16 进制表示以压缩长度
- WebUI 解析文件名展示每个备份的内容
- 原文件名中的随机数, 用文件名其他部分的 hash 替代之, 在前端解析时用来验证文件名的完整性