Databasement完全解説：MySQL/PostgreSQL/MongoDBを一括管理するセルフホスト型バックアップOSS

「本番DBのバックアップ、ちゃんと取れていますか？」と聞かれて即答できるチームは意外と少ない。MySQL・PostgreSQL・MongoDBなど複数エンジンが混在する現場ではcronとシェルスクリプトが乱立し、誰がどのDBをいつバックアップしているか把握できないまま運用が続いてしまう。Databasementはそんな散らばったバックアップ運用を単一のWebUIに集約するセルフホスト型OSSだ。MIT・PHP（Laravel）製で、Docker1コマンドで起動し、SSHトンネル経由のプライベート接続、AES-256暗号化、S3/SFTP保存、MCPサーバー経由のAI連携まで網羅する。

この記事ではセルフホスト型のDBバックアップ管理OSS Databasementを解説します。AI時代の自動化ツール全体像についてはAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方をご覧ください。

Databasementとは何か：散らばるバックアップを1画面に集約するOSS

DatabasementはDavid-Crty氏が公開しているセルフホスト型データベースバックアップ管理アプリケーションだ。2026年4月時点で★379、最新版は4月29日リリースのv1.1.4、PHP（81%）+ Laravelで実装されている。「DB管理者がやることを全部1つの画面に詰め込んだダッシュボード」と表現するのが近い。

従来のバックアップ運用は次の問題を抱えていた。

• スクリプトが各サーバーに分散：MySQLのcronはAサーバー、PostgreSQLはBサーバー、Mongoはまた別…と散らかる
• 失敗通知がない／届かない：ログを見に行くまで気づかず、復旧時にバックアップが壊れていることが発覚
• リストア手順が属人化：バックアップは取れているがリストア訓練がされず、いざという時に動かない
• SaaSは情報セキュリティの壁：BackupBuddyやSimpleBackupsなどのSaaSはコンプライアンス要件で使えない現場が多い

Databasementはこれらを単一のDocker コンテナに収めることで解決する。WebUIから接続情報を登録し、スケジュールを設定すれば、後はキューワーカーが自動で取得・圧縮・暗号化・転送・通知まで行う。

対応データベースとストレージ：6エンジン × 4ストレージのマトリクス

Databasementの強みは「対応の幅広さ」にある。1つのインスタンスでリレーショナル・ドキュメント・KVS・組み込み型まで横断管理できる。

対応データベース

対応ストレージ（保存先）

S3互換が広く使えるため、コスト最適化のためBackblaze B2やCloudflare R2へ逃がす運用がしやすい。「本番MySQLは毎日Backblaze B2、月次はAWS S3 Glacier」のような階層運用もWebUIだけで設計できる。

アーキテクチャ：シングルコンテナで完結する設計

Databasementは「バックアップ取得→圧縮→暗号化→転送→通知」までを内部のキュー処理で完結させる。Laravel Horizon相当のキューワーカーがENABLE_QUEUE_WORKER=trueで同居起動し、外部のRedisやSidekiqを別途用意する必要がない。

このシンプルさはコンテナ運用と相性が良い。LogBullのようにSQLiteで状態を持つアプローチを採用しているため、外部DBレスでも動作する。永続化が必要なデータは/dataボリューム1つに集約され、可搬性が高い。ログ収集の自前運用についてはLog Bull徹底解説：Docker一発で立つOSSログ収集システム、ELK/Lokiの軽量代替も併せて参照したい。

クイックスタート：Dockerで2分で起動

公式が提示している最短手順は次の通り。SQLiteを使い、ボリュームをカレントディレクトリのdatabasement-dataに置く構成だ。

docker run -d \
  --name databasement \
  -p 2226:2226 \
  -e DB_CONNECTION=sqlite \
  -e DB_DATABASE=/data/database.sqlite \
  -e ENABLE_QUEUE_WORKER=true \
  -v ./databasement-data:/data \
  davidcrty/databasement:1

起動後はhttp://localhost:2226にアクセスし、初期管理者アカウントを作成する。ENABLE_QUEUE_WORKER=trueはワーカーをコンテナ内で同時起動するフラグで、これを忘れるとUIから「キューにジョブを入れたまま実行されない」状態になる。

docker-composeでの本番構成例

PostgreSQLを永続化バックエンドにし、別ホストのMySQLをバックアップ対象にする想定で書くと次のようになる。

services:
  databasement:
    image: davidcrty/databasement:1
    container_name: databasement
    restart: unless-stopped
    ports:
      - "2226:2226"
    environment:
      DB_CONNECTION: pgsql
      DB_HOST: db
      DB_PORT: 5432
      DB_DATABASE: databasement
      DB_USERNAME: databasement
      DB_PASSWORD: ${DB_PASSWORD}
      ENABLE_QUEUE_WORKER: "true"
      APP_KEY: ${APP_KEY}
      APP_URL: https://backup.example.com
    volumes:
      - ./data:/data
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: databasement
      POSTGRES_USER: databasement
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./pgdata:/var/lib/postgresql/data

