Databasus v3.63.1 介绍与选型指南

目标：面向需要为 PostgreSQL / MySQL / MariaDB / MongoDB 建立自动化备份体系的 DevOps 与数据库管理员，讲清 Databasus 是什么、能做什么、怎么用最省心，并在同类备份工具中给出量化选型依据。本文为纯联网溯源整理，信息来源与查询日期均已标注（查询日期 2026-10-24），未做本地实测。

一、环境信息

本章说明本文信息采集的来源与环境口径，便于读者复核每一条事实。

• 信息采集方式：公开官网（databasus.com）、GitHub 仓库（github.com/databasus/databasus）README 与官网文档页面联网溯源；
• 查询日期：2026-10-24；
• 本文涉及的最新稳定版本：v3.63.1（来源：Docker Hub 镜像标签列表中最高语义化版本，且 latest 标签与 v3.63.1 镜像摘要一致，经 registry 清单核对，查询日期 2026-10-24）；
• 项目许可：Apache 2.0（来源：仓库 README「License」节）；
• 社区规模参考（来源：官网首页 2026-10-24 展示值）：GitHub Stars 约 9,096、Docker 镜像拉取量约 2.2M。

⚠️ 说明：官网首页的 Stars/Docker Pulls 数值由前端脚本动态渲染，静态抓取页面不含具体数字；本文引用的 9,096 / 2.2M 来自 2026-10-24 当日搜索引擎收录的官网首页快照，仅作社区活跃度参考，精确值以 GitHub 仓库页面实时显示为准。

二、软件概述

本章回答「Databasus 是什么、从哪来、由谁维护」，给读者建立对项目的第一层认知。

2.1 项目定位

Databasus 是一款免费、开源、可自托管（self-hosted）的数据库备份管理工具，聚焦三大能力：自动化备份调度、Point-in-Time Recovery（PITR，时间点恢复）与恢复验证（Restore Verification）。项目前身为 Postgresus（PostgreSQL 备份工具），后扩展支持多数据库引擎并更名为 Databasus；官网 FAQ 明确说明「Databasus is the new name for Postgresus」，二者数据目录与内部数据结构不同，官方提供迁移指引而非直接复用（来源：官网 Installation 页「Migrating from Postgresus」节，查询日期 2026-10-24）。

支持备份的数据库引擎与版本（来源：仓库 README「Supported databases」节，查询日期 2026-10-24）：

关键结论：只有 PostgreSQL 同时支持物理备份与 PITR；MySQL/MariaDB/MongoDB 走各引擎原生逻辑转储（mysqldump/mongodump 等）路线。

2.2 出身与维护状态

• 首次发布：2025 年（来源：官网 FAQ「Databasus launched in 2025 and outpaced both within its first year」，查询日期 2026-10-24）；
• 维护模式：个人主导 + 社区共建，README 提供 Telegram 社区（@databasus_community）与贡献指南（databasus.com/contribute）；
• 商业/组织背书：2026 年 3 月同时入选 Anthropic「Claude for Open Source」与 OpenAI「Codex for Open Source」两个开源支持计划（来源：仓库 README「AI disclaimer」节与官网 FAQ「oss-programs」条目，查询日期 2026-10-24）；
• 版本节奏：从镜像标签序列可见小版本发布频繁（v3.x 系列自 v3.0.0 演进至 v3.63.1，补丁版本迭代密集），处于活跃开发期（来源：Docker Hub 标签列表，查询日期 2026-10-24）；
• 演进决策透明：官网 FAQ 引用架构决策记录 ADR-0008（PG17 原生备份）与 ADR-0009（远程物理备份取代 agent 模式），并明确 agent 模式在 v3.42.0 之后被移除（来源：官网 FAQ「Why did Databasus move away from agent-based backups?」，查询日期 2026-10-24）。

2.3 部署形态与技术栈

• 部署形态：以 Docker 容器交付为唯一官方运行形态，提供自动化安装脚本、docker run、Docker Compose、Kubernetes Helm Chart 四类安装途径，另有「Compose + Caddy 反向代理」的生产组合模板（来源：官网 Installation 页，查询日期 2026-10-24）；
• 最小资源要求：1 CPU 核心、500 MB 内存、5 GB 安装空间（另加备份存储所需空间），Docker Engine 20.10+ 与 Docker Compose v2.0+（来源：官网 Installation 页「System requirements」节）；
• 技术栈：主体为 Go 实现（恢复验证 agent 官方描述为「a small Go binary」；官方 compose 健康检查命令为镜像内置的 databasus healthcheck），配置与元数据持久化使用内嵌 PostgreSQL（数据目录 /pgdata，来源：官网 FAQ「How to backup Databasus itself?」节）；
• 数据面：所有备份数据、加密密钥均保存在用户自己的服务器与存储中，官网反复强调「Files are always owned by you」的隐私优先设计。

