DBのバックアップは、たいてい「動いてはいるが誰も全体像を把握していない」状態になりがちだ。サーバーごとにcronとシェルスクリプトが散らばり、保存先も担当者もバラバラ。復元手順が本当に通るかは、事故が起きるまで誰も知らない。Portabaseは、その散らばった状態をWeb UIの一元管理に寄せるためのセルフホスト型OSSである。

Portabase（Portabase/portabase）は、PostgreSQL・MySQL・MongoDB・Redis・Docker Volumeなど10種のデータベースのバックアップと復元を、1つのダッシュボードから管理できるApache-2.0のオープンソースツールだ。GitHubスターは約1,383、2025年1月の最初のリリース以来174回のリリースを重ね、最新のv1.24.1は2026年7月17日に公開されている。本記事では、実際にDockerでv1.24.1を起動し、PostgreSQLを1本バックアップするところまで動かした実測とあわせて解説する。

Portabaseのデータベース詳細画面。バックアップ1件が成功し、サイズ177.93KB・所要時間176ms・ステータスsuccessと表示されている
実機で動かした結果。約9.9MBのPostgreSQLを対象に実行し、177.93KB / 176ms / success が記録された（Portabase Community Edition v1.24.1・2026-07-20 筆者環境で取得）
30秒でわかる Portabase（2026年7月時点）
  • ・課題：バックアップのcronとシェルスクリプトがサーバーごとに散らばり、成否も保存先も一覧できない。→ 解決：対象DBを登録すると、実行・履歴・成否・サイズを1画面で一元管理できる。
  • ・正体：Next.js製ダッシュボード＋Rust製エージェントの2コンポーネント構成。スター約1,383、最新v1.24.1、Apache-2.0。
  • ・対応DB：PostgreSQL / MySQL / MariaDB / MongoDB / SQLite / Redis / Valkey / Firebird / MSSQL / Docker Volume の10種（Redis・Valkeyは復元非対応）。
  • ・料金：完全無料。公式は「非営利団体が主導」と明記し、有料版・クラウド版は確認できなかった（サーバー費用のみ）。
  • ・注意：AI機能は一切ないDevOpsツール。テレメトリは既定で有効、明示的なオプトアウト環境変数は未確認。

この記事はDevOps・データベース運用ツールとしてPortabaseを解説します。自動化ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

本記事の位置づけについて
AI Heartlandは通常「AI関連OSSの日本語解説」を扱っています。PortabaseにAI機能はありません。本記事は明示的なリクエストにもとづく例外掲載であり、AI要素を後付けで演出することはしません。AIプロダクトを運用していればRAGのベクトルストア（pgvectorを載せたPostgreSQL等）やエージェントの状態を持つRedis／MongoDBも保護対象になる、という接点があるだけです。

Portabaseとは：10種のDBを一元管理するセルフホストのバックアップ基盤

Portabaseは、2024年10月に開発が始まったデータベースのバックアップ／復元ツールだ。狙いは明快で、「対象ごとにバラバラなバックアップ運用を、1つの管理画面に集約する」ことにある。公式サイトは自らを「非営利団体が主導する、オープンソースでセルフホスト型のツール」と位置づけている。

このツールが読者の「結局何ができるのか」に答えるなら、バックアップの実行・スケジュール・履歴・成否・保存先を、DBの種類をまたいで1画面に集約するものである。PostgreSQLはpg_dump、MongoDBはmongodump、というエンジンごとの作法をツール側が吸収するため、利用者はエンジンの差を意識せず同じUIで扱える。

実測で確認したプロジェクトの規模

記事化にあたり、GitHub APIで2026年7月20日時点の実データを確認した。数字は次のとおりだ。

・⭐ GitHubスター：1,383
・🍴 フォーク：81
・👥 コントリビュータ：16人
・📝 コミット数：約1,436
・📦 リリース数：174（最初の1.0.0-rc.1が2025-01-02、最新1.24.1が2026-07-17）
・⚖️ ライセンス：Apache-2.0（LICENSEファイルの中身も正規のApache License 2.0本文であることを確認）
・🛠️ 構成：ダッシュボード＝TypeScript / Next.js / BetterAuth / Drizzle / shadcn/ui、エージェント＝Rust / Tokio