APP_KEYはphp artisan key:generate --show相当で生成した32バイトのbase64文字列が必要だ。コンテナ内で一度docker execして取得するか、Laravelで使える既存のキー生成手段で発行しておく。

Kubernetesへのデプロイ

公式リポジトリ配下にcharts/としてHelmチャートが提供されている。永続ボリューム・Ingress・サブパス配信に対応しており、社内基盤での標準デプロイに向く。

helm repo add databasement https://david-crty.github.io/databasement-helm
helm install backup databasement/databasement \
  --set ingress.enabled=true \
  --set ingress.hosts[0].host=backup.example.com \
  --set persistence.size=50Gi

スケジュールと保持ポリシー：GFSで世代管理する

Databasementの真価はスケジューリングにある。WebUIで対象DBを選び、cron式で取得頻度を、リテンションで保持期間を指定するだけで世代管理が始まる。

サポートされる保持戦略

GFS（Grandfather-Father-Son）は古典的な世代管理戦略で、「日次7世代＋週次4世代＋月次12世代」のように複数粒度で残す。Databasementはこれを設定UIから直接定義でき、ストレージコストと復旧粒度のバランスが取りやすい。

スケジュール例

# 毎日午前3:00に実行（タイムゾーンはApp設定に従う）
0 3 * * *

# 平日のみ午前2:00
0 2 * * 1-5

# 1時間ごと
0 * * * *

cron欄は秒単位ではなく一般的な5フィールド形式。タイムゾーンはコンテナのTZ環境変数あるいはアプリ設定で統一される。

SSHトンネル接続とセキュリティ機能

本番DBはVPCやプライベートサブネットの内側にあり、外部から直接接続できない構成が一般的だ。DatabasementはSSHトンネルをネイティブサポートし、踏み台サーバー越しに対象DBへ到達できる。

設定項目は以下のとおり。

• 踏み台ホスト名／ポート
• 踏み台ユーザー名
• 認証方法：パスワード or SSH鍵（コピペ貼り付け）
• 内部DBのホスト：localhostやdb-internal.svc.cluster.localなど、踏み台から見たアドレス

これにより「踏み台に手動でSSH→ダンプ→S3にアップ」というオペレーションを完全に自動化できる。

暗号化と認証

データ越しの暗号化が前提になっているため、S3バケット側のSSE-KMSと組み合わせれば二重暗号化になる。コンプライアンス監査時に「鍵管理は誰の責任か」を明確に説明できる構成だ。

REST APIとMCPサーバー：CIとAIから操作する

Databasementは「人がブラウザで操作する」だけのツールではない。REST APIに加え、Model Context Protocol（MCP）サーバーを公式で同梱している。これがインフラOSSとしてはかなり先進的な点だ。

REST APIの典型的な使い方

CI/CDから手動バックアップを差し込みたいケースを考える。たとえばマイグレーション直前にスナップショットを残しておくユースケースだ。

# トリガーのみ。実行はキュー任せ
curl -X POST "https://backup.example.com/api/v1/jobs/123/run" \
  -H "Authorization: Bearer ${DBM_TOKEN}" \
  -H "Content-Type: application/json"

# 完了状況をポーリング
curl -X GET "https://backup.example.com/api/v1/jobs/123/runs/latest" \
  -H "Authorization: Bearer ${DBM_TOKEN}"

GitHub Actionsからこれを叩けば、リリースワークフローに「バックアップ完了を待ってからマイグレーションを流す」フェーズを組み込める。

MCPサーバーでClaude Code／Cursorから操作

Databasement v1.1系からはMCPサーバーが組み込まれており、Claude CodeやCursorのMCP設定から接続するだけでAIエージェントから操作できる。

{
  "mcpServers": {
    "databasement": {
      "command": "npx",
      "args": ["@databasement/mcp", "--url", "https://backup.example.com", "--token", "${DBM_TOKEN}"]
    }
  }
}

これを設定しておくとClaude Codeに「本番MySQLのバックアップを今すぐ取って、終わったらSlackに通知」と話しかけるだけで、ジョブの実行・状態監視・通知設定変更まで自然言語で完結する。日々のSREオペレーションが対話で進められるようになるのは、2026年のAI×インフラ運用の象徴的な体験だ。

通知チャンネルと監視：失敗したらすぐ気づく仕組み

バックアップ運用最大の落とし穴は「失敗したのに気づかないこと」だ。Databasementは7つの通知チャンネルを内蔵しており、組織のコミュニケーション基盤に合わせて選択できる。

通知ルールは「失敗時のみ」「成功時も含む」「2回連続失敗時」のように粒度を変えられる。ノイズになりすぎず、本当に必要なときだけページングする運用が実現しやすい。

リアルタイム監視ダッシュボードはジョブごとの実行履歴・所要時間・転送サイズをグラフ化する。トレンドが見えるので「最近MongoDBのダンプが30%重くなった」のような兆候を早期に拾える。

類似ツールとの比較：BackupNinja・SimpleBackups・PgBackRestと何が違うか

DBバックアップOSSは古くから存在するが、Databasementは「マルチエンジン×WebUI×MCP対応」が同居する点で独自性がある。

