Spectrum 生产环境每小时异地备份方案：基于 Compose 与 S3 的双定时任务架构解析

• 后端
• 前端
• 即时通讯
• 社交

本文基于 Spectrum 仓库中的 docs/operations/hourly-backups.md 操作文档，系统讲解该开源社区平台如何通过两个定时任务（cron job）实现生产数据库的每小时异地备份，并说明备份的获取方式、底层环境变量配置以及备份落地到本地 RethinkDB 的完整恢复流程。读完本文，你将掌握这套"数据库托管商按需备份 + 对象存储异地归档"的轻量级备份方案，并能结合仓库源码理解其连接池与密钥配置的底层实现。

备份方案的背景与设计动机

Spectrum 是一个构建在 RethinkDB 之上的在线社区平台，其生产数据（用户、社区、频道、帖子、消息等）全部托管在数据库服务商 Compose 的 RethinkDB 部署中。为了尽可能避免数据丢失，项目在 pull request #5150 中实现了每小时一次的异地（off-site）备份机制。

原文档明确指出，这套实现"虽然简单，但足以覆盖我们的需求"（"While the implementation is simple, it should cover us well enough"）。因此它的设计哲学是：用最少的组件（两个 cron job）获得可接受的恢复点目标，而非追求复杂的备份编排系统。

备份架构总览：两个定时任务的职责分工

整套方案的核心由两个按小时调度的 cron job 构成，二者错峰执行，形成"先产生备份、再搬运备份"的生产者—消费者链路：

两个任务的执行时间刻意错开 30 分钟：第一个任务先确保 Compose 侧生成一份新的按需备份，第二个任务随后将其取走并归档到 S3，从而保证 S3 中始终存在一份最新的异地副本，且不会因为与备份生成过程"抢时间"而拉到旧数据。

从架构上看，这套方案形成了三条链路：

1. 生产链路：应用 → Compose RethinkDB 主实例（日常读写）；
2. 按需备份链路：cron job 1 → Compose API → 触发 RethinkDB 按需备份；
3. 异地归档链路：cron job 2 → Compose 拉取最新备份 → 上传 S3 bucket。

为什么选择 Compose 的 on-demand backup 而非自建导出

选择"由托管商触发备份"而非应用自行执行rethinkdb dump，有几点从仓库配置中可以推断的原因：

• 一致性保障：Compose 的按需备份由托管商在其基础设施层面完成，能保证数据文件的一致性，避免应用层导出时因连接池并发写入而产生不一致快照；
• 对应用零侵入：备份任务不需要在应用进程内运行任何 RethinkDB 导出逻辑，与业务代码完全解耦；
• 带宽与负载隔离：备份的拉取与上传发生在托管商与 S3 之间（或由外部任务执行），不会占用应用与主数据库之间的生产连接。

备份基础设施的环境变量配置

虽然备份任务本身（cron job 的具体脚本）没有以源码形式保留在仓库中，但从 now.json 的部署环境变量清单中可以完整还原备份基础设施所需的密钥与连接信息：

{ "env": { "S3_TOKEN": "@s3-token", "S3_SECRET": "@s3-secret", "COMPOSE_RETHINKDB_PASSWORD": "@new-compose-rethinkdb-password", "COMPOSE_RETHINKDB_URL": "@new-compose-rethinkdb-url", "COMPOSE_RETHINKDB_PORT": "@new-compose-rethinkdb-port", "BACKUP_RETHINKDB_URL": "@new-backup-compose-rethinkdb-url", "BACKUP_RETHINKDB_PORT": "@new-backup-compose-rethinkdb-port", "COMPOSE_API_TOKEN": "@compose-api-token" } }

这些变量（值通过 Now 平台的@secret引用注入，不落盘明文）分别承担如下职责：

值得注意的是，now.json中同时存在COMPOSE_RETHINKDB_URL/PORT与BACKUP_RETHINKDB_URL/PORT两组地址，说明生产环境实际维护了两个 RethinkDB 部署：一个是主库，另一个专用于备份场景。

备份实例在应用层的作用：双服务器连接池

仓库中的 shared/db/db.js 给出了备份实例的真实用途——它是生产连接池的第二个只读/冗余端点。在IS_PROD分支下，连接配置包含两个服务器：

const PRODUCTION_CONFIG = { servers: [ { password: process.env.COMPOSE_RETHINKDB_PASSWORD, host: process.env.COMPOSE_RETHINKDB_URL, port: process.env.COMPOSE_RETHINKDB_PORT, ...(ca ? { ssl: { ca } } : {}), }, { password: process.env.COMPOSE_RETHINKDB_PASSWORD, host: process.env.BACKUP_RETHINKDB_URL, port: process.env.BACKUP_RETHINKDB_PORT, ...(ca ? { ssl: { ca } } : {}), }, ], };

