DBAtlas · データベース運用アトラス

MongoDB のバックアップとリストア (mongodump、mongorestore、snapshot)

MongoDBレベル: 中級所要時間: 45〜90 分

インストール済みの MongoDB にバックアップの運用を構成し、バックアップからの復旧をシナリオごとに説明します。バックアップ: mongodump による単一 collection、データベースまたはデプロイメント全体 (--archive --gzip。replica set では --oplog による一貫性のある時点、secondary からの読み取り)、認証情報ファイル、systemd timer/cron による保持期間付きの定期バックアップ、テストリストア、および任意でファイルシステムの snapshot。リストア: リストアのリハーサル、フルリストア、単一データベース/collection、バックアップ + oplog による特定時点への復旧、別クラスタへのクローン、sharded cluster。数百 GB 規模のデータ、迅速な復旧が必要な場合、または sharded cluster では、mongodump ではなく snapshot やエンタープライズツール (PBM、Ops Manager) を選びます。選び方は最初のステップで説明します。

構成: バックアップサーバーまたはメンバー 1 台 + replica set / 単一インスタンス / sharded cluster (mongos)

シナリオ

  • バックアップを構成する: mongodump、スケジュール、テストリストア — バックアップユーザー、認証情報ファイル、手動および定期の mongodump、別名でのテストリストア。任意で snapshot と mongoexport。初めて構成する場合はここから始めてください。
  • バックアップは本当にリストアできるか (--dryRun と一時インスタンスでのリハーサル) — 本番データには触れません: アーカイブの整合性、含まれる namespace と oplog を確認し、任意で一時的な mongod へのフルリストアとドキュメント数の照合を行います。
  • すべてのデータをバックアップからリストアする (フルリストア、--drop) — データの大部分が失われたか破損しており、デプロイメントをバックアップ取得時点に戻します。バックアップ以降の書き込みは失われ、リストア中はアプリケーションが停止します。
  • 単一のデータベースまたは collection を戻す (--nsInclude、別名で、またはその場で) — collection/データベースが削除または破損したが、残りは正常: その namespace だけをバックアップから戻します。他のデータには触れず、アプリケーションは稼働したままにできます。
  • 特定の時点に戻す: バックアップ + oplog (誤った drop、誤った update/delete) — 誤操作がバックアップの後に発生し、その時点までの書き込みも必要な場合: 最新のフルバックアップをリストアし、本番の oplog を誤操作の直前まで適用します (--oplogReplay --oplogLimit)。replica set のみ。
  • バックアップを別のクラスタ/サーバーにリストアする (クローン、テスト環境、移行) — ソースのデプロイメントには触れません: バックアップを別の replica set またはインスタンスに展開します (テスト/レポート用コピー、サーバー移行、バージョンアップグレード)。ユーザーの移行は任意です。
  • sharded cluster をリストアする: mongodump の制約と適切な方法 — バックアップ対象の構成は sharded cluster: mongos 経由の論理リストア (shard key の再作成、balancer)、または協調して取得した snapshot によるクラスタ全体の物理的な再構築。

開始前の確認

  • バックアップ対象のサーバーがサポート対象のオペレーティングシステムで稼働しており、時刻が NTP で同期され、タイムゾーンが正しいこと (バックアップファイル名とスケジュールはローカル時刻に基づきます)。
  • このサーバーから … の名前解決とポートへの接続ができること。… replica set では、接続文字列のホスト名が rs.conf() 内のメンバー名と一致している必要があります。ドライバはそれらの名前に接続します。…
  • … がデータディスクとは別のディスクまたはネットワーク共有上にあり、空き容量が圧縮バックアップのサイズ (通常はデータの 20〜50%) × 保持期間以上あること。同じディスク上のバックアップは、ディスクが失われるとデータと一緒に失われます。
  • 認可が有効で、… ユーザー (root、または userAdminAnyDatabase + clusterAdmin ロール) とそのパスワードを把握していること。バックアップユーザーはこのユーザーで作成します。
  • oplog ウィンドウがフルバックアップの所要時間より十分に長いこと (少なくとも数時間)。--oplog はバックアップ中に生成された oplog エントリを収集するため、ウィンドウがバックアップより短いとバックアップは失敗します。… 特定時点への復旧では、本番 oplog の最初のエントリが、使用するフルバックアップの完了時点より前である必要があります。そうでなければ、その間の操作はどこにも残っていません。…
  • MongoDB リポジトリ (repo.mongodb.org) に HTTPS で接続できるか、社内ミラーが設定されていること。ツールがすでにサーバーにインストールされていれば、そのバージョンが表示されます。
  • dbPath (…) が … LV 上にあり、ボリュームグループに … 以上の空きがあること。WiredTiger の journal (…/journal) は同じ LV 上にある必要があります。別のディスクに移動している場合は、snapshot の前に fsyncLock が必須です。
  • root または sudo 権限があること。フルリストアを行う場合は、メンテナンスウィンドウとアプリケーションチームの承認を得ていること。… リストアの前に、インシデントの記録 (いつ、どの操作で、誰が) を残し、どのデータが戻るかをアプリケーションチームが把握していること。…
  • バックアップがこのガイドの「バックアップを構成する」シナリオで構成済みであること: ツール (mongorestore、mongosh) と認証情報ファイル … (…: backup + restore) がこのサーバーにあること。ない場合は、先に バックアップを構成する シナリオの最初の 2 フェーズを実行してください。
  • リストアではデータと index が書き直されます: ターゲットサーバーのデータディスクに、戻すデータ (非圧縮) の 1.5 倍以上の空き容量があること。… replica set では secondary もレプリケーションで同じ書き込みを受け取るため、リストア中は oplog ウィンドウが短くなります。…
  • … に、戻すデータの非圧縮サイズ (フルバックアップ + oplog) と同等の空き容量があること。一時 mongod は 127.0.0.1 のポート … でのみ待ち受けるため、このポートが空いている必要があります。
  • ターゲット (…) がインストール済みで稼働しており、認可が有効で、… (root) ユーザーのパスワードを把握していること。ターゲットのバージョンはソースと同じかそれより新しいこと (例: 7.0 → 8.0)。古いバージョンへのリストアはサポートされていません。

