第一个有状态应用上线前，我想先解决备份

目前这个网站主要是静态文件：页面和配置在 Git 中，可以通过 Ansible 再部署。曾用来验证部署路径的容器 API 也是临时的，没有承载持久数据。这让我能较放心地调整页面和路由，却也提醒我：第一个真正保存用户或个人数据的应用，不能照搬现在的恢复思路。

配置可重建，不等于数据可恢复

Git 能保存 Caddy 路由、Compose 定义和站点内容；它不应该保存数据库文件、上传内容或密钥。Docker Volume 如果留在单台服务器上，重建配置并不会把其中的数据带回来。即使应用能重新启动，数据缺失也仍是一次失败的恢复。因此，在我上线第一个有状态应用前，需要先把“数据在哪里、丢失后从哪里恢复”写明白。

我还没有选定第一个有状态应用，所以现在没有可靠的体积、写入频率或保留期数字，也没有做过这类应用的恢复演练。直接宣布某个固定备份周期适合所有项目，会显得有把握，实际却缺少依据。更合理的是在应用确定后，按它的真实数据和可接受损失来定恢复目标。

上线前我会问的几个问题

要先区分哪些是可从 Git 或镜像重新生成的文件，哪些是唯一数据。数据库、上传文件、用户生成内容和密钥可能需要不同的备份方法。备份还要离开原机器；如果服务器和备份一起丢失，备份对灾难恢复没有帮助。密钥不应随手放进仓库，但恢复时必须知道如何重新提供它。

另一个关键问题是恢复，而不只是备份任务有没有按时运行。我希望未来能在隔离环境里按文档取回一份备份、启动应用、检查数据可读，再记录耗时和缺口。只有做过这一步，才更有资格说“可以恢复”。实际操作时还要考虑一致性，不能只复制一个正在写入的数据库文件就假设可用。

先留下边界

当前的单机基础设施已经有可重复部署的路径，静态网站的回滚也依赖 Git；这只是无状态部分的能力。有状态应用的数据备份位置、保留期和恢复目标仍是待决定事项。我会让它们成为首个有状态项目上线的前置工作，而不是在出现故障后补一份看起来完整的文档。