バックアップの準備
クラスターまたはレプリカセットをバックアップする前に、データをバックアップする方法とバックアップするデータを決定します。 このページでは、バックアップを開始する前に考慮する必要がある項目について説明します。
警告
MongoDB Ops Managerでは、ローカルキー暗号化を使用するデータベース配置からのクラスター スナップショットの作成をサポートしなくなりました。 ローカルキーの暗号化でデータベース配置を暗号化すると、スナップショットは失敗します。 スナップショットを暗号化するには、データベース配置で KMIPベースの暗号化を使用します。
バックアップ構成オプション
特定のシステムのバックアップとリカバリの要件は、システムの所有者セットのコスト、パフォーマンス、データ保護の標準を満たすために異なります。
MongoDB Ops Managerのエンタープライズバックアップとリカバリは、それぞれ独自の強度とトレードオフを持つ 5 つのバックアップアーキテクチャをサポートしています。 バックアップ アーキテクチャを構成して配置する前に、配置のデータ保護要件を満たすアーキテクチャを検討してください。
例
要件として、運用コストが低いシステムを検討します。 システムの所有者は、バックアップおよびリカバリ構成のためにストレージに費やできる金額に対して厳格な制限がある場合があります。 その結果、リカバリ時間が長くなる可能性があります。
逆に、リカバリ時間目的が低いシステムも検討してください。 リカバリ要件を満たすバックアップおよびリカバリ構成になる場合、システムの所有者はストレージ コストを許容します。
MongoDB Ops Managerのエンタープライズバックアップとリカバリは、次のバックアップアーキテクチャをサポートします。
高可用性、圧縮、 重複除外 など、ファイルシステム バックアップ用の高度な機能を備えた SAN 上のファイル システム
1 つ以上のANAデバイス上のファイル システム
高可用性構成の MongoDB ブロックストア
スタンドアロン構成の MongoDB ブロックストア
重要
独自のデータ保護アプローチを開発するためのガイダンスとして、バックアップ アーキテクチャの推奨事項を提供します。 推奨事項は、各シナリオまたは配置をカバーしたり表現したりするものではありません。
バックアップ方法の機能
バックアップ システムの機能 | SAN上のファイル システム | las上のファイル システム | Amazon Web Services S3 ブロックストア | MongoDB HA Blockstore | MongoDB ブロックストア |
|---|---|---|---|---|---|
スナップショットのタイプ | 完了 * | 完了 * | 多くの部分的な | 多くの部分的な | 多くの部分的な |
バックアップデータの重複除外 | SAN が をサポートする場合、 | No | はい | はい | はい |
バックアップ データ圧縮 | はい | No | はい | はい | はい |
バックアップ データのレプリケーション | SAN が をサポートする場合、 | No | No | はい | No |
バックアップ ストレージのコスト | より高い | 平均 | 低 | より高い | 低 |
バックアップを管理するための従業員時間 | 平均 | 平均 | 低 | より高い | 平均 |
バックアップRTO | 低 | 平均 | 低 | 低 | 平均 |
* ファイルシステムストア への増分バックアップを実行するために、 MongoDB Agent はバックアップに指定されたパス内の各ストレージエンジンファイルをデータのブロックにスライスし、変更されたブロックのみを Ops Manager に転送します。 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 時間以上かかります。 [1]
これにはディスクの読み取りおよび書込み速度は考慮されません。これは、単一またはミラーリングされた NVMe ストレージ デバイスで最大 3 Gbps の読み取りと 1 Gbps の書込みを超える可能性があります。
連続する各増分バックアップを完了するのに必要な時間は、書込み負荷によって異なります。
このデータベースを 4 つのシャードにシャードすると、各シャードはバックアップを個別に実行します。 これにより、バックアップが完了するまでの時間は 8 時間未満になります。
| [1] | これらのスループット値は、 ネットワーク スループット 計算子を使用して計算 されました および は、追加のネットワーク圧縮がないことを前提としています。 |
スナップショット頻度と保持ポリシー
デフォルトでは、 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 EnterpriseFCV3 44.0WiredTiger から . の間に実行している ヘッドデータベース に保存されているバックアップ ジョブを暗号化できます。
FCV 4.2 以降では、 ヘッドデータベース の代わりに バックアップカーソル を使用します。詳細については、「バックアップデーモン サービス 」を参照してください。
バックアップに関する考慮事項
整合性とスナップショット
MongoDB バージョン 4.2 以降を実行しているクラスターの場合:
MongoDB Ops Managerは、 collStats と によって報告されるサイズ統計を除き、スナップショットを取得するときに 因果整合性
db.[collection].count()を維持します。collStatsおよびdb.[collection].count()によって報告されるサイズ統計が不正確になる可能性があります。MongoDB Ops Managerは、シャーディングされたクラスターのすべてのシャードにわたって時間を調整します。 これにより、スケジュールされたスナップショット時点ですべてのシャードとノードに書き込まれたすべてのドキュメントがスナップショットに含まれるようになります。
MongoDB バージョン 4.0 以前を実行しているクラスターの場合:
MongoDB Ops Managerはクラッシュに対応したスナップショットを維持します。
MongoDB Ops Managerは、シャーディングされたクラスターとコンフィギュレーションサーバーのレプリカセットの各シャードからほぼ同時にスナップショットを取得します。
FCV 4.2 以降を実行しているデータベース
重要
データベースでMongoDB FCV4.2 以前が実行されている場合は、シャーディングされたクラスターとレプリカセットのみがバックアップできる配置タイプです。 MongoDB FCV またはそれ以前のバージョンを実行中しているスタンドアロンのmongodプロセスをバックアップするには、4.2 シングルノードのレプリカセットに変換する 必要があります。
現在サポートされているバックアップ機能
機能 | FCV 4.2 以降を実行しているデータベース | FCV 4.0 以前を実行しているデータベース |
|---|---|---|
WiredTiger スナップショットを使用したデータのバックアップ | ||
バックアップデーモンを使用したデータのバックアップ | ||
レプリカセットのバックアップ | ||
シャーディングされたクラスターのバックアップ | ||
名前空間を使用してフィルタリングが可能になりました [2 ] | ||
同期ソース データベースを指定可能 | ||
特定の時点にデータを復元可能 [3 ] | ||
増分バックアップを実行可能 [4 ] | ||
KMIP 暗号化を使用するスナップショットをサポートするようになりました [5 ] | ||
ローカルキー暗号化 を使用するスナップショットをサポートする [6 ] | ||
ブロックストア スナップショット ストレージへの保存をサポートします | ||
S3 互換ストレージ スナップショット ストレージへの保存をサポートします | ||
ファイル システム ストレージへの保存をサポートするようになりました [7 ] | ||
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アプリケーション サーバーでは、同じファイルの異なるオフセットを開いて書き込む場合があります。 共有ファイル システムでこれが許可されていることを確認します。 付けない場合、アクセス エラーが発生します。
FCV 4.0 以前を実行しているデータベース
重要
データベースでMongoDB FCV4.2 以前が実行されている場合は、シャーディングされたクラスターとレプリカセットのみがバックアップできる配置タイプです。 MongoDB FCV またはそれ以前のバージョンを実行中しているスタンドアロンのmongodプロセスをバックアップするには、4.2 シングルノードのレプリカセットに変換する 必要があります。
次の考慮事項は、データベースが MongoDB 4.0 またはそれ以前のバージョンを実行している場合、または MongoDB 4.2 を実行している場合に適用されます。
"featureCompatibilityVersion" : 4.0
期限切れのスナップショットのガベージ コレクション
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が新しいストレージエンジン形式でスナップショットを提供する場合は、ストレージエンジンを切り替えます。
チェックポイント
重要
4.0またはそれ以前の機能の互換性バージョンで MongoDB を実行するクラスターのチェックポイントを使用できます。 FCVが4.2以降の MongoDB インスタンスからチェックポイントが削除されました。
シャーディングされたクラスターの場合、 チェックポイント はスナップショット間の追加の復元ポイントを提供します。 チェックポイントを有効にすると、 MongoDB Ops Managerは、スナップショット間の15、30、または 60 分ごとに、構成可能な間隔で復元ポイントを作成します。 チェックポイントを有効にするには、「 チェックポイントの有効化 」を参照してください。
チェックポイントを作成するために、MongoDB Ops Manager は バランサー を停止し、クラスター内の各 シャードoplog とコンフィギュレーション サーバー の にトークンを挿入します。これらのチェックポイント トークンは軽量で、パフォーマンスやディスク使用量に影響を与えません。
バックアップにはチェックポイントは必要なく、デフォルトで無効になっています。
チェックポイントから復元するには、 MongoDB Ops Managerがチェックポイントの前にキャプチャされた最後のスナップショットに各シャードとコンフィギュレーションサーバーのoplogを適用する必要があります。 チェックポイントからの復元は、スナップショットからの復元よりも時間がかかります。
エージェントがバランサーを停止できない場合のスナップショット
FCV 4.0 またはそれ以前のバージョンで実行されているシャーディングされたクラスターの場合、 MongoDB Ops Managerはクラスター スナップショットを取得する前にバランサーを無効にします。 長時間の移行やmongosが実行されていない場合など、特定の状況では、 MongoDB Ops Managerはバランサーを無効にしようとしますが、失敗します。 このような場合、 MongoDB Ops Managerは引き続きクラスター スナップショットを取得し続けますが、データが不完全または不整合な状態である可能性のあるスナップショットにフラグを付けます。 アクティブなバランシング操作中に取得されたクラスター スナップショットでは、データが失われる、またはデータが孤立している間に取得されたクラスター スナップショットのリスクがあります。
エージェントが に接続できない場合のスナップショット mongod
シャーディングされたクラスターの場合、バックアップがmongodプロセス（シャードでもコンフィギュレーションサーバーでも）に到達できない場合、エージェントは同期oplogトークンを挿入できません。 このような場合、 MongoDB Ops Managerはスナップショットを作成せず、警告メッセージを表示します。