三、核心架构

本章拆解 Databasus 的组件构成与数据流，帮助读者理解它「怎么把备份做出来、存起来、验真伪」。

3.1 组件构成

Databasus 是单体服务架构，一个实例内聚以下职责（来源：官网各文档页交叉归纳）：

1. Web 管理台：仪表盘、数据库接入向导、备份/存储/通知配置、恢复验证结果查看、审计日志；首个注册账号自动成为实例管理员；
2. 调度器与备份执行器：按 hourly/daily/weekly/monthly/cron 计划触发备份任务，远程连接目标数据库执行转储或物理备份流；
3. 内部 PostgreSQL：存放实例配置、数据库连接信息、备份历史元数据；敏感字段（密码、令牌、webhook 密钥）以 AES-256-GCM 加密后落库，加密主密钥保存在数据目录 secret.key 文件中，不入库（来源：官网 Security 页「Level 1」节）；
4. 恢复验证代理（可选，独立部署）：一个 Go 二进制，注册到 Databasus 后从任务队列领取验证作业，在代理所在机器上拉起与目标引擎大版本一致的临时数据库、执行真实恢复、按表核对行数后回传报告（来源：官网 Restore verification 页「What is a verification agent?」节）。

3.2 两条备份数据流

逻辑备份流（全引擎支持）：原生转储工具（如 pg_dump custom 格式 + zstd level 5 压缩）→ 压缩 → AES-256-GCM 加密 → 存储目的地（本地/S3/Google Drive/FTP 等）。官网 FAQ 说明选择 pg_dump custom 格式而非纯 SQL 格式，兼顾创建速度、恢复速度与体积（宣称比纯 SQL 最多小 20 倍）（来源：官网 FAQ 与 Security 页，查询日期 2026-10-24）。

物理备份流（仅 PostgreSQL 17+）：pg_basebackup 全量 → pg_basebackup --incremental 块级增量（依赖 PostgreSQL 17 服务端 WAL 摘要 summarize_wal）→ pg_receivewal 持续 WAL 流；恢复时用 pg_combinebackup 重建可运行数据目录，再回放 WAL 至目标时刻。物理备份从 Databasus 所在主机远程发起，走 PostgreSQL 标准复制协议，数据库服务器上无需安装任何东西，也兼容 RDS/Cloud SQL 这类不允许登录装软件的托管库（来源：官网 FAQ「How do physical and PITR backups work?」，查询日期 2026-10-24）。

💡 技术拓展：数据库备份的两大流派——

流派	原理	优点	缺点
逻辑备份	用引擎自带转储工具导出数据与结构（如 pg_dump/mysqldump/mongodump）	跨版本兼容好、产物紧凑、可恢复单库单表	大库恢复慢、不天然支持 PITR
物理备份	复制数据库集群的物理文件 + WAL 日志（如 pg_basebackup）	恢复快、支持块级增量与时间点恢复	绑定引擎大版本、通常要求主版本一致

Databasus 对 PostgreSQL 同时提供两条流派（物理要求 PG 17+），对 MySQL/MariaDB/MongoDB 仅提供逻辑流派；本文介绍的工具主推「逻辑保底、物理进阶」的组合。

3.3 安全与验证设计

• 三层安全模型（来源：官网 Security 页）：① 敏感数据加密（AES-256-GCM，主密钥在 secret.key）；② 备份文件流式加密（每个备份用「主密钥 + 备份 ID + 随机盐」派生的独立密钥）；③ 只读权限强制校验（接入数据库前在角色级/库级/表级三层检查写权限，发现写权限即告警，并提供一键创建只读用户的能力）；
• 恢复验证：官网口号是「A backup that finishes without error is not the same as a backup you can actually restore」——备份成功不等于可恢复，Databasus 定时把最新备份真实恢复到临时数据库、逐表清点行数并出报告；队列策略为「同库新备份到达时取消排队中的旧验证，只验最新」（来源：官网 Restore verification 页）。

四、功能特性

本章按「备份、存储、通知、验证、安全、团队」六个维度清点功能，均为官方文档声明项（来源：官网首页 Features 与各专题页，查询日期 2026-10-24）。

4.1 备份能力

• 备份类型：物理全量、物理块级增量、WAL 持续流（PITR）、逻辑转储（引擎原生二进制格式，压缩流式直传存储）；
• 调度粒度：hourly / daily / weekly / monthly / cron，支持指定低峰时刻（如凌晨 4 点）；
• 压缩：内置智能压缩（官方口径 4–8 倍空间节省、约 20% 耗时开销；逻辑 PostgreSQL 固定 pg_dump custom + zstd level 5）；
• 健康检查：按分钟级间隔探测数据库连通性，连续失败判定宕机并通知，恢复时同样通知，探测历史可视化。