ガイドのフェーズ

  • ツールのインストール — MongoDB … のリポジトリを追加する · MongoDB … のリポジトリを追加する · mongodump、mongorestore、mongosh をインストールする · バックアップディレクトリを準備する
  • バックアップユーザーと認証情報ファイル — バックアップユーザーを作成する · 認証情報ファイルを書き込む (--config) · 接続をテストする
  • 手動バックアップ (mongodump) — データサイズと oplog ウィンドウを確認する · balancer を停止する · mongodump でバックアップを取得する · balancer を再開する · バックアップを検証する (gzip と dryRun) · クエリによる部分バックアップ (--query)
  • リストア (mongorestore) — 別名でのテストリストア (--nsFrom/--nsTo) · ドキュメント数を比較する · テスト用データベースを削除する · oplogReplay 用のロールを定義する · その場でのフルリストア (--drop) · 一時的な権限を取り消す …
  • mongoexport / mongoimport (データ移送用で、バックアップではない) — collection をエクスポートする (mongoexport) · 別の collection にインポートする (mongoimport) · 型を比較してクリーンアップする
  • ファイルシステムの snapshot — LVM snapshot を取得する (fsyncLock 付き) · snapshot をバックアップディレクトリにアーカイブする · fsyncLock でファイルコピーを取得する
  • sharded cluster のバックアップ: 制約とエンタープライズ向けの方法 — 一貫性のある sharded cluster バックアップの方法を選ぶ
  • 定期バックアップと保持 — balancer がバックアップの時間帯以外で動作するように制限する · バックアップスクリプトを書き込む · スクリプトを実行可能にする · リモートサーバーへの SSH 接続を準備する · systemd の service と timer を作成する · 定期バックアップを手動で起動して検証する …
  • 監視とメンテナンス — 最新バックアップの経過時間を監視する · 定期的な復旧訓練
  • 1. 診断: バックアップファイルとツール — バックアップファイルと直近のバックアップを順に一覧表示する
  • 2. リハーサル: アーカイブの読み取り — 圧縮の整合性を確認する (gzip -t) · データを書き込まずにリストアを試す (--dryRun) · アーカイブに oplog が含まれているか (一貫性のある時点)
  • 3. リハーサル: 一時インスタンスへのフルリストア — 一時インスタンス用の mongod を準備する · 一時 mongod を起動する · バックアップを一時インスタンスにリストアする · リストアしたデータの件数を数える · 一時インスタンスを停止して削除する
  • 4. 事後作業 — リハーサルの結果を記録する
  • sharded cluster: このシナリオではフルリストアを行わない — sharded cluster のシナリオに移る
  • 1. 診断: フルリストアは適切なシナリオか — 現在の状態と影響を受けたデータを確認する · データを書き込まずにリストアを試す (--dryRun)
  • 2. セーフティネット — アプリケーションを停止して接続を確認する · 現在の状態をバックアップする (切り戻しポイント)
  • 3. 実行: フルリストア — oplogReplay 用の一時的な権限を付与する · バックアップをその場でリストアする (--drop… --oplogReplay…) · 一時的な権限を取り消す · リストアが作成した一時的なユーザー collection をクリーンアップする
  • 4. 検証 — ドキュメント数と index 数を確認する · replica set が追いついたことを確認する
  • 5. 事後作業 — 新しいフルバックアップを取得してアプリケーションを起動する
  • 1. 診断: namespace の現在の状態とバックアップ内の状態 — 本番の状態を確認する · データを書き込まずにリストアを試す (--dryRun)
  • 2. セーフティネット — 現在の状態をバックアップする (切り戻しポイント)
  • 2. 実行: 別名でリストアする — バックアップを別名でリストアする (--nsFrom/--nsTo) · バックアップと本番の件数を比較する · 削除されたドキュメントを本番に戻す ($merge) · 一時コピーを削除する
  • 3. 実行: その場でリストアする (--drop) — shard key を保持する: collection を再度 shard 化する · namespace をその場でリストアする
  • 特定時点への復旧は replica set のみ — このデプロイメントでは oplog による特定時点への復旧はできない
  • 1. 診断: 誤操作の時点と oplog ウィンドウ — oplog で誤操作を探す · フルバックアップが oplog ウィンドウ内にあることを検証する
  • 2. セーフティネット: 本番の oplog をコピーする — 本番の oplog のコピーを取得する · 現在の状態をバックアップする (切り戻しポイント)
  • 3. 実行: 一時インスタンスでその時点に戻す — 一時インスタンス用の mongod を準備する · 一時 mongod を起動する · フルバックアップを一時インスタンスにリストアする · 本番の oplog を誤操作の直前まで適用する · 復旧したデータを一時インスタンスで確認する · 復旧したデータを本番に移す …
  • 4. 事後作業 — 新しいフルバックアップを取得して根本原因を解消する
  • 1. 診断: ターゲットは正しく、互換性があるか — ターゲットがソースでないことを確認し、バージョンを確認する · データを書き込まずにリストアを試す (--dryRun)
  • 2. セーフティネットとターゲットの認証情報 — ターゲット用の一時的な認証情報ファイルを書き込む · ターゲット上の既存データをバックアップする
環境に合わせた手順プランを開く →