備份這件事，多數團隊都是「做了但不確定能不能還原」的狀態。備份腳本每天跑，S3 bucket 裡堆滿了 dump 檔，直到真的出事那一天才發現壓縮檔壞了、還原指令跑不動、或是 WAL 缺了一段。Databasus 就是為了逼你把這件事驗證清楚而寫的工具，前身叫 Postgresus，在 2025 年 12 月改名之後路線變得比過去更廣。
到 2026 年 6 月，Docker Hub 上的 Databasus 映像檔累計下載超過一百萬次，v3.47.1 補齊了 PostgreSQL 18 的實體備份支援，同時把 MySQL、MariaDB、MongoDB 一併納入管理。對只想要一套面板管所有資料庫備份的中小團隊來說，它現在的定位比一年前清楚很多。
Postgresus 為什麼要改名
改名的直接原因是商標。PostgreSQL Inc. 對「Postgres」的使用一直有規範，任何專案名稱只要包含這個字串，都會被要求說明用途或直接改名。Postgresus 從一個看起來像 PostgreSQL 附屬工具的專案，走到累積十幾萬使用者的階段，已經不適合再用擦邊球的方式維持下去。
另一個原因是產品定位變了。Postgresus 剛推出時是純 PostgreSQL 工具，用 Web UI 包裝 pg_dump 和 pg_basebackup，把調度、通知、加密統一處理。用戶開始要求「同一台伺服器上的 MySQL 也希望能一起管」之後，繼續掛著 Postgres 的名字就變成負擔。改名 Databasus 之後，MongoDB 和 MariaDB 陸續進入支援列表，2026 年的路線圖還提到 SQLite 和 ClickHouse。
這種「一套 UI 管多個資料庫」的做法，在 SaaS 世界早就是常態，但自架選項一直不多。過去要嘛用資料庫自帶的工具 + 排程腳本，要嘛買 Rubrik、Veeam 這種企業級軟體，中間地帶幾乎沒有東西。Databasus 卡進的就是這個空缺。
邏輯備份、實體備份、WAL 串流的三條路線
Databasus 對每種資料庫都提供邏輯備份，這是最基本的功能。它跑一個 pg_dump、mysqldump 或 mongodump，把結果壓縮加密送到指定的儲存後端。這條路線的優點是跨版本相容性最好，適合搬家、跨主機遷移、或是週期性冷備份。缺點是資料量大之後備份時間拉長，而且復原時要重放所有資料，還原時間隨資料量線性成長。
PostgreSQL 則多出兩條路線。實體備份走 pg_basebackup，直接把 data directory 的檔案複製走，還原速度快、備份時間也比邏輯備份短。從 PostgreSQL 17 開始，pg_basebackup 支援原生的區塊層級增量備份，只複製上次備份後改動的區塊，Databasus 把這個機制包起來，讓每天的增量備份只需要處理實際變動的資料。
WAL 串流則是為了 Point-in-Time Recovery。Databasus 會持續接收 primary 傳來的 WAL 檔案，任何一個時間點的狀態都能被還原。這對交易頻繁的資料庫特別重要——當有人不小心跑了一個沒加 WHERE 的 UPDATE，PITR 讓資料能倒回那筆錯誤指令發生前一秒，而不是回到昨天的全備份。
實務上這三條路線該怎麼組合？對純交易型的 PostgreSQL，建議直接開實體備份加 WAL 串流，一週跑一次完整實體備份、每日跑增量、WAL 持續串流。邏輯備份可以每週跑一次留著作跨版本相容的保險。MySQL 或 MongoDB 目前只有邏輯備份，就照資料量決定頻率，資料量小可以每小時一次，資料量大就每晚一次配合白天的 binlog 或 oplog 保留。
復原驗證這件事，多數人的備份都沒做
Databasus 最值得留意的功能不是備份本身，而是自動復原驗證。設定開啟之後，它會定期把備份檔拉回來，在隔離的 Docker container 裡跑一次還原，然後檢查資料表數量和行數是否符合預期。整個流程結束後 container 被銷毀，只留下驗證結果的紀錄。
這件事聽起來理所當然，但實際上多數團隊的備份策略停留在「檢查檔案 checksum 是否正常」的程度。checksum 只能證明檔案沒有損毀，不能證明還原流程走得通。真正的還原可能會撞上很多問題——資料庫版本不相容、缺少 extension、user 權限沒帶到、WAL 檔案有缺口——這些都要實際跑一次還原才會浮現。
自動化復原驗證的代價是 CPU 和儲存空間，尤其資料量大的時候。Databasus 允許在 configuration 裡指定驗證頻率、目標資料庫的取樣範圍、以及使用的 container 資源限制。實務建議是主要資料庫每週驗證一次完整備份，次要資料庫每月一次，配合 Slack 或 Telegram 的通知確保驗證失敗時能立刻知道。
儲存後端與部署方式的實務規劃
Databasus 支援的儲存後端相當齊全：S3、Cloudflare R2、Google Drive、Dropbox、SFTP、rclone、以及本地磁碟。選擇的重點不是列表有多長，而是符不符合 3-2-1 備份原則——三份副本、兩種不同媒體、一份異地。
實務上常見的組合是本地磁碟加上 S3 相容儲存。本地磁碟用於快速復原，S3 用於異地備援。R2 相對於 S3 的優勢在於沒有出站流量費用，還原大量資料時能省下可觀成本。SFTP 適合已經有 NAS 或第二台備援伺服器的場景，rclone 則是萬用轉接頭，理論上能接進任何雲端硬碟服務。
部署方式最常見的是 Docker Compose：一個 container 跑 Databasus 本體，透過 Docker network 或直接透過網路連線去各個資料庫執行備份。它需要在資料庫端建立一個唯讀 user 加上必要的 backup 相關權限，而不是用 superuser。Kubernetes 用戶可以直接用 Helm chart，適合已經有 GitOps 流程的團隊。
一台 2GB RAM 的 VPS 就能跑得動 Databasus 本體，實際負擔取決於管理的資料庫數量和備份頻率。有一點要注意：Databasus 不應該和它管理的資料庫跑在同一台機器上。備份工具的重點就是隔離，把它跟資料庫綁在一起等於自我否定備份的價值。
什麼時候不該選 Databasus
Databasus 適合中小規模的多資料庫環境，但它不是萬能。有幾種情境比較適合用其他工具。
超大規模的 PostgreSQL 部署，pgBackRest 仍然是更成熟的選擇。它的並行備份、差異備份、加密壓縮、跨版本 rewind、以及對 TB 等級資料的處理都經過多年生產環境驗證。Databasus 對這些場景還在追趕。
只需要單一 PostgreSQL 的極簡自架環境，直接用 cron 呼叫 pg_dump 加 restic 送到 S3 也許就夠了。Databasus 的 Web UI 和多資料庫抽象化在這種情境下反而是負擔，維運多一層要顧的東西。
需要邏輯 replication、cross-region 熱備援、或是零停機的資料庫升級，這些屬於 HA 和 DR 的範疇，備份工具本來就不是設計來解決這類問題。這時候該看的是 Patroni、pg_auto_failover 或是雲端資料庫的原生功能。
結論
Databasus 把過去分散在 shell 腳本、cron、S3 CLI、以及各種手工組合的備份流程，整合成一個可以在瀏覽器裡管理的介面。它最有價值的貢獻不是備份本身，而是把「復原驗證」這件事變成預設行為。改名後的多資料庫支援也讓它從 PostgreSQL 專用工具轉向更廣泛的自架資料庫管理場景。
備份策略要跑得穩，前提是有一台獨立、穩定、能夠 24 小時運作的機器來執行它。NCSE Network 的臺灣 VPS 服務提供 Intel Gold CPU 與 NVMe SSD，位於是方電訊機房，適合作為 Databasus 這類備份控制節點，或是異地備援伺服器的落腳點。搭配 IP Transit 連線品質，能有效縮短跨地點還原時的傳輸時間。想了解更多可以看看 NCSE Network 的服務介紹。