注目すべきはリリース頻度だ。2025年1月の最初のリリースから約1年半で174回、直近も7月11日・13日・14日・16日・17日と数日おきにバージョンが上がっている。「公開直後に勢いがあるだけのリポジトリ」ではなく、現在進行形で開発が回っているプロジェクトである。スター数だけを見て判断すると見落とすが、コミット数・リリース数・直近の更新日という3点で見ると、実体のあるOSSだと言える。

アーキテクチャ：ダッシュボードにDBのパスワードを持たせない構成

Portabaseを理解するうえで最も重要なのが、2コンポーネント構成である。ここが一般的な「管理画面がDBに直接つなぐ」タイプのツールと決定的に違う。

Portabaseのアーキテクチャ。ダッシュボードが指示し、Rust製エージェントが対象DBをダンプして保存先へ送る流れ
指示はダッシュボード、実行はエージェント。DBの接続情報はエージェント側の設定ファイルに置かれる

ダッシュボード（Portabase Server）は、Next.jsで書かれたWeb UIだ。対象DBの一覧、バックアップの実行指示、履歴・成否・サイズの記録、通知や保存先の設定を受け持つ。メタデータ用にPostgreSQLを1つ必要とする。

エージェント（Portabase/agent-rust）は、Rustで書かれた常駐プロセスだ。バックアップ対象のDBと同じネットワークに置き、ダッシュボードへ定期的にポーリングして「バックアップせよ」という指示を受け取ると、実際にpg_dumpなどを実行する。

この分離が効いてくるのは権限設計の場面だ。DBの接続情報（ホスト・ユーザー・パスワード）はエージェント側の設定ファイルに置かれ、ダッシュボードは保持しない。管理画面をインターネットに公開しても、そこに本番DBの生の認証情報が置かれているわけではない。逆に言えば、エージェントを置いたホストの管理は厳格にする必要がある。

sequenceDiagram participant U as 管理者 participant D as ダッシュボード
(Next.js) participant A as エージェント
(Rust) participant DB as 対象DB participant S as 保存先
(ローカル/S3等) U->>D: バックアップを指示 A->>D: 定期ポーリング(既定5秒) D-->>A: 実行すべきジョブを返す A->>DB: 接続・サイズ確認 A->>DB: pg_dump 等でダンプ(-Fc) DB-->>A: ダンプデータ A->>S: 圧縮して保存(.tar.gz) A->>D: 結果(サイズ・所要時間・成否) D-->>U: 履歴とステータスを表示

実際にエージェントのログを見ると、この流れがそのまま観測できる。筆者環境では5秒間隔でポーリングし、対象DBへ接続してサイズを測り（Size of database is 9903127 bytes）、Using -Fc format（pg_dumpのカスタム形式）を選択していた。

対応データベースと主要機能：どこまでカバーするのか

対応エンジンは公式READMEの「Supported databases」表で明示されている。すべて「✅ Stable」扱いだが、復元（Restore）の可否には差がある点が重要だ。

Portabaseが対応する10種のデータベースエンジンと対応バージョン、復元可否の一覧
対応10エンジン。Redis・Valkeyはバックアップのみで復元は非対応（出典: Portabase/portabase README）
エンジン 対応バージョン 復元
PostgreSQL 12〜18 ✅
MySQL 5.7 / 8 / 9 ✅
MariaDB 10 / 11 ✅
MongoDB 4〜8 ✅
SQLite 3.x ✅
Redis 2.8+ ❌
Valkey 7.2+ ❌
Firebird 3.0 / 4.0 / 5.0 ✅
MSSQL Server 2017 / 2019 / 2022 / Azure SQL ✅
Docker Volume Docker Engine 20.10+ ✅

