OpenRun 把 Litestream 藏进平台，SQLite 备份简单了但仍不是高可用
部署平台 OpenRun 为 SQLite 应用加入内置 Litestream 支持。用户不必再自己准备 sidecar、守护进程和对象存储脚本，平台会持续复制数据库的 WAL 变化，并在实例启动而本地数据库缺失时从远端恢复。
作者：林岚｜OC 开发者生态编辑
部署平台 OpenRun 为 SQLite 应用加入内置 Litestream 支持。用户不必再自己准备 sidecar、守护进程和对象存储脚本，平台会持续复制数据库的 WAL 变化，并在实例启动而本地数据库缺失时从远端恢复。
一句话结论：这是把 SQLite 灾难恢复从一套运维拼装变成平台默认能力，但异步复制仍不能等同于高可用：故障时可能丢失最后一小段数据，恢复也需要时间，单写节点依然是单点。
SQLite 的优势是应用和数据库放在同一个进程附近：无需连接池、网络往返和独立数据库服务。它的麻烦也来自同一点。本地磁盘一旦随实例丢失，数据库不会自动出现在另一台机器上。Litestream 的做法是持续读取写前日志，把增量变化复制到 S3 一类的远端存储，并支持恢复到最新状态或指定时间点。
OpenRun 把这套机制封装进部署流程。按照其说明，应用只需声明数据库路径和复制目标；首次启动时，平台可在数据库不存在的情况下执行 restore，运行期间再持续 replicate。相比让每个团队各写一套启动脚本，这能减少路径写错、进程先后顺序不稳和备份根本没有运行等低级事故。
但“持续复制”很容易被产品界面误读成“实时双机”。Litestream 的复制是异步的。主机突然损坏时，尚未上传的 WAL 变化仍可能丢失；新实例要下载快照和增量日志，恢复时间会随数据库体积和网络变化；多个实例也不能因为共享同一份备份就同时安全写入。它解决的是恢复点与恢复流程，不是共识、故障转移和并发写入。
Litestream 官方恢复文档还强调了几个实用边界：默认不会覆盖已经存在的数据库；可以恢复到某个时间点；恢复后可做快速或完整的完整性检查。这些特性让误操作回滚和灾难恢复更可靠，却也意味着平台必须明确告诉用户何时触发恢复、选中了哪个 generation，以及完整性检查失败时会怎样处理。
对小型 SaaS、内部工具和单区域服务，这种组合很有吸引力。它保留 SQLite 的简单部署和低延迟，同时把“整台机器没了怎么办”变成可操作的问题。真正需要多区域写入、极低 RPO 或自动秒级切换的系统，仍应选择拥有复制协议和故障转移机制的数据库，而不是把备份产品当成集群。
关键事实
- OpenRun 将 Litestream 的复制与恢复集成到 SQLite 应用部署流程。
- Litestream 支持持续复制、最新状态恢复和时间点恢复，并可执行完整性检查。
- 复制是异步的，不能提供同步多副本、自动主从切换或多写节点能力。
OC 判断
平台最有价值的工作，往往不是发明新的数据库，而是把正确但容易漏掉的运维动作变成默认路径。OpenRun 这次集成降低了 SQLite 的恢复门槛；它是否值得信任，则要看平台能否同时公开最后复制时间、恢复点、失败告警和演练方法。看不见的备份，不应被当成已经验证的备份。
为什么重要
- 对独立开发者：可以保留 SQLite 的低复杂度，同时获得远端恢复能力。
- 对运维：仍需设定 RPO/RTO、监控复制延迟并定期做真实恢复演练。
- 对平台：必须避免用“内置复制”模糊备份和高可用之间的差别。
评论
围绕这篇文章补充信息、提出问题或分享观察。