Databasus：自托管的数据库备份管理工具

自己维护过服务器的人，多半写过数据库备份脚本：pg_dump 加一行 crontab，每天凌晨落一个文件。脚本好写，难的是后面三件事：昨晚到底跑没跑成、文件是不是完整、真要恢复时能不能导回去。Databasus 把这些活收进了一个网页后台：它是一个用 TypeScript 编写、以 Apache-2.0 许可证开源的自托管数据库备份管理工具，围绕 PostgreSQL 做物理备份、增量备份和时间点恢复（PITR），MySQL、MariaDB、MongoDB 走逻辑备份。公众号「科技君」在 2026 年 9 月 29 日的文章里推荐了它。

核心功能

• 恢复验证：把备份取出来，在临时数据库容器里实际执行一遍恢复，核对结果并给出每张表的行数，完成后清理容器。可以定期跑，也可以配置成每次备份完成后自动触发；备份列表里的 Verified 标记，把“生成了文件”和“验证过能恢复”区分开。
• 物理备份与 PITR：正在写入的数据库不是 Syncthing 能直接同步的普通文件夹，物理备份因此走 PostgreSQL 原生机制做一致性拷贝，增量备份只存变化的数据块，再配合 WAL 日志流把数据推进到当天任意时刻。官方文档写明物理备份要求 PostgreSQL 17 及以上，更低版本退回逻辑备份。
• 定时与保留策略：按小时、天、周、月或 Cron 表达式安排备份；保留策略支持固定时长、固定份数和 GFS 分层（日、周、月各自保留），还能给单份和总存储量设上限。
• 多种存储与加密：本地磁盘、S3 兼容存储、Cloudflare R2、Google Drive、NAS、SFTP 等都可作目的地，备份文件用 AES-256-GCM 加密。
• 失败会说话：通过邮件、Telegram、Slack、Discord、Teams 或 Webhook 主动推送成功与失败，恢复验证可以单独配提醒。
• 团队功能：按工作区隔离项目，viewer / member / admin 角色权限，审计日志记录操作。

支持的数据库引擎（来自官方 README，截至 2026-09-29）：

数据库	备份方式	版本
PostgreSQL	物理 + 逻辑	14–18（物理备份需 17+）
MySQL	仅逻辑	5.7、8.0、8.4、9、26
MariaDB	仅逻辑	5.5–13
MongoDB	仅逻辑	4.2+

典型使用场景

• 手里有两三台 VPS、各自跑着 PostgreSQL 或 MySQL 的独立开发者：把各家 crontab 里风格不一的备份脚本换成同一个有界面的后台，跑没跑、成没成一眼可见。照 独立开发低成本技术栈 把服务搬上自托管 VPS 之后，备份这件事就全归自己管，这个工具正好补上那一环。
• 订单、交易类的 PostgreSQL 业务库：凌晨做全量备份，白天靠 WAL 日志流持续追平，出问题时恢复到误删前的那一刻，而不是只能回到昨晚。
• 备份放 S3 / R2 的团队：文件落盘后自动在临时容器里试恢复，验证报告推到 Slack，不用等出事才发现备份是坏的。

快速上手

准备一台有 Docker 的机器（官方门槛：1 核 CPU、500 MB 内存、5 GB 磁盘），运行：

docker run -d \
  --name databasus \
  -p 4005:4005 \
  -v ./databasus-data:/databasus-data \
  --restart unless-stopped \
  databasus/databasus:latest

打开 http://localhost:4005 注册账号——实例的第一个账号即管理员——再按向导添加数据库、选频率和存储、配保留策略与通知。除 Docker 外还有安装脚本、Docker Compose 和 Helm 三种装法，Docker Hub 限流时可换用 ghcr.io/databasus/databasus。建议先接一个测试库，把“备份 → 验证 → 恢复”整条流程跑通再上生产。

小结

Databasus 适合自托管着几个长期维护的数据库、被“脚本悄悄挂掉”坑过的人；恢复验证让它在“文件在不在”之外多回答了一层“能不能恢复”。项目以 Apache-2.0 许可证开源，用 TypeScript 编写，截至 2026-09-29 在 GitHub 有 8,690 星。三点留意：物理备份与 PITR 要求 PostgreSQL 17 及以上，老版本只有逻辑备份；恢复验证需要额外部署验证代理，并为它准备 Docker、CPU、内存和磁盘；备份加密后务必保管好数据目录里的 secret.key——密钥丢了，备份文件就成了取不回的数据。