常见问题

这里汇总了关于 Databasus 最常见的问题的答案，包括安装、配置和备份策略。

为什么 Databasus 的逻辑 PostgreSQL 备份不使用原始 SQL dump 格式？

在逻辑备份方面，Databasus 使用 pg_dump 的自定义格式加 zstd 压缩（级别 5），而不是纯 SQL 格式，因为它在以下几方面之间达到了最高效的平衡：

• 备份创建速度
• 恢复速度
• 文件压缩比（最多比纯 SQL 格式小 20 倍）

这个决定是在对不同的 PostgreSQL 备份格式和压缩方式做了大量测试和基准评测之后做出的。测试详情见这篇文章： PostgreSQL backups: comparing pg_dump speed in different formats and with different compression。

Databasus 不会加入原始 SQL dump 格式，因为：

• 额外的多样性对用户体验没有好处；
• 会增加代码维护成本；
• 当前的 dump 格式适用于 99% 的场景

通过 .sh 脚本安装时，Databasus 安装在哪里？

Databasus 安装在 /opt/databasus/ 目录。

物理备份和 PITR（时间点恢复）备份是如何工作的？

Databasus 从自己的主机远程执行物理备份，通过标准的复制协议连接你的 PostgreSQL，因此数据库服务器上无需安装任何软件。如果数据库位于封闭网络中，Databasus 可以通过连到内部主机或跳板机的 SSH 隧道访问它，数据库永远不必暴露到公网。

备份的工作方式：

• 全量备份用 pg_basebackup 创建，直接流式传输到 Databasus
• 块级增量备份使用 pg_basebackup --incremental，由 PostgreSQL 17 的服务端 WAL 摘要（summarize_wal = on）跟踪变更，因此只传输发生变化的块
• WAL 通过 pg_receivewal 持续流式传输，保证两次备份之间的恢复链完整
• 物理备份要求 PostgreSQL 17 或更新版本；在更早的版本上使用逻辑 pg_dump 备份

恢复的工作方式：

• pg_combinebackup 从全量备份及其增量链重建出可运行的数据目录
• 然后 PostgreSQL 重放 WAL 到你选择的目标时间，可以恢复到两次备份之间的任意一秒
• 启动 PostgreSQL 后，它会完成恢复，提升为主库并恢复正常运行

为什么我们使用 PG 17 原生备份：

• 它复用 PostgreSQL 自身的备份机制而不是重新发明，你得到的是背后有数千个测试和边界用例保障、久经考验的内部实现
• 它适用于远程数据库，包括 Amazon RDS 和 Google Cloud SQL 这类暴露复制协议但禁止在主机上安装软件的托管服务
• 它带来接近零的数据丢失，可以恢复到两次备份之间的任意一秒

为什么 Databasus 放弃了基于 agent 的备份？

早期版本的 Databasus 附带一个备份 agent：一个运行在数据库主机上的二进制程序，用来传输 WAL 并在本地创建物理备份。这个最初的实现被证明是个错误，我们把它移除了。物理备份现在由 Databasus 主机远程执行，如上文所述。

为什么 agent 是错误的方向：

• 它是一个简陋的实现，只是在全量备份之上复制 WAL，导致 RTO 很长
• 用户必须同时配置 Databasus 和一个独立的 agent，而在一个地方远程完成所有事情要简单得多
• 因为 agent 位于主系统之外，很难覆盖所有测试用例
• agent 真正解决的问题只有一个：访问从外部无法触达的数据库。对 99% 的用户来说，把 Databasus 部署在私有网络里或通过 SSH 连接就已经解决了，所以 agent 是在重新造轮子，把一个简单问题弄得比实际需要复杂得多
• 它无法在 RDS 和 Cloud SQL 这类托管数据库上运行：这些服务禁止在主机上安装软件，却已经暴露了复制协议，所以无论如何都需要一条远程路径
• 它还带来大量边界情况。连接中断、agent 更新管理、从独立进程收集日志都很痛苦，而系统的活动部件越少，日常使用就越可靠

