Loading... # Databasus 开源数据库备份工具技术分析 # 一、背景与目标 ## 1. 项目背景 ### A. 业务场景 随着云计算和容器化技术的普及，数据库备份管理成为运维工作的核心环节。传统的备份方案存在以下痛点：需要编写复杂的脚本、缺乏统一的可视化管理界面、难以支持多种数据库类型、无法灵活配置存储目标和通知渠道。 ### B. 痛点分析 - **操作复杂**：传统方案依赖命令行工具如 pg_dump、mysqldump，需要编写自动化脚本 - **缺乏监控**：备份任务执行状态难以及时掌握，失败发现滞后 - **存储单一**：难以同时支持本地存储和多种云存储服务 - **协作困难**：团队成员无法共享备份配置和查看备份历史 ## 2. 设计目标 ### A. 功能目标 - 支持 PostgreSQL、MySQL、MariaDB、MongoDB 四种主流数据库 - 提供可视化的 Web 管理界面 - 支持多种存储后端和通知渠道 - 支持定时备份和加密 ### B. 非功能目标 - **安全性**：备份文件 AES-256-GCM 加密，敏感数据不暴露 - **易用性**：提供直观的 UI，支持暗色/亮色主题 - **可靠性**：支持 Docker 容器化部署，自动重启 - **可扩展性**：支持团队协作，工作空间隔离，角色权限管理 # 二、系统架构 ## 1. 整体架构 ```mermaid graph TB subgraph 用户层 U1[管理员] U2[成员] U3[查看者] end subgraph Databasus应用层 W[Web界面] A[API服务] S[调度器] E[加密引擎] end subgraph 数据库连接层 PG[PostgreSQL] MY[MySQL] MR[MariaDB] MO[MongoDB] end subgraph 存储层 L[本地存储] S3[S3兼容存储] GD[Google Drive] FTP[SFTP/FTP] RC[Rclone] end subgraph 通知层 EM[邮件] TG[Telegram] SL[Slack] DC[Discord] WH[Webhook] end U1 --> W U2 --> W U3 --> W W --> A A --> S S --> PG S --> MY S --> MR S --> MO S --> E E --> L E --> S3 E --> GD E --> FTP E --> RC S --> EM S --> TG S --> SL S --> DC S --> WH ```  ## 2. 组件说明 ### A. Web 界面 - 提供 RESTful API 接口 - 支持暗色和亮色主题切换 - 响应式设计，支持移动端访问 ### B. 调度器 - 支持多种调度策略：每小时、每天、每周、每月、Cron 表达式 - 智能压缩：4-8 倍空间节省，约 20% 性能开销 ### C. 加密引擎 - 使用 AES-256-GCM 算法加密备份文件 - 零信任存储：加密后的备份文件即使泄露也无法解密 - 敏感数据加密存储，日志中不暴露 # 三、核心功能 ## 1. 支持的数据库 | 数据库类型 | 支持版本 | |-----------|---------| | PostgreSQL | 12, 13, 14, 15, 16, 17, 18 | | MySQL | 5.7, 8, 9 | | MariaDB | 10, 11 | | MongoDB | 4, 5, 6, 7, 8 | ## 2. 定时备份策略 ```mermaid graph LR A[调度器] --> B{调度类型} B --> C[每小时] B --> D[每天] B --> E[每周] B --> F[每月] B --> G[Cron表达式] C --> H[执行备份] D --> H E --> H F --> H G --> H H --> I[压缩] I --> J[加密] J --> K[存储] K --> L[通知] ```  ## 3. 存储后端支持 - **本地存储**：直接存储在服务器磁盘 - **云存储**：S3、Cloudflare R2、Google Drive、Azure Blob Storage - **网络存储**：NAS、SFTP、FTP - **扩展存储**：通过 Rclone 支持 70+ 种存储服务 ## 4. 通知渠道 - **邮件**：SMTP 协议 - **即时通讯**：Telegram、Slack、Discord - **Webhook**：自定义 HTTP 回调 # 四、安全设计 ## 1. 加密机制 ### A. 备份文件加密 - 算法：AES-256-GCM - 适用场景：所有存储到外部服务的备份文件 - 安全性：即使存储服务被攻破，备份文件也无法解密 ### B. 敏感数据保护 - 数据库凭证加密存储 - 敏感配置不在日志中显示 - 错误信息中不包含敏感数据 ## 2. 访问控制 ### A. 工作空间隔离 - 不同项目/团队使用独立工作空间 - 工作空间间数据隔离 ### B. 角色权限 | 角色 | 权限 | |------|------| | 查看者 | 仅查看备份状态和历史 | | 成员 | 管理数据库和备份任务 | | 管理员 | 管理工作空间内所有资源 | | 所有者 | 完全控制，包括删除工作空间 | ### C. 审计日志 - 记录所有用户操作 - 记录备份任务执行历史 ## 3. 只读用户原则 - Databasus 默认使用只读用户连接数据库 - 不存储任何可以修改数据的凭证 - 备份过程不会对源数据库产生写入操作 # 五、部署方式 ## 1. 部署架构对比 ```mermaid graph LR subgraph Docker部署 D1[Docker Run] D2[Docker Compose] end subgraph K8s部署 K1[ClusterIP] K2[LoadBalancer] K3[Ingress] end D1 --> S[Databasus容器] D2 --> S K1 --> S K2 --> S K3 --> S S --> V[数据卷<br/>./databasus-data] ```  ## 2. 自动化脚本部署（推荐） ```bash sudo apt-get install -y curl && \ sudo curl -sSL https://raw.githubusercontent.com/databasus/databasus/refs/heads/main/install-databasus.sh \ | sudo bash ``` 功能： - 自动安装 Docker 和 Docker Compose - 配置 Databasus 服务 - 设置开机自启动 ## 3. Docker Run 部署 ```bash docker run -d \ --name databasus \ -p 4005:4005 \ -v ./databasus-data:/databasus-data \ --restart unless-stopped \ databasus/databasus:latest ``` ## 4. Docker Compose 部署 ```yaml services: databasus: container_name: databasus image: databasus/databasus:latest ports: - "4005:4005" volumes: - ./databasus-data:/databasus-data restart: unless-stopped ``` ## 5. Kubernetes Helm 部署 ### A. ClusterIP + Port-Forward（开发/测试） ```bash helm install databasus oci://ghcr.io/databasus/charts/databasus \ -n databasus --create-namespace kubectl port-forward svc/databasus-service 4005:4005 -n databasus ``` ### B. LoadBalancer（云环境） ```bash helm install databasus oci://ghcr.io/databasus/charts/databasus \ -n databasus --create-namespace \ --set service.type=LoadBalancer ``` ### C. Ingress（域名访问） ```bash helm install databasus oci://ghcr.io/databasus/charts/databasus \ -n databasus --create-namespace \ --set ingress.enabled=true \ --set ingress.hosts[0].host=backup.example.com ``` # 六、使用流程 ```mermaid graph TD A[访问 Dashboard<br/>http://localhost:4005] --> B[添加数据库] B --> C[配置调度策略] C --> D[设置数据库连接] D --> E[选择存储后端] E --> F{添加通知?} F -->|是| G[配置通知渠道] F -->|否| H[保存并启动] G --> H H --> I[系统验证配置] I --> J{验证成功?} J -->|是| K[开始定时备份] J -->|否| L[修正配置] L --> I K --> M[接收备份通知] ```  # 七、技术特点 ## 1. 从 Postgresus 到 Databasus 项目原名为 Postgresus，专注于 PostgreSQL 备份。2025 年 12 月更名为 Databasus，主要原因是： - **功能扩展**：从单一 PostgreSQL 支持扩展到 MySQL、MariaDB、MongoDB - **品牌定位**：从简单的 pg_dump UI 包装工具成长为成熟的备份管理系统 - **商标合规**：PostgreSQL 是 PostgreSQL Inc. 的注册商标 ## 2. 云数据库与自托管数据库支持 ### A. 支持的云数据库 - AWS RDS - Google Cloud SQL - Azure Database ### B. 不支持 PITR 的原因 云提供商已提供原生的 PITR（时间点恢复）功能，外部 PITR 备份无法恢复到托管的云数据库，因此对云托管 PostgreSQL 来说不实用。 ### C. 实用的备份粒度 每小时和每日备份对 99% 的项目已足够，无需 WAL 归档的操作复杂性。 ## 3. AI 辅助开发策略 ### A. AI 用于 - 代码质量验证和漏洞搜索 - 文档、注释和代码清理改进 - 开发过程中的辅助 - 人工审查后的 PR 和提交双重检查 ### B. AI 不用于 - 编写整个代码 - 随意编写代码 - 未经人工逐行验证的代码 - 没有测试的代码 ### C. 质量保证 - 完善的测试覆盖率（单元测试和集成测试） - CI/CD 流水线自动化 - 经验丰富的开发者验证 # 八、对比分析 ## 1. 与传统备份方案对比 | 特性 | Databasus | 传统脚本方案 | |------|-----------|-------------| | 部署复杂度 | 低（Docker 一键部署） | 高（需编写和维护脚本） | | 可视化管理 | 支持 | 不支持 | | 多数据库支持 | 支持 | 需分别配置 | | 存储后端 | 多种 | 通常单一 | | 通知渠道 | 多种 | 需自行实现 | | 加密支持 | 内置 AES-256-GCM | 需自行实现 | | 团队协作 | 支持 | 不支持 | ## 2. 与云备份服务对比 | 特性 | Databasus | 云备份服务 | |------|-----------|-----------| | 数据主权 | 完全控制 | 托管给云服务商 | | 成本 | 一次性部署成本 | 按量计费 | | 定制性 | 高（开源可修改） | 低 | | 混合云支持 | 支持 | 通常受限 | # 九、适用场景 ## 1. 推荐使用场景 - **中小企业**：缺乏专业 DBA 团队，需要简单可靠的备份方案 - **DevOps 团队**：需要可视化的备份管理界面 - **多数据库环境**：同时使用 PostgreSQL、MySQL、MongoDB - **混合云部署**：数据库分布在本地和云端 - **合规要求高**：需要数据加密和审计日志 ## 2. 不适用场景 - **需要 PITR 的 PostgreSQL**：云数据库已有原生 PITR - **超大规模部署**：单一实例可能有性能瓶颈 - **特殊数据库**：不支持除四种外的其他数据库 # 十、总结 Databasus 是一个设计精良的开源数据库备份管理工具，通过 Docker 容器化部署和友好的 Web 界面，大大降低了数据库备份管理的门槛。其核心优势在于： 1. **多数据库支持**：覆盖 PostgreSQL、MySQL、MariaDB、MongoDB 四种主流数据库 2. **安全可靠**：AES-256-GCM 加密、零信任存储、只读用户原则 3. **易于部署**：支持自动化脚本、Docker、Kubernetes 多种部署方式 4. **团队协作**：工作空间隔离、角色权限、审计日志 5. **灵活通知**：邮件、Telegram、Slack、Discord、Webhook 多渠道 对于需要统一管理多种数据库备份的团队，Databasus 是一个值得考虑的自托管解决方案。 *** ## 参考资料 1. [Databasus GitHub Repository](https://github.com/databasus/databasus) 最后修改：2026 年 01 月 15 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