Redis・Valkeyが復元非対応なのは、導入前に必ず把握しておきたい。キャッシュとして使っているなら実害は小さいが、セッションストアやジョブキューとして永続性を期待している場合、「バックアップは取れているが戻せない」という状態になる。

逆に、この表に載っていないエンジンも把握しておきたい。分析用途で使われるカラムナDBのClickHouseや、Elasticsearch、Cassandraといったエンジンは対応外だ。データ基盤にこれらが含まれる場合、Portabaseだけでは全体をカバーできず、エンジン固有のバックアップ手段との併用になる。

機能面では、バックアップ実行のほかに次のものが用意されている。実際に管理画面で確認できた選択肢を挙げる。

・保存先（Storage）：S3、Google Drive、Azure Blob Storage、Google Cloud Storage。ローカル保存のほか、S3互換バケットへ退避できる
・通知（Notifier）：Email、Slack、Discord、Telegram、Gotify、ntfy.sh、Webhook、Nextcloud Talk、Microsoft Teams、Pushover の10種
・保持ポリシー：リポジトリのスキーマにretention_policiesテーブルが存在し、世代管理に対応する
・ヘルスチェック：healthcheck_logテーブルを持ち、DBへの死活監視を記録する
・組織・プロジェクト：organization / project 単位でDBをグルーピングでき、複数チームでの利用を想定した構造になっている

通知先にntfy.shやGotifyといったセルフホスト系が並んでいるのは、このツールの想定ユーザー像をよく表している。SaaSに寄せず自分で抱える運用者向けだ。

Portabaseのダッシュボード。エージェント100%オンライン、データベース100%オンライン、バックアップ1/1、成功率100%が表示されている
実際のダッシュボード。エージェント／DBの死活、バックアップ履歴、成功率、ストレージ使用量が1画面に集約される（筆者環境・v1.24.1）

Docker実機検証と本番運用設計：v1.24.1を実際に動かす

ここからは実際に動かした記録である。公式が挙げる導入方法は、CLI（推奨）、Docker Run、Docker Compose、Unraid Community Apps、Kubernetes（Helm）、開発用セットアップの6通り。今回は再現しやすいDocker Composeで検証した。

1. ダッシュボードを起動する

ダッシュボードにはメタデータ用のPostgreSQLが要る。必須の環境変数はPROJECT_URL（ダッシュボードのアクセスURL）とPROJECT_SECRET（エージェント暗号化用の秘密鍵）、そしてDATABASE_URLだ。

services:
  app:
    image: portabase/portabase:latest
    ports:
      - "80:80"
    environment:
      TZ: "Asia/Tokyo"
    env_file: [.env]
    volumes:
      - portabase-data:/data
    depends_on:
      db: { condition: service_healthy }

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=devdb
      - POSTGRES_USER=devuser
      - POSTGRES_PASSWORD=changeme
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U devuser -d devdb"]
      interval: 5s
      retries: 10

volumes:
  portabase-data:
ハマりどころ：PROJECT_URLはコンテナ内からも解決できる必要がある
最初に PROJECT_URL=http://localhost:8887（ホスト側8887→コンテナ80）で起動したところ、アプリが自分自身をサーバーサイドから呼ぶ際に connect ECONNREFUSED 127.0.0.1:8887 で失敗し、ログインが通りませんでした。コンテナ内のアプリは80番で待ち受けているため、コンテナ内のlocalhost:8887には誰もいないためです。ホスト側も80番に合わせ PROJECT_URL=http://localhost とすることで解消しました。ブラウザからのURLとコンテナ内から見たURLが一致するように組むのが要点です。

PROJECT_SECRETはopenssl rand -hex 32などで生成する。加えてAUTH_DEFAULT_USER／AUTH_DEFAULT_PASSWORDを指定しておくと管理者アカウントが初期投入され、メール送信の設定なしに初回ログインできる（パスワードは8文字以上・数字・大小英字・記号が必須）。

起動すると14ステップのオンボーディングが始まる。サインイン → アカウント → セキュリティ → 組織 → 通知 → ストレージ → 既定値 → エージェント作成 → エージェントキー → エージェント接続 → プロジェクト → DB設定 → 完了、という流れで、通知とストレージは後回しにできる（Skip可）。