4.2 存储目的地

Local、S3 及兼容（含 Cloudflare R2）、Google Drive、Azure Blob Storage、NAS、FTP、SFTP、Dropbox、rclone（号称桥接 70+ 云存储）（来源：官网 Storages 页）。

4.3 通知渠道

Slack、Discord、Telegram、Microsoft Teams、Mattermost、Email、自定义 Webhook；成功/失败事件可分别开关（来源：官网 Notifiers 页）。

4.4 恢复验证

• 触发方式：每次备份后（After backup）或 hourly/daily/weekly/monthly/cron 计划；
• 执行方式：验证代理在本机拉起同大版本临时数据库真实恢复，报告含恢复退出码、恢复后库大小、schema/表清单与逐表行数；
• 结果状态机：Pending → Running → Successful / Failed / Canceled；
• 代理资源预算：--max-cpu/--max-ram-mb/--max-disk-gb/--max-concurrent-jobs 四个预算参数按并发均摊，单作业下限 1 CPU + 512 MB。

4.5 保留策略

按时间周期（如 7 天/3 个月/1 年）、按数量（如最近 30 份）、GFS 祖孙三代分层（小时/天/周/月/年独立保留）、按单份与总量大小上限，四类可组合控制存储成本。

💡 技术拓展：GFS（Grandfather-Father-Son，祖-父-子）保留法——

层级	保留对象	典型策略
子（Son）	最近若干份高频备份（如每日）	保留 7 份日备
父（Father）	每周挑一份升级为周备	保留 5 份周备
祖（Grandfather）	每月挑一份升级为月备	保留 12 份月备

GFS 用滚动的「升级」机制让近期备份密、远期备份稀，兼顾恢复粒度与长期归档成本；Databasus 将其做成内置选项，无需人工滚动归档。

4.6 安全与团队协作

• 登录安全：密码登录可强制两步验证（邮箱六位码，10 分钟有效、错 5 次作废）；另支持 Google/GitHub OAuth 登录；
• 权限模型：工作区（Workspace）隔离资源，查看者/成员/管理员/所有者四级角色；
• 审计与日志：全量审计日志记录用户操作，支持 OpenTelemetry 对接外部日志系统（默认同时落本地文件）；
• 合规工程：官方声明 CI 覆盖 CodeQL 静态扫描、gitleaks/semgrep 机密检查、Trivy 镜像扫描、Dependabot CVE 监控，并禁止「vibe code」合入（来源：官网 Security 页「Security & reliability engineering」节）。

五、快速开始（最小可用示例）

本章给出官方安装路径的最小可用流程，便于读者十分钟内把实例跑起来。以下命令均为官方文档原文（来源：官网 Installation 页与仓库 README，查询日期 2026-10-24），本文未做本地实测验证。

5.1 方式一：自动化安装脚本（官方推荐，仅 Linux）

sudo apt-get install -y curl && \
sudo curl -sSL https://raw.githubusercontent.com/databasus/databasus/refs/heads/main/install-databasus.sh \
| sudo bash

脚本行为：自动安装 Docker 与 Compose（若缺失）→ 写入 /opt/databasus/docker-compose.yml → docker compose up -d 启动并配置开机自启。安装完成后访问 http://<服务器IP>:4005。

5.2 方式二：Docker Compose（推荐用于生产管理）

在服务器上创建 docker-compose.yml：

services:
  databasus:
    container_name: databasus
    image: databasus/databasus:latest
    ports:
      - "4005:4005"
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "databasus", "healthcheck"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 60s

启动并验证：

docker compose up -d

官方提示首次启动最长约 2 分钟。启动后访问 http://<服务器IP>:4005，注册的第一个账号即实例管理员；随后按向导「New Database → 连接信息 → 备份计划 → 存储目的地 → 通知渠道」完成首个备份任务。

5.3 方式三：Kubernetes（Helm Chart）

helm install databasus oci://ghcr.io/databasus/charts/databasus \
  -n databasus --create-namespace

访问方式可选 port-forward、LoadBalancer 或 Ingress，完整参数见官方 Helm 文档。

5.4 健康检查端点（监控对接）

GET http://<host>:4005/api/v1/system/health

健康返回 200；异常返回 503 并附原因（内部数据库、缓存、磁盘用量超 95%、数据库客户端工具、备份调度器、验证代理存活度六项检查）。该端点无需认证、CORS 开放，官方明确提示它只用于外部监控告警，不要当作容器或 K8s 存活探针（因为「降级但仍在服务」也会返回 503，会误杀健康进程）（来源：官网 Installation 页「Monitoring / status endpoint」节）。