从这段源码可以推断出备份实例的双重价值：

1. 灾难恢复：当主实例不可用时，连接池可以故障切换到备份实例，保证应用读取路径的可用性（rethinkhaberdashery连接池对多服务器配置天然支持请求分发）；
2. 按需备份的数据源：cron job 拉取的 on-demand backup 正是基于这类备份实例/主实例产生的快照，从而避免备份操作影响主库性能。

此外，db.js 还展示了生产连接的几条关键约束，这些约束同样适用于备份任务的执行环境：

• 必须提供 SSL 证书：cacert文件必须存在于项目根目录，否则生产环境直接抛错（Please provide the SSL certificate to connect to the production database...）。因此备份任务拉取/上传数据时同样需要该证书文件；
• 连接池默认配置：最大连接数 20、最小缓冲连接 20、空闲连接超时 60 分钟、单连接建立超时 30 秒（DEFAULT_CONFIG）。

如何获取最新的每小时备份

原文档给出了两条等效的备份获取渠道：

渠道一：Compose 控制台

1. 登录 Compose 控制台（app.compose.com）；
2. 进入对应的 RethinkDB 部署；
3. 在备份列表中下载最新的 on-demand backup。

该渠道适合运维人员人工核查备份是否按时生成，以及快速下载最近一次快照。

渠道二：S3 bucket

1. 打开项目的 AWS S3 控制台；
2. 进入 Spectrum 备份专用的 bucket（文档中目录结构为Spectrum Backups > Hourly）；
3. 下载最新的备份文件（.tar.gz格式）。

S3 渠道是异地归档的最终落点，也是灾备场景下的首选来源——即使 Compose 本身发生故障，S3 中的备份依然可用。由于第二个 cron job 每小时执行一次，S3 中最坏情况下与最新数据之间的差距在 1 小时左右（即恢复点目标 RPO ≈ 1 小时）。

备份的本地落地：导入生产数据到本地 RethinkDB

获取到备份之后，如何将其还原到本地环境用于调试？仓库中的 docs/operations/importing-rethinkdb-backups.md 提供了完整的操作步骤，这也是每小时备份最常见的消费场景：

1. 打开本地 RethinkDB 管理界面http://localhost:8080/#tables，删除本地的spectrum表（旧数据）；
2. 登录 Space Program AWS 控制台；
3. 进入S3 > Spectrum Backups > Hourly；
4. 下载最新的备份文件.tar.gz；
5. 解压该备份到本地（例如解压到桌面）；
6. 将解压得到的目录重命名为prod-backup；
7. 在终端执行cd ~/Desktop && rethinkdb import -d prod-backup，把生产数据导入本地 RethinkDB；
8. 导入过程可能需要数小时；完成后清理localhost:3000的 localstorage 以重新认证，即可使用完整生产数据调试。

关键命令rethinkdb import -d prod-backup中的-d表示从指定目录导入数据库文件，这也是 RethinkDB 官方推荐的目录级导入方式，可以整体还原全部表结构与数据。

方案的设计取舍与边界

基于原文档"实现简单但够用"的定位，可以总结这套方案在设计上的取舍：

• 优点：架构极简，仅依赖托管商 API 与 S3 两个外部组件；S3 归档实现真正的异地容灾；每小时一个快照，RPO 控制在约 1 小时，足以应对"删除数据/误操作/区域性故障"等常规风险；
• 局限（从实现推断）：备份文件本身未在仓库中发现加密或生命周期管理逻辑（如多版本保留策略），长期运行会持续累积存储成本；恢复为手动流程（下载 + 本地导入），不具备一键还原到生产的自动化能力。

对于希望复刻此方案的自建项目，所需的最小组件为：一个能触发按需备份的数据库托管商 API、一个对象存储（S3 或兼容实现）、两个定时任务，以及now.json中列出的那组密钥环境变量。

相关文档导航

• docs/operations/intro.md：Operations 目录索引，涵盖用户封禁、删除与备份导入等运维操作；
• docs/operations/importing-rethinkdb-backups.md：生产备份的本地导入完整流程；
• now.json：备份基础设施所需的全部环境变量与密钥引用；
• shared/db/db.js：生产/备份双服务器连接池的源码实现。

• 后端
• 前端
• 即时通讯
• 社交