benbjohnson/litestream

如果你用 SQLite 作为小服务的真实数据库，而目前的备份方式是定时拷贝数据库文件，Litestream 值得花时间评估。它是灾难恢复工具，不是数据库集群；README 中项目仍标注为 beta。

解决什么问题

你有一个单文件 SQLite 数据库在支撑应用，希望出现误写、误删或磁盘损坏时能恢复。现在的做法通常是 cron 定时复制文件，但副本只是某个时间点的快照，最近的写入可能不在里面。Litestream 改变的是这一步：它作为后台进程运行，跟踪数据库的 WAL，把增量变更持续发送到另一个文件或 S3。最终你得到的是一个可用来恢复的副本，而不是隔一段时间才复制一次的快照。

有什么不同

Litestream 只通过 SQLite API 读写数据库，README 称它不会破坏数据库。它的机制是基于 WAL 的增量流：不复制整页数据，而是随写入不断复制变更，因此传输量跟随变更规模，而非整个数据库大小。恢复是一个单独步骤，不在复制循环里完成，所以副本是备份目标，而不是可对外查询的第二节点。

代价是：它更接近连续备份，而不是分布式数据库。README 把 Litestream 定义为独立的灾难恢复工具，恢复副本并不承担读副本的角色。它还会改动源库结构：首次运行时会在源数据库里创建内部表 _litestream_lock，恢复出来的库也会包含它。因此受 Litestream 管理的数据库不能指望与启用前保持字节完全一致，而且运行期间不要删除这张表。项目标记为 beta，监控、恢复演练和凭据管理等运维事项需要你自己承担。

谁值得试

适合：整个持久状态就是一个 SQLite 文件的小应用，文件丢失后果严重，但又不需要热备集群。你希望以较低成本把连续副本放进对象存储，而不引入数据库服务器。

不适合：需要同步复制、多写入者或跨节点读扩展的团队。2022 年一条追踪实时复制迁往 LiteFS 的 HN 讨论可以说明，读副本方向由 LiteFS 承接，Litestream 本身在 README 中是灾难恢复工具讨论。如果你的负载需要复制集群，这不是合适的工具。

使用条件与边界

你需要一个 Litestream 能打开的 SQLite 数据库、一个存储目的地（本地路径或 S3），以及运行后台进程的环境。安装和配置说明在项目网站，README 没有重复这些步骤。你还需要一条实际验证过的恢复流程——副本存在的意义就是恢复，而恢复与复制是分开的。

持续成本在运维侧：保持后台进程运行、确认复制没有落后，并接受源库结构中存在 Litestream 的锁表。工具仍为 beta，依赖它之前应在自己的 SQLite 版本和负载上验证行为。README 没有详细列出支持平台；致谢中提到了 OpenBSD 发布构建，社区文档也涉及在 Kubernetes 上运行项目 README。

HotRepo 点评

HotRepo 只有一条每日榜单观察：2026-10-26 仓库为 14,532 星，当天 +6，出现在榜单快照。单一日期的记录无法判断关注度在上升还是消退，持续性尚不能判断。仓库创建于 2020 年，项目不算新，但年龄并不能证明维护质量。采用前，请对照项目网站确认你的存储目标和 SQLite 配置，并验证从副本恢复在你的环境中可行。