「PostgreSQLしか使わないし、PITRが欲しい」ならPgBackRestが王道だ。一方で現場のDB構成が混在していて、人と機械の両方から扱える管理面が欲しいならDatabasementが最も近い選択肢になる。

想定ユースケースと導入時の注意点

向いているシーン

• 個人開発・スモールチームのSaaS運用：MySQLとMongoが混在し、cronスクリプトを書く時間がない
• 社内ツール・kintoneを置き換えたNoCodeアプリ群：複数のSQLite／PostgreSQLが同居し、誰がどれを管理するか曖昧になりがち
• 規制業界のオンプレ運用：データが外部SaaSに出ない要件があるが、UIなしのcronはレビューが厳しい
• AI時代のSRE実験場：MCP経由でClaude CodeやCursorから操作できる「AI-Operableなインフラ」を試したいチーム

注意すべきポイント

• 増分バックアップ非対応：論理ダンプベースのため、TB級のDBは取得時間が課題になる。100GBを超えるならPgBackRestやXtraBackupとの併用を検討する
• Laravel製の本体DB：内部状態用にSQLiteかPostgreSQLが必要。SQLiteは検証用、本番運用ではPGを別建てするのが安全
• APP_KEY漏洩は致命的：Laravelの暗号化キーが漏れるとバックアップ取得設定の認証情報が復号される恐れがある。SecretManagerなどで管理する
• SSH鍵の管理：踏み台用のSSH秘密鍵をUI入力するため、ロール権限とアクセスログを必ず監査する

インフラコスト最適化の観点では、Infracost活用ガイド：Terraformのクラウドコストをデプロイ前に可視化するOSSツール完全解説と組み合わせて、バックアップストレージのコスト試算をTerraformレベルで管理するのも有効だ。

まとめ：DBバックアップを「整理整頓」するタイミング

DBバックアップは「動いてさえいれば見直さない」領域になりやすい。だが、複数エンジンを並行運用しているチームにとって、Databasementは散らかったcronとスクリプトを一気に整理する好機を与えてくれる。MIT・Docker一発・MCP対応という現代的なパッケージングで、しかも自社インフラに閉じ込められる。SaaSバックアップに払っていた料金を見直すきっかけにもなる。

まずはローカルでdocker runしてみて、開発DBを1本繋いでみるのが最短ルートだ。WebUIの完成度に驚くはずだ。

FAQ

Q. 既存のmysqldump/pg_dumpスクリプトと共存できますか？

A. 対象DBから取得する経路はDatabasement専用ではないため、共存可能です。ただしロックタイミングが重なるとパフォーマンス影響が出るため、スケジュールはずらしてください。段階的に既存cronを停止し、Databasementに統合していくのがおすすめです。

Q. PITR（ポイントインタイムリカバリ）はできますか？

A. v1.1.4時点では論理ダンプベースのスナップショットのみで、PITRは未対応です。PostgreSQLでPITRが必要な場合はPgBackRestと併用するのが現実的です。

Q. MCPサーバーは安全に使えますか？

A. APIトークンベースの認証で動作します。トークンはユーザーごとに発行・失効でき、操作はDatabasement内の監査ログに残ります。ただしClaude Code側でトークンを平文で扱う場面があるため、必要最小限のスコープで発行することを推奨します。

Q. Backblaze B2やCloudflare R2は本当に使えますか？

A. S3互換APIをサポートしているストレージなら原則動作します。エンドポイントURLとアクセスキー／シークレットキーをUIから設定するだけで、AWS S3と同じ使い勝手で利用できます。R2は外向け転送量が無料のため、海外DBから取得する構成で特に相性が良いです。

Q. データを世代管理しているとストレージが膨らみます。コスト最適化の方法は？

A. GFS設定で「日次7／週次4／月次12」のように粒度を分けて残し、月次バックアップだけGlacier相当の安価なストレージに転送するのが定番です。S3 Lifecycleルールで自動アーカイブも可能です。

Q. ハードウェア要件はどの程度？

A. 公式の最小構成は1vCPU／1GB RAMです。実際にはバックアップ対象が多くなるとCPU使用率が上がるため、本番運用では2vCPU／4GB RAMを目安にすると安定します。同時並列ジョブ数はQUEUE_WORKERS相当の環境変数でチューニングでき、ストレージ転送がボトルネックになるケースが多いのでネットワーク帯域も併せて確認してください。

Q. 復旧訓練（リストアテスト）は自動化できますか？

A. REST APIでリストアジョブをトリガーできるため、定期的に「別環境にリストアして件数を確認」というジョブをCIで回す運用が可能です。バックアップが取れているだけでなく、実際にリストアできる状態を保証する仕組みをセットで作ることを強く推奨します。

参照ソース

• David-Crty/databasement (GitHub) - 本体リポジトリ。README、Releases、Issuesを参照
• Databasement Documentation - 公式ドキュメント（Docusaurus）
• Databasement Live Demo - 公式が公開している動作デモサイト
• Databasement v1.1.4 Release Notes - 最新リリース内容
• Model Context Protocol - MCPサーバー仕様の一次情報