NetBackup™ for MongoDB 管理者ガイド

NetBackup は、MongoDB クラスタ内のノードを選択して、次の順序でバックアップを作成します。

NetBackup が MongoDB クラスタの特定のバックアップノードを選択するようにする場合は、非表示のノードとして設定します。

バックアップジョブを実行する前に、バックアップホスト上のすべての MongoDB ノードから ping 応答が正常に返されることを確認します。ファイアウォールの設定を確認して更新し、バックアップホストが MongoDB クラスタと通信できるようにします。

保護する MongoDB クラスタで LVM スナップショットを取得できることを確認します。

MongoDB データベースパスのボリュームグループまたは LVM の物理ボリュームと論理ボリュームの名前を変更すると、バックアップが失敗します。LVM のボリュームグループまたは物理ボリュームと論理ボリュームの名前を変更する場合は、バックアップを作成する前に、MongoDB データベースが新しいパスにマウントされていることを確認します。

バックアップは mongos プロセスのバランサーを停止し、他のすべての操作をブロックします。そのため、バックアップ処理中に、mongos プロセスを使用する他の操作を実行しないようにしてください。たとえば、データベースのインポートです。

データベースのパスを変更する場合、mongod または mongos プロセスの設定ファイルを変更する場合、または MongoDB トポロジーを変更する場合は、常に完全バックアップを実行してください。

単一の Netbackup バックアップポリシーに複数の MongoDB クライアントがある場合は、マスターサーバー、メディアサーバーおよびクライアントの クライアント読み込みタイムアウトパラメータを増やして、すべてのバックアップが正常に実行されることを確認します。

詳しくは、『NetBackup™管理者ガイド vol. 1』と タイムアウトプロパティセクション を参照してください。

増分バックアップジョブでは、増分の変更を判断するための参照として、一貫性のあるバックアップイメージを使用します。以前のバックアップが失敗したか、部分的に成功していた場合 (いずれかのノードで障害が発生した場合)、完全にスキップされ、その前に作成されたバックアップイメージが考慮されます。このような場合、バックアップ操作に時間がかかり、作成されたイメージのサイズが大きくなる可能性があります。

oplog ファイルには、上限またはローリングキャッシュがあるため、ファイルのサイズを設定できます。NetBackup は、oplog を使用して増分データをキャプチャします。oplog ロールオーバーによって、増分バックアップが失敗する場合があります。これを防ぐには、増分バックアップの間に生成された増分データを保持するのに十分な oplog ファイルサイズであることを確認します。

tpconfig コマンドを使用して追加したユーザーが、MongoDB クラスタ全体と、mongodb.conf ファイルに指定されているカスタムフォルダパスにアクセスできることを確認します。

MongoDB 4.2 シャードクラスタの場合、機能の互換性のバージョン (FCV) がすべての MongoDB クラスタノードで同じであることを確認します。この手順によって、バックアップ時にデータの一貫性が保たれます。

レプリカセットで oplog の保持機能を使用している場合は、増分バックアップ間のスケジュール設定された時間を oplog の最小保持期間よりも短くする必要があります。これにより、正しい増分バックアップが確実にキャプチャされます。

NetBackup は、機能の互換性のバージョン (FCV) が 4.0 以前に設定されている場合にのみ、MongoDB 4.2 シャードクラスタの増分バックアップをサポートします。MongoDB 4.2 シャードクラスタが FCV 4.2 である場合は、完全バックアップのみがサポートされます。

シャードクラスタ上の MongoDB 4.4 バージョンについては、NetBackup は完全バックアップのみをサポートします。