ファイルシステムのスナップショットを使用した自己管理型配置のバックアップと復元
項目一覧
このドキュメントでは、 LVMやストレージ アプライアンスなどのシステムレベルのツールを使用して MongoDB スタンドアロン サーバーとレプリカセットのバックアップを作成する手順と、それに対応する復元戦略について説明します。 シャーディングされたクラスターの詳細については、「ファイルシステム スナップショットを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。
これらのファイルシステムのスナップショット、または「ブロックレベル」バックアップ方法では、システムレベルのツールを使って MongoDB のデータファイルを保持するデバイスのコピーを作成します。これらのメソッドはすぐに完了し、確実に機能しますが、MongoDB 外で追加のシステム設定を行う必要があります。
スナップショットの概要
スナップショットは、ライブデータと特別なスナップショットのボリューム間にポインターを作成することで機能します。これらのポインターは理論的には「ハードリンク」と同じです。作業データがスナップショットと異なる場合、スナップショット加工ではコピーオンライト戦略が使用されます。その結果、スナップショットには変更されたデータのみがストアされます。
スナップショットを作成したら、スナップショット画像をファイルシステムにマウントし、スナップショットからデータをコピーします。結果として得られるバックアップには、すべてのデータの完全なコピーが含まれます。
Considerations
WiredTiger ストレージ エンジン
MongoDB では、MongoDB インスタンスのデータファイルとジャーナルファイルが別々のボリュームに存在する場合に、WiredTiger ストレージエンジンを使用して MongoDB インスタンスのボリュームレベルのバックアップをサポートしています。ただし、一貫性のあるバックアップを作成するには、データベースをロックし、バックアップ プロセス中にデータベースへのすべての書き込みを一時停止する必要があります。
暗号化ストレージエンジン（MongoDB Enterprise のみ）
AES256-GCM 暗号化モードを使用して暗号化されたストレージ エンジンの場合、AES256-GCM はすべてのプロセスについて、キーとユニークなカウンター ブロック値を使用することを求めます。
AES256-GCM 暗号で構成されたストレージ エンジンの場合:
- ホット バックアップからの復元
- バージョン 4.2 以降、「ホット」バックアップ（
mongodが実行されている状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出し、データベース キーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避できるようになりました。
- コールド バックアップからの復元
ただし、「コールド」バックアップ（
mongodが実行されていない状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出できず、IV を再利用すると、機密性と整合性における保証が無効になります。バージョン 4.2 以降では、コールド ファイルシステム スナップショットから復元した後にキーが再利用されるのを回避するため、MongoDB に新しいコマンド ライン オプション
--eseDatabaseKeyRolloverが追加されました。--eseDatabaseKeyRolloverオプションを使用して起動すると、mongodインスタンスはAES256-GCM暗号で構成されたデータベース キーをロールオーバーして終了します。
スナップショットの時点で有効なデータベース
スナップショットを実行するときは、データベースが有効である必要があります。つまり、データベースが受け入れるすべての書き込みは、ジャーナルまたはデータファイルのいずれかのディスクに完全に書き込まれる必要があります。
バックアップの実行時にディスク上に存在しない書き込みがある場合、バックアップではこれらの変更は反映されません。
WiredTiger ストレージエンジンの場合、データファイルは最後のチェックポイント時点での一貫した状態を反映します。チェックポイントは 2 GB のデータごとに、または 1 分ごとに発生します。
ディスク全体のイメージ
スナップショットはディスクイメージ全体のイメージを作成します。システム全体をバックアップする必要がなければ、MongoDB のデータファイル、ジャーナル（該当する場合）、設定を他のデータを含まない 1 つの論理ディスクに分離することを検討してください。
あるいは、すべての MongoDB データファイルを専用のデバイスにストアして、余計なデータを重複させずにバックアップを取れるようにします。
サイト障害予防策
スナップショットから他のシステムにデータをコピーするようにします。これにより、サイト障害からデータを保護できます。
増分バックアップなし
このチュートリアルには、増分バックアップの手順は含まれていません。スナップショットの方法が異なれば、提供される機能も異なりますが、以下で説明する LVM の方法では、増分バックアップをキャプチャするためのキャパシティーは提供されません。
ジャーナリングを使用したスナップショット
mongod インスタンスでジャーナリングが有効になっている場合は、任意の種類のファイルシステムまたはボリュームやブロックレベルでのスナップショットツールを使用してバックアップを作成できます。
Linux ベースのシステムで独自のインフラストラクチャを管理する場合は、ディスクパッケージを提供し、スナップショット機能を提供するように LVM を使用してシステムを構成します。また、クラウド環境や仮想化環境内で LVM ベースの設定を使用することもできます。
注意
LVM を実行すると柔軟性が高まり、スナップショットを使用して MongoDB をバックアップできるようになります。
RAID 10 構成の Amazon EBS を使用したスナップショット
インスタンス内で RAID が構成された Amazon の EBS（Elastic Block Storage）上での配置に依存している場合、プラットフォームのスナップショットツールを使用してすべてのディスクで一貫性のある状態を取得することは不可能です。別の方法として、次のいずれかを実行することができます。
ディスクへのすべての書き込みをフラッシュし、書込みロック (write lock) を作成して、バックアップ処理中の状態の一貫性を確保します。
このオプションを選択する場合は、「 ジャーナルファイルを含むインスタンスの別のボリュームへのバックアップ、またはジャーナリングなしでのインスタンスのバックアップ」を参照してください。
システム内の RAID の一番上で MongoDB データファイルを実行し、保持するように LVM を構成します。
このオプションを選択した場合は、「 スナップショットの作成 」で説明されている LVM バックアップ操作を実行します。
Linux での LVM を使用したバックアップと復元
このセクションでは、Linux システムで LVM を使用しての簡単なバックアップ処理の概要を説明します。ツール、コマンド、パスはシステムによって（若干）異なる場合がありますが、次の手順ではバックアップ操作の概要を説明します。
注意
以下の手順は、バックアップシステムとインフラのガイドラインとしてのみ使用してください。本番環境のバックアップシステムでは、アプリケーション固有の要件数や特定の環境に固有の要素を考慮する必要があります。
シャーディングされたクラスターの詳細については、「ファイルシステム スナップショットを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。
スナップショットの作成
WiredTiger を使った MongoDB インスタンスのボリュームレベルのバックアップでは、データファイルとジャーナルを単一のボリュームに置く必要がなくなりました。
LVM を使用してスナップショットを作成するには、次の形式でルートとしてコマンドを発行します。
lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb
このコマンドは、vg0 ボリュームグループ内の mongodb ボリュームの mdb-snap01 という名前の LVM スナップショット（--snapshot オプションを使用）を作成します。
この例では、/dev/vg0/mdb-snap01 にある mdb-snap01 という名前のスナップショットを作成します。システムのボリュームグループとデバイスのロケーションとパスは、オペレーティングシステムの LVM 構成によって若干異なる場合があります。
パラメーター --size 100M により、スナップショットの上限は 100 メガバイトになります。このサイズはディスク上のデータの総量ではなく、/dev/vg0/mongodb の現在の状態とスナップショットの作成との間の量の差異（/dev/vg0/mdb-snap01 など）を反映しています。
警告
特に、システムからデータをコピーしたり、一時的なイメージにコピーするのにかかる時間を考慮して、データの増加に対応できる十分なスペースのあるスナップショットを作成するように確認します。
スナップショットの容量が不足すると、スナップショットのイメージは使用できなくなります。この論理ボリュームを破棄し、別の論理ボリュームを作成します。
スナップショットは、コマンドが戻ったときに存在します。いつでもスナップショットから直接復元できます。また、新しい論理ボリュームを作成してこのスナップショットから代替イメージを復元することもできます。
スナップショットは高品質のバックアップを素早く作成するのに最適ですが、バックアップデータをストアするための形式としては理想的ではありません。スナップショットは通常、元のディスクイメージと同じストレージインフラストラクチャに依存し、そこに保存されます。したがって、これらのスナップショットをアーカイブして別の場所にストアすることが重要です。
スナップショットのアーカイブ化
スナップショットを作成したら、スナップショットをマウントし、データを別のストレージにコピーします。バックアップイメージをオフラインに移動すると、システムがバックアップイメージを圧縮しようとすることがあります。または、次の手順でスナップショットのイメージをブロックレベルでコピー作成します。
umount /dev/vg0/mdb-snap01 dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz
上記のコマンドシーケンスでは、以下のことを行います。
/dev/vg0/mdb-snap01デバイスがマウントされていないことを確認します。マウントされているファイルシステムまたはファイルシステムのスナップショットのブロックレベルのコピーは絶対に作成しないでください。ddコマンドを使用してスナップショットイメージ全体のブロックレベルのコピーを実行し、その結果を現在の作業ディレクトリ内の gzip ファイルに圧縮します。警告
このコマンドは、現在の作業ディレクトリに大容量の
gzファイルを作成します。十分な空き容量があるファイルシステムでこのコマンドを実行するようにします。
スナップショットの復元
LVM で作成されたスナップショットを復元するには、以下の一連のコマンドを実行します。
lvcreate --size 1G --name mdb-new vg0 gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
上記のシーケンスでは、次の処理が行われます。
/dev/vg0ボリュームグループにmdb-newという名前の新しい論理ボリュームを作成します。新しいデバイスへのパスは、/dev/vg0/mdb-newになります。警告
このボリュームの最大サイズは 1 ギガバイトです。元のファイルシステムの合計サイズが 1 ギガバイト以下でなければ、復元は失敗します。
1Gを希望のボリュームサイズに変更します。mdb-snap01.gzを圧縮解除してアーカイブ解除し、mdb-newディスクイメージに展開します。mdb-newディスクイメージを/srv/mongodbディレクトリにマウントします。MongoDB データファイルのロケーションに対応するようにマウントポイントを変更するか、必要に応じて他のロケーションに変更します。
注意
復元されたスナップショットには古い mongod.lock ファイルが含まれます。このファイルをスナップショットから除かないと、MongoDB は古いロックファイルが問題のあるシャットダウンを示していると見なす可能性があります。db.fsyncLock() を使用する場合は、mongod.lock ファイルを除く必要があります。
スナップショットから直接復元
圧縮された gz ファイルに書き込まずにバックアップを復元するには、次の一連のコマンドを使用します。
umount /dev/vg0/mdb-snap01 lvcreate --size 1G --name mdb-new vg0 dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
注意
すべての MongoDB コレクションには、デフォルトで UUIDが付属します。MongoDB がコレクションを復元する場合、復元されたコレクションは元の UUID を保持します。UUID がないコレクションを復元する場合、MongoDB は復元されたコレクションのために UUID を生成します。
コレクション UUID について詳しくは、「コレクション」を参照してください。
リモートバックアップでのストレージ
プロセスと SSH を組み合わせて使用し、オフシステムバックアップを実装できます。
このシーケンスは、SSH を使用してリモートシステムにバックアップをアーカイブし圧縮することを除いて、上で説明した手順とまったく同じです。
次の手順について考えてみます。
umount /dev/vg0/mdb-snap01 dd if=/dev/vg0/mdb-snap01 | ssh username@example.com gzip > /opt/backup/mdb-snap01.gz lvcreate --size 1G --name mdb-new vg0 ssh username@example.com gzip -d -c /opt/backup/mdb-snap01.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
ジャーナルファイルを含むインスタンスの別のボリュームへのバックアップ、またはジャーナリングなしでのインスタンスのバックアップ
WiredTiger を使った MongoDB インスタンスのボリュームレベルのバックアップでは、データファイルとジャーナルを単一のボリュームに置く必要がなくなりました。ただし、バックアップの一貫性を確保するために、バックアップ プロセス中にデータベースをロックし、データベースへのすべての書き込みを中断する必要があります。
mongod インスタンスがジャーナリングなしで実行中であるか、ジャーナルファイルが別のボリュームにある場合は、バックアップ処理中の書き込みを防ぐために、すべての書き込みをディスクにフラッシュし、データベースをロックする必要があります。レプリカセット構成の場合は、バックアップには読み取りを受信していないセカンダリ（つまり非表示ノード）。
ディスクへの書き込みをフラッシュし、データベースをロックしてそれ以上書き込みが行われないようにします。
ディスクへの書込み (write) をフラッシュし、データベースを "ロック" するには、mongosh の db.fsyncLock() メソッドを発行します。
db.fsyncLock();
スナップショットを作成したら、データベースのロックを解除します。
スナップショットを作成した後にデータベースのロックを解除するには、 mongoshで次のコマンドを使用します。
db.fsyncUnlock();