2. エージェントを対象DBの隣に置く

オンボーディングでエージェントを1つ作ると、portabase agent "<名前>" --key <キー>という接続コマンドが表示される。このキーはBase64エンコードされたJSONで、中身はserverUrl・agentId・masterKeyB64の3点だった。Dockerで動かす場合は、このキーをEDGE_KEY環境変数に渡す。

  agent:
    image: portabase/agent:latest
    volumes:
      - ./config.json:/config/config.json:ro
    environment:
      EDGE_KEY: "<ダッシュボードが発行したキー>"
      LOG: "info"
      TZ: "Asia/Tokyo"
    extra_hosts:
      - "localhost:host-gateway"

ここで必須なのが/config/config.jsonだ。これを置かないとエージェントは起動直後にConfig file not found: /config/config.jsonを出し続け、ダッシュボードにも現れない。バックアップ対象のDBはこのファイルで定義する。

{
  "databases": [
    {
      "name": "shop (PostgreSQL)",
      "type": "postgresql",
      "host": "shopdb",
      "port": 5432,
      "database": "shop",
      "username": "shopuser",
      "password": "shoppass123",
      "generated_id": "f8364841-16e1-4f97-b8b3-3472b218acef"
    }
  ]
}

generated_idはUUIDを自分で採番する。この値がダッシュボード側のDBエントリと紐づく鍵になる。設定を置いて再起動すると、ログにDatabases: 1 instances loadedとPing shop (PostgreSQL) => trueが出て、ダッシュボードのオンボーディング「プロジェクト」ステップに対象DBが自動で現れた。

Portabaseのエージェント管理画面。登録したエージェントの状態が一覧表示されている
エージェント管理画面。複数拠点のエージェントをここで束ねる（筆者環境・v1.24.1）

3. 実際にバックアップして計測する

検証用に、PostgreSQL 16へcustomers5,000行とorders20,000行を投入した。エージェントが認識したサイズは9903127 bytes（約9.9MB）である。ダッシュボードの「Backup」ボタンから実行し、確認ダイアログで承認すると、数秒で結果が返ってきた。

実機計測の結果。バックアップサイズ177.93KB、所要時間176ms、成功率100%
約9.9MBのPostgreSQLを実際にバックアップした結果（2026-07-20・v1.24.1・ローカルDocker環境）

・生成サイズ：177.93KB（元DB 約9.9MB から大幅に圧縮）
・所要時間：176ms
・ステータス：success（成功率1/1＝100%）
・保存パス：backups/<日付>/<UUID>.tar.gz
・形式：pg_dumpのカスタム形式（-Fc）を選択

生成物が元DBの約1.8%まで縮んでいるのは、generate_seriesで作った規則的なテストデータのためで、実データではここまで縮まない。この数字は「小規模DBをローカルで取った場合の目安」以上のものではないが、少なくとも「登録から実行・記録まで一連が通る」ことは確認できた。ダッシュボード側にもサイズ・所要時間・ステータス・ログが記録され、冒頭のスクリーンショットの状態になる。

復元まで試すなら
本記事はバックアップの実行までを検証しました。実運用で本当に重要なのは復元が通るかです。PortabaseにはUIに「Restoration」タブがあり、対応エンジンなら同じ画面から復元を指示できます。導入時は必ず、本番と別の空DBへ復元するリハーサルを1度は実施してください。バックアップの成功ログは、復元の成功を保証しません。

ここまでで手元の検証は終わりだ。ただし本番に載せるなら、この先に決めるべきことがある。以降はPortabaseの機能を運用設計の観点から整理する。

エージェントをどこに置くか

エージェントはバックアップ対象のDBと同じネットワークに置く。対象DBをインターネットへ露出させずに済むのがこの構成の利点なので、そこを崩さないようにしたい。DBサーバーと同居させるか、同一VPC内の管理用ホストに置くのが基本形になる。

