OpenShipデータベースバックアップの選び方

2026年8月2日に確認したOpenShip公式料金ページでは、Cloudに「1アクティブメンバーあたり月額20米ドル」、日次バックアップとポイントインタイムリカバリが含まれると案内されています。自主管理側はバックアップとPITRが「DIY」とされているため、運用担当者が少ない、復旧目標が明確、本番データを失えないなら托管を優先してください。データベース運用の経験、独立した保存先、定期的な復旧演習がある場合だけ自主管理を選ぶのが安全です。(openship.io)

このページは、原型データベースを本番へ移したいAI SaaS開発者、Agentの会話やユーザーファイルを保存する小規模チーム、復旧責任の所在を比較している技術責任者向けです。単純な月額料金ではなく、保存容量、複製、監視、復旧時間、失敗時の対応まで含めて判断します。

まず復旧対象を分解して、必要な方式を決めます

OpenShipのデータベースバックアップを考えるとき、PostgreSQLだけを保存すればよいとは限りません。AI SaaSでは、次のデータが別々の場所に存在することがあります。

PostgreSQL公式文書では、pg_dumpによる論理バックアップと、継続アーカイブおよびPITRを別の方式として説明しています。つまり、バックアップファイルを1つ作ることと、障害直前の状態へ戻せることは同じではありません。(postgresql.org)

Redisも用途によって判断が分かれます。キャッシュだけなら消失後の再生成を前提にできますが、Agentの実行待ち状態やセッションを持たせているなら、RDBやAOFの保存方針が必要です。Redis公式文書でも、RDBはスナップショット、AOFは書き込み記録として説明され、復旧時のデータ損失幅が異なります。(redis.io)

OpenShipの自主管理データベースは、何もしなくても自動バックアップされますか。

自主管理環境では、OpenShipのプラン表に日次バックアップやPITRが標準提供されるとは記載されておらず、該当機能はDIY扱いです。したがって、cronやバックアップツール、外部ストレージ、通知、復旧手順を自分で用意し、失敗を検知する責任があります。托管機能から自主管理環境の頻度や保持期間を推測してはいけません。(openship.io)

次にチーム段階ごとの費用変数を並べます

費用比較では、まず金額ではなく変数を洗い出します。托管データベースの料金に含まれる範囲は、契約プラン、メンバー数、保存期間、データ量、復旧機能によって変わるため、確認日と通貨を残してください。

2026年8月2日に公式ページで確認できるOpenShip Cloudの料金は、月額20米ドルまたは年払い時の実質月額16米ドルと案内されています。ただし、これはプラン料金であり、あなたのAI SaaS全体のバックアップ費用やコンピュート費用を含む総額とは限りません。(openship.io)

計算は次の形にすると比較しやすくなります。

托管の月間総コスト
= プラン料金
+ 超過ストレージ
+ 追加転送・保持料金
+ 契約外の復旧作業

自主管理の月間総コスト
= サーバー・ディスク費
+ 複製先ストレージ費
+ 監視・通知費
+ 月間作業時間 × 時間単価
+ 障害時の復旧対応費

托管バックアップと自分でスクリプトを書く方法は、どちらが得ですか。

保存容量が小さく、すでに監視や外部ストレージを持っている場合は、自主管理の現金支出が低く見えることがあります。しかし、毎週の失敗確認、古いファイルの削除、鍵の更新、PostgreSQLやRedisのバージョン更新、復旧演習を実施しないなら、その安さは見かけだけです。

一方、托管方式は月額費用が発生しますが、バックアップ生成、保存、監視、復旧入口がまとまっている場合があります。契約前には「保存されるもの」「保持期間」「復旧単位」「復旧時に必要な権限」「サポート範囲」を確認してください。

ここでいうRPOは、どこまでのデータ損失を許容するか、RTOはどれだけの時間でサービスを戻すかを示す変数です。固定の復旧時間や保持日数をOpenShipの公式説明にないまま埋めるのではなく、契約ページと実環境で確認してください。

その後、原型・独立開発者・小規模チームで判断を分けます

原型プロジェクトでは、まずデータを3種類に分類します。再生成できる埋め込みやキャッシュ、再取得できないユーザー情報、復旧できないと課金やAgent実行が壊れる業務状態です。

再生成可能なデータだけなら、複雑な多重バックアップを避けても構いません。ただし、設定のエクスポートと、別の保存場所に置いた復旧副本を1つ用意し、実際に読み込めることまで確認してください。「バックアップなし」はコスト削減ではなく、損失を受け入れる選択です。

独立開発者では、ストレージ費より作業時間が問題になります。バックアップスクリプトが成功したか、保存先へ転送できたか、古いファイルが削除されたか、通知が届くかを確認する担当者が自分一人なら、障害時に本番開発が止まります。

