向大家道个歉，这周末计划给网站提速，但在昨晚在尝试迁移网站的主体和数据库从日本到香港地域时，发生意外，想通过快照恢复，恰好遇上 Fly.io 的每日数据快照 出现问题，数据暂无法找回 🥲
最近的一个备份在 23年9月1日的 19:14 分，所以先回了一个档。
影响时间：9月1日 - 11月26日早晨
具体范围：
- discussion_id 为 1610 - 1669 的 discussion
- post_id 在 9385 以后的帖子，以及中途编辑过的部分
- 9.1 之后新注册的用户，及所有的记录
当前的补救措施：
- 还原 9.1 的备份，数据库 / Redis 单独抽到一个 vps 去运行（目前走的阿里云香港轻量），后续补充自动化备份方案
- 设置新话题 id 的起始量
ALTER TABLE discussions AUTO_INCREMENT=1670;
- 尽力找服务商看能否要回对应数据，单独作展示
- 考虑搜集一下对应 discussion 被搜索引擎收录的 cache 链接
一些教训：
- 意识：数据安全方面得非常重视，DBA 和开发的关注视角会很不一样；
- 备份：涉及 DB 的操作一定要提前备份一次，不能大意；还需单独考虑异地容灾方案；自动化备份 / 手动的定时检查也很重要；
- 选型：fly.io 本身更侧重边缘计算方面，技术相对要激进，对数据而言更重要的是稳和安全，不太适合放在它们跟随 machine 绑定的 volume 上。
太痛了！
