综合 Databasus：PostgreSQL 备份工具，用容器真跑一遍 restore 做还原验证

2026-09-27 21:31:10

Databasus：PostgreSQL 备份工具，还原验证会真起一个容器跑一遍 restore

项目信息

GitHub：https://github.com/databasus/databasus
官网：https://databasus.com
还原验证说明：https://databasus.com/restore-verification
License：Apache 2.0（免费、开源、自托管）

它解决的具体问题：备份文件在，不代表能恢复

大多数备份脚本的验收标准是「文件生成了、大小不为 0、校验和通过」。这些都不足以证明数据能回来：dump 中途被截断、压缩流损坏、权限或扩展缺失、恢复时版本不兼容，都可能让一个「完整」的备份在真正恢复那天失败。Databasus 把「可恢复性」当作独立的验证环节来做，而不是靠备份任务的退出码。

物理备份、逻辑备份与 WAL 流式 PITR

物理备份基于 PostgreSQL 原生的增量备份机制，直接做集群文件级拷贝：

Full：整个集群的完整自包含副本
Incremental：只存相对上一次 full 之后变化的部分
WAL streaming：持续捕获写入流，支持 Point-in-Time Recovery（PITR），目标是低 RPO/RTO

逻辑备份是数据库自身的 dump，使用引擎特有的二进制格式，压缩后可直接用于并行恢复。

取舍上，物理 + WAL 的路径能给出连续时间点恢复能力，代价是备份文件与 PostgreSQL 主版本、文件布局强绑定，跨大版本迁移不适用；逻辑 dump 更通用、可选择性恢复单库，但只能恢复到 dump 那一刻，RPO 取决于调度间隔。

还原验证：起容器、真跑 restore、比对大小

这是它比较难被简单脚本替代的一段。验证不是查校验和，而是真的恢复一次：

触发时机：每次备份之后，或按单独的调度
真实恢复：拉起一个数据库容器，执行 restore，并把恢复后的数据大小与备份对比
报告：列出每张表及其行数
通知可选：发送完整报告，或只在失败时告警

也就是说，配合 CI 里的集成测试，每个 PR 都会跑完整的 backup-then-restore 流程。日常运行的验证同样走真实容器，而不是模拟。

保留策略：时间、数量、GFS

Time period：按时间窗口保留
Count：按份数保留
GFS（Grandfather-Father-Son）：小时、天、周、月、年各层级独立保留，互不挤占
另外可设置单个备份的大小上限与总大小上限

调度支持 hourly / daily / weekly / monthly 或 cron 表达式，可选精确时间点；压缩比常见在 4–8x，CPU 开销约 20%。

存储、通知与安全

存储目标：Local、S3、Cloudflare R2、Google Drive、NAS、Dropbox、SFTP、Rclone。

通知渠道：Email、Telegram、Slack、Discord、Teams、Mattermost、webhooks。

安全方面：AES-256-GCM 加密、零信任存储、密钥加密存储、默认使用 read-only 用户连接被备份的库、双因素认证。团队功能包含 Workspaces、访问管理、审计日志、角色、OpenTelemetry 日志。

支持的数据库版本

PostgreSQL：14、15、16、17、18（物理与逻辑）
MySQL：5.7、8.0、8.4、9、26（仅逻辑）
MariaDB：5.5、10、11、12、13（仅逻辑）
MongoDB：4.2+、5、6、7、8（仅逻辑）

物理备份与 WAL PITR 目前只对 PostgreSQL 开放。

安装

自动化脚本（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 run -d --name databasus -p 4005:4005 -v ./databasus-data:/databasus-data --restart unless-stopped databasus/databasus:latest

镜像也可以从 GHCR 拉：ghcr.io/databasus/databasus:latest。

Docker Compose：

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

Kubernetes（Helm，OCI registry）：

helm install databasus oci://ghcr.io/databasus/charts/databasus -n databasus --create-namespace
kubectl port-forward svc/databasus-service 4005:4005 -n databasus

用 LoadBalancer 暴露加 --set service.type=LoadBalancer；用 Ingress 加：

--set ingress.enabled=true --set ingress.hosts[0].host=backup.example.com

首次配置与运维命令

打开 http://localhost:4005 创建第一个账号（该账号管理整个实例）
添加要备份的数据库
配置调度（hourly/daily/weekly/monthly/cron）
设置连接
选择存储
配置保留策略（时间/数量/GFS）
配置通知
保存并启动

重置密码与查看管理员：

docker exec -it databasus ./main --new-password="YourNewSecurePassword123" --email="owner@example.com"
docker exec -it databasus ./main --list-admins

建议把 Databasus 自身的配置也纳入备份，并单独保存加密密钥——服务器丢失时，没有密钥就无法恢复加密备份。

CI 侧的安全与可靠性工程

每次 commit/PR 的流水线包含：CodeQL、CodeRabbit + gitleaks + semgrep、Codex Security 深度审计、Dependabot 对照 GitHub Advisory DB、Dependency Review Action 阻断新引入的 HIGH/CRITICAL CVE、Trivy 扫描镜像与 Dockerfile；GitHub Actions 固定到完整 commit SHA，权限按最小化配置。集成测试针对每个受支持引擎的主要版本跑真实数据库容器，每个 PR 都会执行完整的备份再恢复流程。

什么情况下不必用它

如果只需要一个几十行的 pg_dump + cron + 上传脚本，且库很小、可接受每天一次全量、恢复失败时人工处理，Databasus 的容器、存储与调度抽象就是额外负担。只跑逻辑备份、且不关心 PITR 和自动还原验证的场景，一个 shell 脚本已经够用；反之，一旦需要低 RPO、跨多种存储投递、或者希望「备份能恢复」这件事被持续验证，它的价值才成立。