拠点やVPCが複数ある場合は、エージェントを複数登録して束ねられる。ダッシュボードのAgents画面が各エージェントの死活を表示するため、「どの拠点のバックアップが止まっているか」を1画面で把握できる。逆にいえば、エージェントが落ちていればバックアップも止まるので、この死活監視は必ず通知と紐づけておく。

スケジュールと保持世代

手動実行だけでは運用にならない。Portabaseはスケジュール実行と保持ポリシー（retention_policies）を持つため、次の3点をセットで決める。

・頻度：日次か時間毎か。論理ダンプ方式のため、頻度を上げるほど対象DBへの負荷とダンプ時間が効いてくる
・保持世代：何世代・何日分を残すか。保存先の容量と直結する
・実行時間帯：pg_dumpは対象DBに読み取り負荷をかける。業務ピークを外す

バックアップ実行が本番のクエリにどの程度影響しているかを実際に見たい場合は、sql-tapのようなプロキシ型のSQL監視ツールでトラフィックを覗くと、負荷の重なりを定量的に把握できる。

論理ダンプであることの意味
Portabaseが取るのはpg_dump等による論理バックアップです。これは「取得した瞬間の状態」に戻せるもので、任意の時点に戻すPITR（Point-in-Time Recovery）ではありません。日次バックアップなら、最悪ほぼ1日分の更新が失われます。このRPO（許容できるデータ損失時間）が業務要件に合うかどうかが、Portabaseで足りるか専用ツールが要るかの分岐点です。

保存先を「同じ場所」にしない

既定ではダッシュボードのボリュームに保存されるが、これはバックアップとして片手落ちになりやすい。サーバーごと失う障害では、DBもバックアップも同時に消えるからだ。S3・Azure Blob・Google Cloud Storage・Google Driveのいずれかを外部保存先として登録し、少なくとも1系統は別の場所へ逃がしておきたい。

通知は「失敗」だけでなく「無音」も検知する

通知先はEmail・Slack・Discord・Telegram・Webhookなど10種から選べる。ここで設計を誤りやすいのが、失敗通知しか設定しないパターンである。エージェントごと停止していれば、失敗すら通知されず静かにバックアップが途絶える。ヘルスチェック（healthcheck_log）とエージェントの死活を併せて監視し、「一定期間バックアップが成功していない」状態を検知できるようにしておく。

復元リハーサルを運用に組み込む

最後に、これが最も重要である。バックアップの成功記録は復元の成功を意味しない。四半期に一度でよいので、本番とは別の空DBへ実際に復元し、アプリが起動するところまで確認する手順を運用に組み込む。PortabaseはUIに「Restoration」タブを持ち、対応エンジンなら同じ画面から復元を指示できるため、この手順自体は難しくない。難しいのは、それを続けることのほうだ。

Portabaseは「使えるか」：他手段との比較・活性度・注意点

既存のバックアップ手段と何が違うか

Portabaseの立ち位置を、よくある3つの選択肢と比べて整理する。

  Portabase cron + シェルスクリプト マネージドDBの自動バックアップ pgBackRest / Barman
対象 10エンジン横断 何でも（自作次第） そのDBのみ PostgreSQL特化
一元管理UI ✅ Web UIで集約 ❌ サーバーに分散 △ クラウド管理画面ごと ❌ CLI中心
導入コスト 中（2コンポーネント） 低（すぐ書ける） 最低（既定で有効） 高（習熟が要る）
通知 ✅ 10種を標準装備 自作 クラウド側の仕組み 自作
PITR（時点復元） ❌ 論理ダンプ中心 自作次第 ✅ 多くは対応 ✅ 得意領域
ベンダーロック なし（自前保管） なし あり なし
費用 無料＋サーバー代 無料＋サーバー代 従量課金 無料＋サーバー代

この表から見える使いどころは明確だ。Portabaseが刺さるのは「複数種類のDBが複数のサーバーに散らばっていて、全体を俯瞰できていない」ケースである。逆に、PostgreSQL 1台だけを厳格に守りたい、秒単位のPITRが要る、という要件ならpgBackRestのような専用ツールのほうが適している。マネージドDBを使っていて自動バックアップで足りているなら、わざわざ置き換える理由はない。