我们确保现有备份安全无虞。如果你从仍有 agent 备份的版本升级，Databasus 不会悄悄进行：它会提示你这一变化，让你选择留在受支持的 3.42.0 版本，或在升级前自行删除旧的 agent 备份。基于 agent 的实现在 3.42.0 及之前的版本中仍然可用，并会长期继续工作，所以不会有任何东西坏掉。

完整的论证可以在架构决策记录中查看： ADR-0008: PG17-native backups with mandatory WAL summary 和 ADR-0009: remote physical backups instead of agents。

Databasus 开发中如何使用 AI？

在 issue 和讨论中，有人问到项目开发中的 AI 使用情况。由于项目聚焦于安全性、可靠性和生产环境使用，有必要说明 AI 在开发流程中是如何使用的。

AI 被用作以下工作的辅助：

• 验证代码质量和搜索漏洞
• 清理和改进文档、注释和代码
• 开发过程中的辅助
• 在人工审查之后复查 PR 和提交

AI 不用于：

• 编写全部代码
• "Vibe code" 方式
• 未经人工逐行验证的代码
• 没有测试的代码

项目具备：

• 扎实的测试覆盖（包括单元测试和集成测试）
• 带测试和 lint 的 CI/CD 流水线自动化，保证代码质量
• 由在大型安全项目中经验丰富的开发者进行验证

所以 AI 只是开发者用来提高生产力和保证代码质量的助手和工具。工作由开发者完成。

另外需要指出的是，我们并不区分糟糕的人写代码和 AI vibe code。任何代码要被合并都有严格的要求，以保持代码库可维护。

即使代码是人手动写的，也不保证会被合并。Vibe code 完全不被允许，此类 PR 默认全部拒绝（见贡献指南）。

我们同样重视快速的 issue 处理和安全漏洞报告。

如何备份 Databasus 自身？

如果你想备份自己的 Databasus 实例（包括所有配置、数据库和凭据），按以下步骤操作：

1. 进入 /opt/databasus（或你安装 Databasus 的目录）
2. 进入 databasus-data 目录

需要备份的内容：

• secret.key：你的凭据的加密密钥
• /pgdata：Databasus 的内部 PostgreSQL 数据库，包含你的全部配置和备份元数据

如果你使用本地存储保存备份，也可以一并备份 backups 文件夹。

重要：恢复有两种不同的场景：

• 不通过 Databasus 界面恢复备份：只需要 secret.key 文件就能恢复数据库备份，不需要 Databasus 或它的内部数据。详细步骤见手动恢复指南。
• 恢复 Databasus 界面及全部配置：如果你想恢复带有全部配置、备份计划和备份历史的 Databasus 界面，需要同时备份 secret.key 和 /pgdata 文件夹（后者包含加密元数据和 Databasus 的全部配置）。

在另一台服务器上恢复 Databasus：用备份好的文件重建 databasus-data 目录结构，然后启动 Databasus 即可。

Databasus 如何获得 Anthropic 和 OpenAI 开源项目计划的支持？

2026 年 3 月，Databasus 同时被 Anthropic 的 Claude for Open Source 和 OpenAI 的 Codex for Open Source 计划接纳。项目被两家全球领先的 AI 公司认可为对行业重要的开源软件，这对我们来说非常宝贵，尤其考虑到两个计划的准入门槛都很高。

这对用户意味着什么？这是又一个可靠性的佐证：项目经过独立评估，被行业领导者认可为值得支持的关键基础设施。因此，得益于对最新且不限量的 AI 的使用权限，我们有了更高的代码质量、更快的安全审查和持续活跃的开发。

尽管加入了这些计划，Databasus 仍按AI 使用一节所述保持严格的 AI 使用规则。所有代码都要求逐行人工验证、完整的测试覆盖和经验丰富的开发者审查。Vibe coding 不被允许。AI 始终是开发者的工具，而不是人类判断的替代品。