六、适用场景与限制

本章帮读者判断「该不该选它」，分正反两面陈述。

6.1 典型适用场景

1. 中小团队统一备份入口：多台服务器上的 PostgreSQL/MySQL/MariaDB/MongoDB 想收敛到一个带 Web UI 的备份平台，摆脱散落的 crontab + 脚本；
2. PostgreSQL 17/18 生产库的 PITR 需求：需要「恢复到任意一秒」的低 RPO 容灾，Databasus 基于 PG17 原生块级增量 + WAL 流实现，且远程发起、兼容 RDS/Cloud SQL；
3. 对备份真实性存疑的合规场景：恢复验证功能定时真恢复 + 逐表行数报告，把「备份能不能用」变成可审计的客观结论；
4. 备份文件外发云存储的安全诉求：AES-256-GCM 流式加密 + 零信任存储设计，云盘泄露也不泄数据；
5. 需要备份成功/失败即时告警的运维体系：Slack/Telegram/Teams/Webhook 多渠道通知 + 数据库健康检查。

6.2 已知限制

1. 物理备份与 PITR 仅限 PostgreSQL 17+：14/15/16 只能用逻辑备份（来源：官网 FAQ「Physical backups require PostgreSQL 17 or newer」）；
2. MySQL/MariaDB/MongoDB 仅逻辑备份：无物理级增量与 PITR 能力；
3. 恢复验证代理需要额外一台有 Docker 的机器：代理会拉起临时数据库容器执行恢复，目标机需备足「备份文件体积 + 数据库原始体积 + 最高 5 GB 安全余量」的磁盘（来源：官网 Restore verification 页）；
4. 单实例形态：官方文档未提供多实例高可用方案，Databasus 自身的可用性依赖服务器本身 + 对 /opt/databasus/databasus-data（含 secret.key 与 /pgdata）的外部备份；
5. 版本演进快：v3.x 小版本迭代密集（曾发生 agent 备份模式在 v3.42.0 后移除的破坏性变更），生产升级前应关注 Release Notes 并固定版本号而非盲目追 latest。

七、同类选型对比

本章给出量化对比表，帮助读者在 Databasus 与主流备份工具间做选择。数据来源：官网 FAQ（pgBackRest/WAL-G 星数与发布年份，查询日期 2026-10-24）、各项目官方仓库 README/官网；站内同类工具的深度评测可参见《UrBackup 2.5.38 介绍与选型指南》与《rdiff-backup 介绍与选型指南》。

7.1 量化对比表

表格解读：数据库专项能力上，Databasus 是唯一「Web UI + 多引擎 + PITR + 备份加密 + 恢复验证 + 通知」六项全有的工具；pgBackRest/WAL-G 胜在成熟度与极致恢复控制，但没有管理界面、验证要靠人；UrBackup/rdiff-backup 是文件级备份利器，与数据库专项工具不在同一赛道，可作互补而非替代。

7.2 选型建议（如果…则…）

• 如果只用 PostgreSQL 且团队 DBA 能力强、追求恢复控制粒度 → pgBackRest 或 WAL-G（CLI 流派天花板）；
• 如果要管 PG + MySQL + MongoDB 多引擎、希望开箱即用的 Web 界面 → Databasus；
• 如果备份对象是整机/文件而非数据库 → UrBackup 或 rdiff-backup（见站内专栏）；
• 如果托管库（RDS/Cloud SQL）不能登录装软件 → Databasus（远程物理备份走复制协议）或 pgBackRest/WAL-G（同样支持远程流式备份）；
• 如果把「备份一定能恢复」当硬指标 → Databasus 的恢复验证是目前同类中唯一内置「真恢复 + 行数报告」的方案；
• 密码/凭据类敏感数据的备份与托管属另一命题，可参考《Psono v7.5.3 介绍与选型指南》。

八、参考链接

1. Databasus 官网：https://databasus.com/
2. Databasus GitHub 仓库：https://github.com/databasus/databasus
3. 官网安装文档：https://databasus.com/installation
4. 官网恢复验证文档：https://databasus.com/restore-verification
5. 官网安全文档：https://databasus.com/security
6. 官网存储目的地列表：https://databasus.com/storages
7. 官网通知渠道列表：https://databasus.com/notifiers
8. 官网 FAQ：https://databasus.com/faq
9. 站内同类备份工具实测专栏：《UrBackup 2.5.38 介绍与选型指南》、《rdiff-backup 介绍与选型指南》、《rdiff-backup 常用 CLI 命令详解》