同種のセルフホストOSS「Databasement」との違い

同じ「セルフホストでDBバックアップを一元管理する」領域には、当サイトでも解説したDatabasement（David-Crty/databasement・MIT）がある。狙う課題はほぼ同じなので、選ぶ際の違いを整理しておく。

・対応エンジン数：Databasementは6種（MySQL / PostgreSQL / MariaDB / MongoDB / SQLite / Redis）。Portabaseは10種で、Valkey・Firebird・MSSQL・Docker Volumeが追加で対応する
・構成：Databasementはシングルコンテナで完結し、本番DBへはSSHトンネルで接続する。Portabaseはダッシュボード＋エージェントの2つを置く代わりに、管理画面にDB認証情報を持たせない
・外部連携：DatabasementはREST APIとMCPサーバーを持ち、CIやAIアシスタントから操作できる。Portabaseにこの種のAI連携はない
・ライセンス：Databasementは MIT、Portabaseは Apache-2.0（特許条項を含む）

ざっくり言えば、構成の単純さとAPI/MCP連携を取るならDatabasement、対応エンジンの広さと権限分離を取るならPortabaseという住み分けになる。コンテナを1つ増やしたくない小規模環境では前者、複数拠点・複数エンジンを束ねたい環境では後者が向く。

もうひとつの用途がDocker Volumeのバックアップだ。自宅サーバーやVPSでコンテナを多数動かしている場合、DBだけでなくボリューム丸ごとを同じUIで扱えるのは実用的で、Unraid向けにCommunity Appsが用意されているのもこの層を狙っているためだろう。

活性度・バス係数・注意点

導入判断に必要な材料を、良い点と気になる点の両方から正直に並べる。

評価できる点

・開発が現役：174リリース・約1,436コミット。直近も数日おきに更新され、最新版は記事執筆の3日前にリリースされている
・ライセンスが素直：Apache-2.0で、LICENSEファイルの中身も正規のApache License 2.0本文。「OSSを名乗るが実は再配布制限」という類の罠は見当たらなかった
・権限分離の設計：ダッシュボードがDBの認証情報を持たない構成は、管理画面を公開する運用と相性が良い
・導入経路が広い：CLI・Docker・Compose・Helm・Unraidと、個人から小規模チームまで無理なく入れる
・費用がかからない：公式サイトは「非営利団体が主導」と明記し、有料版・クラウド版は確認できなかった

気になる点

・バス係数が小さい：コントリビュータは16人だが、コミットはRambokDev氏に291件と大きく偏り、次点は自動化ボット130件、Asuniia氏53件。実質的に中核開発者1〜2名のプロジェクトであり、その体制が続くかは読めない
・収益モデルが見えない：無料であること自体は利点だが、裏を返すと開発を支える継続的な収入源が公開されていない（支援はBuy Me a Coffeeのリンクのみ）。長期の持続性はリスク要因として見ておくべき
・Redis・Valkeyは復元不可：前述のとおり非対称。永続用途で使っているなら別手段が要る
・テレメトリが既定で有効：匿名・集計済みで、初回起動時に告知も出る誠実な作りだが、v1.24.1のコードを確認した限り環境変数によるオプトアウトは見つからなかった。外部通信を許さない環境ではネットワーク側での遮断が必要
・日本語UIは未確認：今回の検証範囲では英語UIのみを確認した
・設定ファイルに平文の認証情報：エージェントのconfig.jsonにはDBのパスワードが平文で入る。ファイル権限とホストの管理は厳格に

総合すると、「複数DBのバックアップ状況を可視化したい小〜中規模の自前運用」には十分候補になる。一方で、金融系のように厳密なRPO/RTOとPITRが要求される基幹系や、ベンダーサポートが契約上必須の環境には向かない。まずは本番以外の環境に入れ、復元リハーサルまで通してから判断するのが現実的だ。

