Databasus: backup PostgreSQL, MySQL, MongoDB tự động, self-hosted và dễ cấu hình

Tóm tắt nhanh (Key Takeaways)

Databasus là một công cụ backup cơ sở dữ liệu mã nguồn mở, self-hosted, hỗ trợ PostgreSQL, MySQL/MariaDB và MongoDB, cho phép bạn lên lịch backup tự động và đẩy bản sao lưu lên nhiều loại storage như S3, Cloudflare R2, Google Drive, Azure Blob, NAS, FTP/SFTP… chỉ với vài lệnh Docker.

Bạn triển khai Databasus trên chính hạ tầng của mình (VPS, server tại chỗ, Kubernetes…), quản lý nhiều database trong một web UI, nhận thông báo qua Slack, Discord, Telegram, email, MS Teams hoặc webhook mỗi khi backup thành công/thất bại, và vẫn giữ toàn quyền kiểm soát dữ liệu của doanh nghiệp.

Bài viết này sẽ hướng dẫn chi tiết cách cài đặt Databasus bằng script, Docker run, Docker Compose, Helm, Docker + Caddy reverse proxy, cũng như cách cấu hình job backup, storage và notification để bạn có một hệ thống backup database “chạy êm” trong 5–10 phút.

Databasus là gì và giải quyết vấn đề nào?

Databasus là một công cụ backup cơ sở dữ liệu miễn phí, mã nguồn mở và self-hosted, tập trung vào việc tự động hoá backup theo lịch, lưu trữ bản sao lưu ở nhiều đích khác nhau và gửi thông báo chi tiết về trạng thái backup. Công cụ này hỗ trợ PostgreSQL, MySQL, MariaDB và MongoDB, nên bạn có thể dùng một hệ thống thống nhất cho toàn bộ stack thay vì phải ghép nhiều script rời rạc.

Về bản chất, Databasus là hậu duệ và bản mở rộng của dự án Postgresus, được đổi tên sau khi có vấn đề về trade‑mark, đồng thời bổ sung full support cho MySQL và MongoDB. Thay vì phụ thuộc vào backup “mặc định” của từng nhà cung cấp cloud, bạn chủ động định nghĩa lịch backup, lưu bản sao ở local + cloud của riêng mình và giám sát trung tâm qua web UI.

Những tính năng nổi bật của Databasus

Databasus được thiết kế để “set up một lần, quên nó đi” nhưng vẫn có khả năng kiểm soát chi tiết khi bạn cần.

Hỗ trợ đa hệ quản trị CSDL: Databasus backup PostgreSQL, MySQL, MariaDB và MongoDB, phù hợp cho cả monolith lẫn microservices có nhiều loại database khác nhau. Bạn có thể cấu hình nhiều database từ nhiều host (on‑premise, cloud, managed service) trong cùng một giao diện.
Backup theo lịch, cho nhiều DB cùng lúc: Bạn tạo các “backup jobs” với lịch tuỳ chỉnh (theo giờ/ngày/tuần), mỗi job có thể chạy trên một hoặc nhiều database. Điều này giúp gom lịch backup của cả staging và production vào một chỗ để dễ theo dõi và chuẩn hoá quy trình DR (disaster recovery).
Nhiều loại storage backend: Databasus lưu bản sao lưu lên local disk, S3 và S3‑compatible (Cloudflare R2), Google Drive, Azure Blob, NAS, FTP/SFTP và các đích khác thông qua rclone, giúp bạn dễ dàng xây chiến lược 3‑2‑1 (3 bản sao, 2 loại storage, 1 offsite).
Notifications đa kênh: Mỗi job có thể gửi thông báo thành công/thất bại qua email, Telegram, Slack, Discord, Microsoft Teams hoặc webhook tuỳ chỉnh, giúp DevOps/SRE nắm tình trạng backup kịp thời. Điều này đặc biệt hữu ích khi bạn tự host database và không có dashboard backup nào khác đi kèm.
Tập trung vào bảo mật và toàn vẹn dữ liệu: Databasus sử dụng kết nối read‑only tới database, hỗ trợ mã hoá AES‑256‑GCM cho file backup và secrets, cùng khả năng xoay vòng access key và audit log cho thao tác nhạy cảm. Bản thân file backup vẫn có thể được khôi phục mà không cần chạy Databasus, giúp bạn không bị “lock‑in” vào chính công cụ backup.

Kiến trúc self-hosted và lý do nên dùng Databasus

Databasus chạy như một dịch vụ web self‑hosted: bạn deploy nó trên VPS, bare-metal server hoặc cluster Kubernetes của mình, sau đó truy cập qua trình duyệt tại http://localhost:4005 hoặc domain riêng. Việc backup được thực thi bằng cách gọi các công cụ dòng lệnh chuẩn (như pg_dump, mysqldump, mongodump) phía sau, rồi đẩy file lên storage mà bạn cấu hình.

Cách tiếp cận này mang lại nhiều lợi ích:

Bạn giữ toàn bộ dữ liệu và secrets trên hạ tầng của mình, không gửi vào một SaaS backup bên thứ ba.
Hỗ trợ đa cloud và multi‑region dễ dàng: chỉ cần cấu hình thêm storage backend là xong.
Dễ tích hợp vào pipeline DevOps/Infra‑as‑Code hiện có (Docker, Docker Compose, Helm, Caddy).

Yêu cầu hệ thống trước khi cài đặt

Theo tài liệu chính thức, Databasus cần tối thiểu:

CPU: 1 core
RAM: khoảng 500 MB
Disk: tối thiểu 5 GB cho bản thân ứng dụng, cộng thêm dung lượng cho các bản backup (tuỳ chiến lược lưu trữ)
Docker Engine ≥ 20.10 và Docker Compose v2+ nếu dùng Docker hoặc script cài đặt tự động.

Bạn có thể cài trên mọi distro Linux phổ biến (Ubuntu, Debian, v.v.), cũng như triển khai trên Kubernetes cluster (on‑prem hoặc cloud) thông qua Helm chart.

Các cách cài đặt Databasus phổ biến

Databasus hỗ trợ nhiều phương thức triển khai, trong đó script tự động và Docker Compose là nhanh nhất cho self‑hosted trên VPS đơn.

Cài đặt bằng script tự động (Linux, khuyến nghị)

Script này sẽ kiểm tra và cài Docker + Docker Compose nếu chưa có, sau đó setup Databasus như một dịch vụ tự khởi động lại khi reboot.

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

Theo tài liệu, Databasus sẽ được cài vào thư mục /opt/databasus với cấu hình Docker Compose kèm sẵn. Sau khi script chạy xong, bạn có thể truy cập giao diện tại http://localhost:4005 (hoặc http://IP-SERVER:4005 nếu truy cập từ máy khác).

Chạy nhanh bằng lệnh `docker run`

Nếu bạn muốn kiểm thử nhanh trên máy dev hoặc server sandbox, có thể dùng một lệnh Docker duy nhất:

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

Lệnh này sẽ chạy container Databasus, mount volume ./databasus-data để lưu cấu hình/metadata, expose port 4005 và cấu hình tự khởi động lại. Bạn chỉ cần bảo đảm thư mục ./databasus-data có quyền ghi phù hợp cho user Docker.

Dùng Docker Compose

Đối với môi trường production nhỏ hoặc muốn quản lý nhiều service hơn sau này, Docker Compose là lựa chọn sạch sẽ:

services:
  databasus:
    container_name: databasus
    image: databasus/databasus:latest
    ports:
      - "4005:4005"
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped

Sau đó chạy:

docker compose up -d

Lưu ý khởi động có thể mất tới khoảng 2 phút, tuỳ cấu hình máy. Nếu port 4005 đã dùng, bạn chỉ cần đổi phần trước dấu hai chấm, ví dụ "8080:4005" để phục vụ trên port 8080 bên ngoài.

Triển khai trên Kubernetes với Helm

Nếu bạn vận hành cluster Kubernetes, Databasus cung cấp Helm chart trên OCI registry ghcr.io/databasus/charts/databasus.

Dev/test (ClusterIP + port‑forward):

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

kubectl port-forward svc/databasus-service 4005:4005 -n databasus
# Truy cập tại http://localhost:4005

Cloud (LoadBalancer):

helm install databasus oci://ghcr.io/databasus/charts/databasus \
  -n databasus --create-namespace \
  --set service.type=LoadBalancer

Domain riêng (Ingress):

helm install databasus oci://ghcr.io/databasus/charts/databasus \
  -n databasus --create-namespace \
  --set ingress.enabled=true \
  --set ingress.hosts[0].host=backup.vnrom.net

Tuỳ môi trường (bare‑metal, cloud, Gateway API), bạn có thể tinh chỉnh thêm NodePort, TLS, HTTPRoute… trong giá trị Helm chart.

Docker Compose kết hợp Caddy (HTTPS tự động)

Đây là pattern đẹp cho production: Caddy làm reverse proxy + TLS, Databasus chạy phía sau không expose port ra ngoài.

File docker-compose.yml:

services:
  databasus:
    container_name: databasus
    image: databasus/databasus:latest
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped

  caddy:
    container_name: caddy
    # cấu hình image, volumes, ports cho Caddy...

File Caddyfile cùng thư mục:

backup.vnrom.net {
  reverse_proxy databasus:4005
}

Sau đó chạy:

docker compose up -d

Caddy sẽ lo tự xin chứng chỉ Let’s Encrypt, redirect HTTP → HTTPS và reverse proxy traffic tới Databasus. Bạn chỉ cần trỏ DNS domain backup.example.com về IP server trước khi khởi động stack.

Hướng dẫn cấu hình Databasus sau khi cài

Khi triển khai xong, bạn truy cập http://localhost:4005 (hoặc domain/port tương ứng) để vào web UI. Luồng cấu hình cơ bản gồm ba phần: storage, database, và backup job.

Thêm storage backend (S3, R2, Google Drive, NAS…)

Trong phần Storage (tuỳ UI cụ thể), bạn có thể tạo một hoặc nhiều “destination”:

S3/S3‑compatible: AWS S3, Cloudflare R2, MinIO, Wasabi… với access key/secret và bucket name.news.
Google Drive: dùng OAuth/token để cho phép Databasus lưu backup archive vào một folder cụ thể.
Azure Blob, FTP/SFTP, NAS hoặc backend hỗ trợ rclone: phù hợp cho offsite backup nội bộ hoặc hạ tầng tại chỗ.

Mỗi storage có thể được gán cho nhiều job, giúp bạn dễ dàng thực hiện chiến lược lưu trữ đa tầng (local + cloud).

Thêm database cần backup

Tiếp theo, bạn định nghĩa nguồn dữ liệu:

PostgreSQL (bao gồm cả managed như RDS, Cloud SQL, Supabase…)
MySQL/MariaDB (tự host hoặc cloud như RDS, Aurora, v.v.)
MongoDB (self‑host, Atlas hoặc dịch vụ tương đương).

Bạn khai báo host, port, database name, user/password (hoặc DSN), và nên dùng role read‑only được cấp quyền backup để tăng an toàn. Databasus sẽ dùng công cụ dòng lệnh tương ứng (vd. mongodump cho MongoDB) để tạo bản sao lưu chuẩn, nên sau này có thể restore trực tiếp bằng tool nguyên thuỷ nếu cần.

Tạo backup job và lịch chạy

Một backup job thường bao gồm:

Danh sách database nguồn
Storage đích (có thể một hoặc nhiều)
Lịch chạy: mỗi X phút/giờ/ngày, hoặc CRON nâng cao (tuỳ UI)
Chính sách retention: giữ lại N bản gần nhất, xoá bản cũ tự động (nếu tính năng này được bật trong cài đặt cụ thể).

Sau khi lưu job, Databasus sẽ chạy theo lịch; bạn cũng có thể trigger run thủ công để test ngay lập tức.

Cấu hình notifications

Cuối cùng, bạn thêm các kênh thông báo trong phần Notifications:

Slack/Discord/MS Teams: dùng webhook URL để nhận thông báo trong kênh DevOps.
Telegram: cấu hình bot token và chat ID để gửi message khi backup thành công/thất bại.
Email: dùng SMTP server nội bộ hoặc dịch vụ bên ngoài để gửi báo cáo định kỳ.
Webhook tuỳ chỉnh: gửi JSON payload về hệ thống monitoring riêng (Grafana, custom dashboard…).

Việc nhận thông báo sớm giúp bạn phát hiện nhanh các lỗi như hết dung lượng, credential sai, network timeout…, tránh tình trạng “nghĩ là có backup” nhưng đến lúc cần lại không có gì để restore.

Bảo mật, mã hoá và best practice khi dùng Databasus

Từ góc độ security, Databasus đưa ra một số nguyên tắc tốt:

Kết nối database dưới quyền read‑only, chỉ cần đủ quyền để thực hiện dump, hạn chế tối đa rủi ro ghi nhầm dữ liệu production.
Mã hoá bí mật và file backup bằng AES‑256‑GCM, chuẩn mã hoá mạnh trong môi trường enterprise.
File backup được tạo theo định dạng chuẩn (vd. output từ pg_dump, mysqldump, mongodump), có thể phục hồi ngay cả khi không còn chạy Databasus.

Một số best practice nên áp dụng:

Luôn test quy trình restore định kỳ, không chỉ dừng ở việc “backup thành công”.
Kết hợp storage local + offsite (S3/R2/Drive) để giảm rủi ro mất dữ liệu khi server bị sự cố.
Giới hạn quyền truy cập web UI của Databasus (VPN, firewall, auth reverse proxy) nếu deploy trên internet.

Một vài kịch bản sử dụng Databasus thực tế

Databasus phù hợp với nhiều tình huống DevOps/SRE khác nhau:

Startup tự host database trên VPS: bạn dùng một instance PostgreSQL + một instance MongoDB cho app; Databasus giúp gom backup của cả hai vào cùng một dashboard, đẩy lên S3/R2, gửi cảnh báo về Slack khi có lỗi.
Multi‑tenant SaaS: mỗi khách hàng là một database riêng (PostgreSQL hoặc MySQL); bạn tạo job backup chạy theo từng nhóm tenant, lưu trữ riêng biệt trên storage khác nhau nếu cần.
Môi trường staging/QA: backup staging định kỳ để phân tích dữ liệu test, hoặc clone qua môi trường khác mà không cần script backup tự viết.

Với DevOps hiện đại, việc có một công cụ backup DB trung lập, open‑source, không phụ thuộc vendor là một “mảnh ghép” quan trọng trong chiến lược an toàn dữ liệu.

Nếu bạn đang tìm một giải pháp backup database đơn giản, rõ ràng, không khoá vào một nhà cung cấp cloud, Databasus là lựa chọn rất đáng thử: triển khai nhanh với Docker/Helm, quản lý qua web UI nhẹ, và đủ linh hoạt để phục vụ từ side‑project tới production của startup hoặc SME.

Duy Nghiện

Hãy làm khán giả, đừng làm nhân vật chính :)