小規模チームでは、権限設計を先に決めます。バックアップを作成できる人、削除できる人、復旧を承認する人を同じアカウントに集約すると、誤削除や認証情報の漏えい時に被害が広がります。托管方式でも、自主管理方式でも、役割と復旧入口を文書化してください。

注意：バックアップジョブが「成功」と表示されても、復旧に成功したとは限りません。ファイルの存在確認、整合性確認、隔離環境での起動、アプリの再接続まで完了して初めて、復旧可能なバックアップと判断できます。

本番投入前に復旧コストを実際の手順へ落とします

AI SaaS上線前の復旧コストは、次の5段階で見積もります。

1. 復旧範囲を確定します。 PostgreSQL、Redis、オブジェクトストレージ、タスクキュー、環境変数、DNS、秘密情報を一覧化します。
2. 許容損失を決めます。 「数時間前まで戻ればよい」のか、「直前の処理まで必要」なのかをサービス単位で記録します。
3. 保存先を分離します。 稼働中のサーバーと同じディスクだけに置かず、別のアカウント、別ノード、または別の保存場所へ複製します。
4. 隔離環境へ復旧します。 本番データを上書きせず、別名のデータベースと一時的なアプリ環境で読み込みます。
5. アプリの再接続を確認します。 ログイン、Agent会話、ファイル参照、課金状態、キュー再投入、外部API連携を順番に検証します。
6. 所要時間と欠落データを記録します。 復旧開始からアプリ利用可能までの時間、戻らなかった項目、手作業の内容を次回の費用変数に反映します。

• [ ] PostgreSQLの復旧副本を隔離環境へ読み込んだ
• [ ] Redisをキャッシュ用と業務状態用に分類した
• [ ] Agent会話とユーザーファイルの対応関係を確認した
• [ ] 外部タスクキューの未処理ジョブを再現した
• [ ] 環境変数、秘密情報、DNSの復旧手順を保管した
• [ ] バックアップ成功と復旧成功を別々に記録した
• [ ] 担当者以外の人でも手順を実行できた
• [ ] 次回の演習日と保存期間の見直し日を決めた

データベースバックアップは、どれくらいの期間保管すべきですか。

一律の日数を決めるのではなく、削除要求、請求訂正、ユーザー問い合わせ、障害発見までの時間、契約上の保存義務から逆算します。短期の原型なら直近の復旧副本と設定保存で足りることがありますが、継続運用のサービスでは、日次だけでなく変更履歴や月次の基準点が必要になる場合があります。

バックアップに成功したのに、なぜ復旧できないのですか。

代表的な原因は、保存先の権限切れ、暗号鍵の欠落、破損ファイル、データベースのバージョン差、マイグレーション不足、オブジェクトストレージとの参照不一致です。PostgreSQLのダンプは復元対象を選べる一方、PITRに必要な継続アーカイブとは役割が異なります。RedisもRDBやAOFの方式によって、戻せる時点と作業が変わります。(postgresql.org)

最後に、托管・自主管理・混合を選びます

低い運用負担を優先し、復旧目標が明確なら、OpenShip CloudのようにバックアップとPITRがプランに含まれる托管方式を候補にします。自主管理は、保存先を自分で選べる、データ位置を細かく制御できる、既存の運用基盤を流用できる点が利点ですが、失敗検知と復旧演習まで担当する必要があります。(openship.io)

混合方式は、機密性の高いデータベースを管理可能な環境に置き、プレビューや一時的な処理を托管側へ寄せる考え方です。ただし、アプリだけ移してもデータベース、ファイル、キューの復旧関係が分断されると、障害時に戻せません。OpenShipのCloud、自主管理、Hybridの責任範囲は、実際の構成と契約内容で確認してください。(openship.io)

自前のLinuxサーバーだけで長期運用する方式は、月額の見た目を抑えやすい反面、パッチ適用、ディスク障害、バックアップ監視、鍵管理、当番対応を自分で抱えます。復旧演習用の環境まで別に用意すると、サーバー費と管理時間が増えます。逆に、短期の検証や隔離した復旧環境が必要なら、日本向けMac miniレンタルを使って作業環境を分けるほうが、手元の開発機を止めずに検証しやすい場合があります。

ただし、Macを本番データベースの長期運用基盤として選ぶ話ではありません。物理インターフェース、常時稼働要件、既存Linuxツールとの互換性が必要なら、自前サーバーや托管サービスを選ぶべきです。復旧演習、移行確認、短期の検証環境が目的なら、Macレンタルの利用条件を確認し、データの持ち出し範囲と削除手順を決めてから使ってください。

購入や契約を決める前に、まず隔離環境で1回、データベースからアプリ再接続までを通して復旧します。その演習で担当者、所要時間、欠落データ、必要な権限が明確になれば、托管を契約するのか、自主管理ノードを準備するのか、混合構成にするのかを価格表ではなく実際の復旧証拠で判断できます。