本記事の実測値の限界
掲載した177.93KB / 176msは、ローカルDocker上の約9.9MBのPostgreSQLを1回バックアップした結果です。ネットワーク越しのS3保存、数十GB規模のDB、本番の負荷状況では値は大きく変わります。ベンチマークとしてではなく「一連の流れが実際に通ることの確認」としてお読みください。また、対応バージョンや機能は公式READMEの記載に準拠しており、全組み合わせを検証したものではありません。

向いているケース・向かないケース

判断を早めるために、条件を具体的に切り分けておく。

向いている

・複数種類のDBが複数台に散らばっている：PostgreSQLとMongoDBとRedisが別々のサーバーにいて、全体の成否を誰も一覧できていない状態。Portabaseが最も効くのはここ
・自前のVPS・オンプレ・自宅サーバーで運用している：マネージドDBの自動バックアップが使えず、cronを自作している環境
・Docker中心の構成：Docker Volumeを同じUIで扱えるため、コンテナで固めた小規模環境と相性が良い
・日次バックアップで許容できる：RPOが「最大1日分の損失まで許容」なら論理ダンプで足りる

向かない

・秒単位・分単位のRPOが必要：論理ダンプではPITRができない。PostgreSQL単体ならpgBackRestやBarman、マネージドならその自動バックアップを使うべき
・マネージドDBだけで完結している：RDSやCloud SQLの自動バックアップで要件を満たせているなら、コンポーネントを2つ増やす理由がない
・Redis／Valkeyの復元が必須：現時点で復元非対応のため、別手段との併用が要る
・ベンダーサポートが契約上必須：非営利・少人数体制のOSSであり、商用サポート窓口は確認できなかった
・外部通信を一切許さない：テレメトリが既定で有効かつオプトアウト変数が未確認のため、ネットワーク遮断の運用が別途必要

まとめ：散らばったバックアップを1画面に寄せる道具

Portabaseは、派手な機能で驚かせるツールではない。やっていることは「バックアップの実行と記録を、DBの種類をまたいで一元化する」という一点である。しかしこの一点は、サーバーが増えるほど効いてくる部分でもある。

・何ができるか：10種のDBとDocker Volumeのバックアップ／復元を、Web UIから実行・記録・通知できる
・何を解決するか：サーバーごとに散らばったcronとシェルスクリプト、把握できていない成否と保存先
・何を代替できるか：自作のバックアップスクリプト群と、その運用管理。ただしPITRが要る領域は専用ツールの担当

そして繰り返しになるが、これはAIツールではない。AIプロダクトを運用している読者にとっての接点は、そのプロダクトが依存するPostgreSQLやMongoDB、Redisを守る側にある。RAGのインデックスもエージェントの状態も、失えば作り直しになる資産だ。そこを守る道具として見ると、この種のツールを1つ持っておく価値は理解しやすい。

導入を検討するなら、まずは本記事のとおりDocker Composeで手元に立て、対象DBを1本登録し、バックアップと復元の両方を通してみることをおすすめする。所要時間は30分ほどで、その30分で「自分の環境に合うか」はかなり判断できる。

参照ソース

・Portabase/portabase — GitHub（README、Supported databases表、LICENSE、docker-compose.prod.yml、.env.example、src/features/telemetry/ 配下のコードを参照。スター数・コミット数・リリース数はGitHub APIで2026-07-20に取得）
・Portabase/agent-rust — GitHub（エージェントのREADME、docker-compose.prod.yml、databases.json、entrypoint.sh を参照）
・Portabase 公式サイト（プロジェクトの位置づけ・非営利団体による運営の記載）
・Portabase 公式ドキュメント — Dashboard Setup（導入方法と必須環境変数PROJECT_URL／PROJECT_SECRET）
・実機検証：portabase/portabase:latest（Community Edition v1.24.1）およびportabase/agent:latest（v1.17.0）をDocker上で起動し、PostgreSQL 16に対してバックアップを実行（2026-07-20・筆者環境）