バックアップの準備
クラスターまたはレプリカセットをバックアップする前に、データをバックアップする方法とバックアップするデータを決定します。 このページでは、バックアップを開始する前に考慮する必要がある項目について説明します。
バックアップ構成オプション
特定のシステムのバックアップとリカバリの要件は、システムの所有者セットのコスト、パフォーマンス、データ保護の標準を満たすために異なります。
MongoDB Ops Managerのエンタープライズバックアップとリカバリは、それぞれ独自の強度とトレードオフを持つ 5 つのバックアップアーキテクチャをサポートしています。 バックアップ アーキテクチャを構成して配置する前に、配置のデータ保護要件を満たすアーキテクチャを検討してください。
例
要件として、運用コストが低いシステムを検討します。 システムの所有者は、バックアップおよびリカバリ構成のためにストレージに費やできる金額に対して厳格な制限がある場合があります。 その結果、リカバリ時間が長くなる可能性があります。
逆に、 リカバリ時間目的が低いシステムも検討してください。 リカバリ要件を満たすバックアップおよびリカバリ構成になる場合、システムの所有者はストレージ コストを許容します。
MongoDB Ops Managerのエンタープライズバックアップとリカバリは、次のバックアップアーキテクチャをサポートします。
高可用性、圧縮、 重複除外 などのファイルシステム バックアップ用の高度な機能を備えた SAN 上のファイル システム
1 つ以上のANAデバイス上のファイル システム
高可用性構成の MongoDB ブロックストア
スタンドアロン構成の MongoDB ブロックストア
独自のデータ保護アプローチを開発するためのガイダンスとして、バックアップ アーキテクチャの推奨事項を提供します。 推奨事項は、各シナリオまたは配置をカバーしたり表現したりするものではありません。
バックアップ方法の機能
バックアップ システムの機能 | SAN上のファイル システム | las上のファイル システム | Amazon Web Services S3 ブロックストア | MongoDB HA Blockstore | MongoDB ブロックストア |
|---|---|---|---|---|---|
スナップショットのタイプ | 完全[1] | 完全[1] | 多くの部分的な | 多くの部分的な | 多くの部分的な |
バックアップデータの重複除外 | SAN が をサポートする場合、 | No | はい | はい | はい |
バックアップ データ圧縮 | はい | No | はい | はい | はい |
バックアップ データのレプリケーション | SAN が をサポートする場合、 | No | No | はい | No |
バックアップ ストレージのコスト | より高い | 平均 | 低 | より高い | 低 |
バックアップを管理するための従業員時間 | 平均 | 平均 | 低 | より高い | 平均 |
バックアップRTO | 低 | 平均 | 低 | 低 | 平均 |
| [1] | （ 1 、 2 ）ファイルシステムストアへの増分バックアップを実行するために、 MongoDB Agentはバックアップ用に指定されたパス内の各ストレージエンジンのファイルをデータのブロックにスライスし、変更されたブロックのみを に転送しますMongoDB Ops Manager 。 MongoDB Ops Managerは、受信したブロックから新しいスナップショットを作成し、前の完全バックアップ スナップショットから残りの変更されていないブロックをコピーします。 ファイル システムに保存されるたびに、ネットワーク I/O が節約されます。 このようなバックアップ スナップショットには、バックアップされた MongoDB デプロイからのすべての必要ファイルの完全なコピーが含まれており、レコードの重複は除外されません。 |
注意
特定のバックアップ方法をいつ使用するか？
大量のデータでバックアップを頻繁に実行し、バックアップから復元するには、 SAN上のファイルシステム、 Amazon Web Services S3 互換のストレージ スナップショット ストア、またはレプリカセットとして構成されたMongoDBブロックストア、またはシャーディングされたクラスター。
MongoDB database に依存せずにデータを復元するには、 Amazon Web Services S3 互換ストレージのスナップショットストア、1 つ以上のlasデバイス、または高可用性などのファイルシステムバックアップ用の高度な機能を持つSAN上のファイルシステムへのバックアップを検討してください。圧縮、または重複除外。
内部ストレージとメンテナンスのコストを最小限に抑えるには、 Amazon Web Services S3 互換ストレージ スナップショット ストアまたはMongoDBスタンドアロン ブロックストアにバックアップすることを検討してください。
MongoDB スタンドアロン ブロックストアの回復力は限定的です。 ディスクがいっぱいになると、このブロックストアはオフラインになる可能性がありGo 。 バックアップ スナップショットは、ストレージを追加した後にのみ復元できます。
バックアップ サイズの推奨事項
データのバックアップをサイズ化する場合は、レプリカセットのサイズを2 TB 以下の非圧縮データに管理します。 データベースの非圧縮データが2 TB を超えた場合:
データベースのシャード
各シャードの非圧縮データは 2 TB 以下である
これらのサイズに関する推奨事項はベストプラクティスです。 これらはMongoDB database またはMongoDB Ops Managerの制限ではありません。
バックアップと復元では、大量の CPU、メモリ、ストレージ、ネットワーク帯域幅を使用する可能性があります。
例
10 GBps や 100 GBps などの記載されたネットワーク スループットは、論理的な最大値です。 その値は、ネットワーク トラフィックの共有または調整を考慮していません。
次のシナリオを検討してみましょう。
2 TB のデータベースをバックアップする場合。
ホストはMongoDB Ops Managerからバックアップ ストレージへの 10 Gbps TCP 接続をサポートしています。
ネットワーク接続では、パケットロスが非常に少なく、ラウンドトリップ遅延時間が短いです。
このような状況では、データの完全なバックアップが完了するまでに30時間以上かかる場合があります。
これにはディスクの読み取りおよび書込み速度は考慮されません。これは、単一またはミラーリングされた NVMe ストレージ デバイスで最大 3 Gbps の読み取りと 1 Gbps の書込みを超える可能性があります。
連続する各増分バックアップを完了するのに必要な時間は、書込み負荷によって異なります。
このデータベースを 4 つのシャードにシャードすると、各シャードはバックアップを個別に実行します。 これにより、バックアップが完了するまでの時間は 8 時間未満になります。
スナップショット頻度と保持ポリシー
デフォルトでは、 MongoDB Ops Managerは 24 時間ごとにデータの基本スナップショットを取得します。
必要に応じて、管理者は基本スナップショットの頻度を6 、 8 、 12 、または24時間に変更できます。 MongoDB Ops Managerはスケジュールされたスナップショットを自動的に作成します。 オンデマンドスナップショットの取得も可能です。
MongoDB Ops Managerは、次の表に記載されている期間のスナップショットを保持します。
配置の バックアップ を終了すると、 MongoDB Ops Managerは現在の保持ポリシーの日付内にあるスナップショットを直ちに削除します。
配置の バックアップ を停止すると、 MongoDB Ops Managerは新しいスナップショットの取得を停止しますが、リストされている有効期限が切れるまで既存のスナップショットを保持します。
スナップショット | デフォルトの保持ポリシー | 最大保持ポリシー |
|---|---|---|
基本スナップショット | 2 日 | 5 日間（頻度が 24 時間の場合は 30 日間） |
毎日のスナップショット | 0 日 | 1 年 |
週次スナップショット | 2 週間 | 1 年 |
月次スナップショット | 1 か月 | 7 年 |
バックアップ配置のスケジュールは、 Backupページから利用可能な Edit Snapshot Scheduleメニューのオプションを使用して変更できます。 管理者は、 API の snapshotSchedule リソースを使用して、スナップショット頻度と保持を変更できます。
参照時間を変更すると、予定される次回のスナップショットの時間が変更されます。 現在の次のスナップショット時間よりも早く予定されたスナップショットを実行することはできません。 現在の次のスナップショット時間は、現在の参照時間にスナップショット間の間隔を加えた時間です。
次のスナップショットの時間を決定するには、現在の次のスナップショット時間と新しい参照時間を比較します。
新しい参照時間が現在のスナップショット時間より前の場合、次のスナップショットは現在の次のスナップショット時間後に発生します。 スナップショットは、新しい参照時間に、現在の次のスナップショット時間を超えるために必要な間隔の数を加えて発生します。 変更を行ったときにこの時間がすでに経過している場合、 MongoDB Ops Managerは新しい参照時間の次回の発生で次のスナップショットを取得します。 例については、次の表の最初の 2 行を参照してください。
新しい参照時間が現在のスナップショット時間より後の場合、 MongoDB Ops Managerは新しい参照時間の次回の発生で次のスナップショットを取得します。 例については、次の表の 3 行目と 4 行目を参照してください。
変化の時間 | 現在の参照時間 | スナップショットの間隔 | 現在の次のスナップショット時間 | 新しい参照時間 | 次のスナップショットの時間 |
|---|---|---|---|---|---|
08:00 UTC | 12:00 UTC | 6 時間 | 12:00 UTC | 10:00 UTC | 今日の 16:00 UTC |
23:00 UTC | 12:00 UTC | 6 時間 | 00:00 UTC | 10:00 UTC | 今日の 04:00 UTC |
08:00 UTC | 12:00 UTC | 6 時間 | 12:00 UTC | 19:00 UTC | 今日 19:00 UTC |
20:00 UTC | 12:00 UTC | 6 時間 | 00:00 UTC | 19:00 UTC | 今日の 01:00 UTC |
保存するスナップショットの数を少なくするためにスケジュールを変更すると、 MongoDB Ops Managerは新しいスケジュールに準拠するように既存のスナップショットを削除しません。 不要なスナップショットを削除するには、「 スナップショットの削除 」を参照してください。
制限
MongoDB Ops Manager は、配置上のコレクションの合計数が
100,000以上である配置のバックアップは 行いません 。MongoDB Ops Managerは、インデックス コレクション オプションを複製しません。
暗号化
MongoDB Ops Managerは任意のバックアップジョブを暗号化できます。 ヘッドデータベース の代わりに バックアップカーソル を使用してバックアップジョブを暗号化します。詳細については、「バックアップデーモンサービス 」を参照してください。
バックアップに関する考慮事項
整合性とスナップショット
MongoDB Ops Managerは、 collStats と によって報告されるサイズ統計を除き、スナップショットを取得するときに 因果整合性db.[collection].count() を維持します。collStatsおよびdb.[collection].count()によって報告されるサイズ統計が不正確になる可能性があります。 MongoDB Ops Managerは、シャーディングされたクラスターのすべてのシャードにわたって時間を調整します。 これにより、スケジュールされたスナップショット時点ですべてのシャードとノードに書き込まれたすべてのドキュメントがスナップショットに含まれるようになります。
現在サポートされているバックアップ機能
機能 | FCV 4.2 以降を実行しているデータベース | FCV 4.0 以前を実行しているデータベース |
|---|---|---|
WiredTiger スナップショットを使用したデータのバックアップ | ||
バックアップデーモンを使用したデータのバックアップ | ||
レプリカセットのバックアップ | ||
シャーディングされたクラスターのバックアップ | ||
名前空間を使用してフィルタリングが可能になりました [3 ] | ||
同期ソース データベースを指定可能 | ||
特定の時点にデータを復元可能 [4 ] | ||
増分バックアップを実行可能 [5 ] | ||
KMIP 暗号化を使用するスナップショットをサポートするようになりました [6 ] | ||
ローカルキー暗号化 を使用するスナップショットをサポートする [7 ] | ||
ブロックストア スナップショット ストレージへの保存をサポートします | ||
S3 互換ストレージ スナップショット ストレージへの保存をサポートします | ||
ファイル システム ストレージへの保存をサポートするようになりました [8 ] | ||
MongoDB Enterprise を実行しているデータベースをサポート | ||
MongoDB Community を実行しているデータベースをサポート | ||
| [2] | 名前空間フィルタリングは、 MongoDB Ops Managerバージョン 6.0.8 以降でのみサポートされています。 MongoDB 配置には、 4.0以前または6.0.1以降のfeatureCompatibilityVersion値が必要です。 |
| [3] | PIT復元を実行するにはMongoDB Ops Manager 4.2.13 以降が必要です。 |
| [4] | MongoDB Ops Managerでは、スナップショットが削除された後、およびブロックストア ブロック サイズが変更された場合は、最初のバックアップに完全なバックアップが必要です。 増分バックアップにより、ネットワーク転送とストレージのコストが削減されます。この機能は以下と連携します。
|
| [ 5 ] | 暗号化されたスナップショットをクエリするには、 MongoDB Enterprise 4.2.9以降、または4.4.0以降が必要です。 |
| [ 6 ] | FCV 4.2以降のバックアップは、ローカルキーの暗号化をサポートしていません。 |
| [ 7 ] | FCV 4.2以降のデータベースから ファイルシステム ストアへのバックアップでは、 File System Store Gzip Compression Levelは無視されます。 |
要件と制限事項
MongoDB 4.2以降をFCV 4.2以降で実行している場合にバックアップと復元を実行するには、次の操作を実行します。
ブロックストア ブロック サイズの変更を考慮する必要があります。 ブロック サイズを設定せず、デフォルトを使用した場合、そのブロック サイズは 64 KB から 1 MB に変更されます。 これはストレージの使用に影響を与える可能性があります。
レプリカセット構成内のホスト名が MongoDB Agent が使用するホスト名と一致していること、またはホスト マッピングに正しいホスト名が含まれていることを確認する必要があります。 rs.conf()を使用してレプリカセットの構成を確認できます。
MongoDB 6.0以降を実行している場合にのみ、 名前空間フィルター リスト を使用してバックアップに含まれる名前空間を定義できます。 MongoDB 4.2から5.0のバージョンで取得されたスナップショットには、常にすべての名前空間が含まれます。
同期ソース データベースは必要ありません。 スナップショットを作成する際、 MongoDB Ops Managerはパフォーマンスへの影響が最も少なく、スナップショットデータのストレージレベルの重複が最も大きいレプリカセットのメンバーを選択します。
クラスター内のすべての
mongodノードを使用して MongoDB Agent を配置する必要があります。
注意
MongoDB Ops Managerがクラスターを管理しない場合、次のようになります。
backupclusterAdminバックアップを実行する MongoDB ユーザーに } ロールと ロールを 付与 します。MongoDB Agent を実行するオペレーティング システム ユーザーが、配置のすべてのデータファイル（ジャーナル ファイルを含む）に対する読み取り権限があることを確認します。
共有ファイル システム
または HTTPSHTTP ロード MongoDB Ops Managerバランサーの背後で複数のMongoDB Ops Manager アプリケーション サーバーを使用し、 ファイルシステムのスナップショット を使用するように を構成すると、 FCV4 .2 以降のバックアップ スナップショット ジョブは 1 つ以上のサーバーで並行して実行されます。各MongoDB Ops Managerサーバーに共有ファイル システムがマウントされていることを確認します。 MongoDB Ops Managerアプリケーション サーバーでは、同じファイルの異なるオフセットを開いて書き込む場合があります。 共有ファイル システムでこれが許可されていることを確認します。 付けない場合、アクセス エラーが発生します。
期限切れのスナップショットのガベージ コレクション
MongoDB Ops Managerは グルーム ジョブ を使用して期限切れのスナップショットを管理します。 これらのグルーム ジョブは、スナップショットが含まれるスナップショット ストアに応じて異なる動作をします。
スナップショットストア | グルーミング ジョブの仕組み |
|---|---|
MongoDB ブロックストア | 各ジョブのライブ ブロックの量まで追加のディスク領域を使用します。 |
ファイルシステム スナップショットの保存 | 期限切れのスナップショットを削除します |
S3 スナップショット保存 | グルーム ジョブの実行中にMongoDB Ops Managerがスナップショットを作成する場合、追加のディスク領域を使用する可能性があります。 MongoDB Ops Managerは、S3 スナップショット ストアで同時グルーム ジョブを実行できます。 |
注意
スナップショット ジョブとグルーム ジョブは同時に実行することはできません。 スナップショット ジョブの実行中にグルーム ジョブを開始すると、グルーム ジョブは失敗し、 MongoDB Ops Managerはエラーをログに記録し、スナップショット ジョブが完了するとグルーム ジョブを自動的に再試行します。 グルーム ジョブの実行中にスナップショット ジョブを開始すると、スナップショット ジョブは失敗し、 MongoDB Ops Managerはエラーをログに記録し、グルーム ジョブが完了した後にスナップショット ジョブを再試行します。
グルーミング ジョブの詳細については、「グルーミング ジョブ 」を参照してください。
名前空間フィルター
名前空間フィルターを使用すると、バックアップするデータベースとコレクションを指定できます。 名前空間フィルタは、 adminとlocalを除く任意のデータベースと、 systemで開始されていないコレクションに適用できます。
You create either a Blacklist of those to exclude or a Whitelist of those to include. バックアップを開始するときに選択を行い、後で必要に応じて編集できます。 フィルターを変更してバックアップにデータを追加する場合は、 再同期 が必要になります。
ホワイトリストを使用して、ログ データ、キャッシュ、またはその他のエフェメラル データを含むコレクションのバックアップを防止します。 このようなデータベースとコレクションを除外すると、バックアップ時間とコストを削減できます。 バックアップするすべての名前空間を意図的にオプトインする必要があるため、ホワイトリストをホワイトリストとして使用するよりもブラックリストを使用する方が適しています。
注意
名前空間フィルタリングは、MongoDB Ops Manager バージョン6.0.8以降でのみサポートされています。 MongoDB 配置には、 4.0以前または6.0.1以降のfeatureCompatibilityVersion値が必要です。
ストレージ エンジン
MongoDB クラスターをバックアップするには、 WiredTiger storage engineストレージ エンジン を使用します。
現在のバッキング データベースで MMAPv1 を使用している場合は、WiredTiger にアップグレードします。
WiredTigerを使用すると、 MongoDB Ops Managerはバックアップを 100,000 未満の配置に制限します。 ファイルには、コレクションとインデックスが含まれます。
MongoDB 4.2は MMAPv 1ストレージを削除します。 ストレージ エンジンの詳細については、MongoDB マニュアルの「ストレージ」を参照してください。
本番環境の配置の再同期
本番環境では、バックアップされたすべてのレプリカセットを 1 年ごとなど定期的に再同期します。 再同期すると、各レプリカセット内の セカンダリ からデータが読み取られます。 再同期中は、新しいスナップショットは生成されません。
次の場合は、バックアップを再同期することをお勧めします。
データのサイズを小さくすると、 MongoDB Ops Managerのディスク上のデータのコピーのサイズも小さくなります。
TTL インデックスを作成し、ドキュメントを定期的に削除します。
コレクションを削除します（MMAPv 1のみ）。
シャーディングされたクラスターを実行し、特定のシャードからチャンクを移動します。
MongoDB Ops Managerが新しいストレージエンジン形式でスナップショットを提供する場合は、ストレージエンジンを切り替えます。
エージェントが に接続できない場合のスナップショット mongod
シャーディングされたクラスターの場合、バックアップがmongodプロセス（シャードでもコンフィギュレーションサーバーでも）に到達できない場合、エージェントは同期oplogトークンを挿入できません。 このような場合、 MongoDB Ops Managerはスナップショットを作成せず、警告メッセージを表示します。
リージョナルバックアップに関する考慮事項
リージョンバックアップを有効にするには、次の少なくとも 1 つを、レプリカセットまたはシャードが対象とする配置リージョンに関連付ける必要があります。
さらに、次の各項目のそれぞれ 1 つを配置リージョンに関連付ける必要があります。
同期ストア（
mms.backup.noSyncStateをtrueに設定した場合を除く）
シャーディングされたクラスターのリージョンバックアップを有効にした後にシャードを追加する場合、既存のシャードのバックアップジョブを続行するには、新しいシャードに 配置リージョン を割り当て、 必要があります 。 新しいシャードに配置リージョンを割り当てるまで、シャーディングされたクラスターのバックアップ ジョブ全体はMisconfigured状態になり、新しいスナップショットは生成されません。 Misconfigured状態のシャーディングされたクラスターは、引き続き oplog エントリを生成します。