AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

Atlas のバックアップに関するガイダンス

MongoDB Atlas は、データの保持と復元を確保するために、フルマネージドでカスタマイズ可能なバックアップを提供します。

  • クラウドバックアップ: クラウドプロバイダーのネイティブスナップショット機能を使用して、フルコピーのスナップショットとローカライズされたスナップショット ストレージをサポートします。これらのスナップショットは常に増分方式であり、低コストかつ迅速な復元を実現します。バックアップ ポリシーを選択し、毎時・毎日・毎週・毎月・毎年といったスナップショットの頻度と保持期間を指定できます。

  • 継続的なクラウド バックアップは、標準のクラウド バックアップを拡張し、ポイントインタイム(PIT)復元を提供することでリカバリを強化します。この追加機能は、クラスタの oplog とともにスナップショットを保存し、スナップショット間のデータ変更を取得します。これにより、障害やイベントが発生する直前の正確な時点(ポイントインタイム)までデータを復元できます。これにより、1 分という低いリカバリポイント目的(RPO)がサポートされます。

開発環境およびテスト環境では、バックアップを有効にすることは推奨されません。ステージング環境および本番環境においては、このページで説明されているバックアップ ポリシーの推奨事項を含む自動配置テンプレートを作成することを推奨します。

注意

MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者のセキュリティと運用の優れ性の詳細な内訳については、共有責任モデルを参照してください。

Atlas は、ポイントインタイムでのデータ復旧および一貫性のあるクラスター全体のスナップショットを含む、データの完全管理型バックアップを提供します。これには、シャーディングされたクラスターも含まれます。Atlas では、毎時・毎日・毎週・毎月・毎年といった5種類のスナップショット頻度から選択でき、それぞれ独自の保持期間を設定できます。

クラウドバックアップ

この機能は、クラスターのクラウド サービス プロバイダーのネイティブ スナップショット機能を使用して、ローカライズされたバックアップ ストレージを提供します。メリットには、12 か月という強力なデフォルト バックアップ保持スケジュール、スナップショットと保持スケジュールをカスタマイズする全面的な柔軟性、そして業界規制を遵守するために、リカバリ用には毎時、長期保持用には毎週または毎月といった、さまざまなスナップショット頻度を設定できる能力が含まれます。バックアップ データに即座にアクセスできるため、監査、コンプライアンス、またはデータ復旧の用途に役立ちます。

継続的なクラウドバックアップ

この機能はクラウドバックアップ上で有効にすると、ポイントインタイム(PIT)リカバリが可能になります。継続的なクラウド バックアップは、クラスタの oplog とともにスナップショットを保存し、カスタマイズ可能なポイントインタイム復元(PITR)ウィンドウまで保持することで機能します。これにより、最新のスナップショットまで復元し、そのスナップショットが取得された時点以降のすべてのオペレーションをリプレイできます。これにより、サイバー攻撃のような障害やデータ損失イベントが発生する直前の正確な時点(ポイントインタイム)までデータを復元できます。。

マルチリージョン スナップショットの分散

この機能により、バックアップ スナップショットや oplog のコピーを地理的リージョン全体に分散配置し、デフォルトのプライマリ リージョンに加えてレジリエンスを向上させることができます。この構成は、異なる地理的ロケーションにバックアップを保存することでコンプライアンス要件を満たし、地域的な停止が発生した場合の障害復旧を確保します。

詳細については、「スナップショットの分散」を参照してください。

バックアップ コンプライアンス ポリシー

この機能はさらに、Atlas に保存されたすべてのスナップショットおよび oplog が変更または削除されることを防止することで、ビジネス クリティカルなデータを保護します。これにより、バックアップが完全に WORM(Write Once Read Many)準拠であることが保証されます。この保護を解除できるのは、MongoDB サポートとの検証プロセスを完了した後に指定された認可ユーザーのみです。この機能を無効化するには必須のクールダウン期間が設けられており、攻撃者がバックアップ ポリシーを変更したり、データをエクスポートしたりすることを防止します。

詳細については、「バックアップ コンプライアンス ポリシーの構成」を参照してください。

ビジネス継続要件を満たすには、特にゼロに近いRPOと迅速なリカバリ時間が重要なアプリケーションの場合、バックアップ戦略を特定のリカバリ点目的(RPO)とリカバリ時間目的(RTO)と整合させる必要があります。RPO は障害または中断中に許容されるデータ損失の最大量を定義し、RTO はクラスターまたはサービスが回復するまでにかかる最大時間を定義します。アプリケーションの 重要度 に基づいて、RPO と RTO の標準を計算する必要があります。例、オペレーション クリティカル データには通常、クリックストリーム分析よりも低い RPO が必要です。

障害シナリオの性質や復旧方法によって、達成可能な RPO と RTO が左右されます。MongoDB のデフォルトの高可用性アーキテクチャは、自動フェイルオーバーをサポートしており、クラウドプロバイダーの一時的な停止時からほぼゼロの RTO と RPO で復旧できます。これは停止時の範囲と選択した配置パラダイムに依存します。自動フェイルオーバーをサポートする配置構成の詳細については、「Atlas 高可用性に関するガイダンス」を参照してください。

バックアップからの復元が必要な障害シナリオとして、データベース全体を破損するコード エラーや誤ってクラスターを削除する場合、配置の RTO と RPO は次の要因に依存します。

  • RPO は、バックアップ ポリシーで定義されたスナップショット間隔に依存します。継続的なクラウドバックアップが無効になっている場合、RPO はスナップショット間の時間に直接対応します。例えば、4 時間ごとにバックアップスナップショットを取得する場合、障害イベントが発生すると最大で 4 時間分のデータが失われる可能性があります。継続的なクラウドバックアップを有効にすると、カスタマイズ可能な PITr ウィンドウ内で PIT 復元を実行し、 RPO を1分以内に保証できます。

  • RTO は、バックアップのサイズと復元操作の効率に依存します。大規模なレプリカセット(およびシャード)は、復元に時間がかかります。復元を高速化するために、Atlas はスナップショットコピーを保存している同じプロジェクトおよびリージョンにあるクラスターに対して、最適化されたダイレクトアタッチ復元を自動的に実行します。

    利用可能なローカルスナップショットがない場合、またはクラスターが標準の General またはLow CPUストレージの代わりに NVMe ストレージを使用している場合、Atlas は低速のストリーミング復元をデフォルトとします。

    さらに、継続的クラウドバックアップを有効にした場合、Atlas はPIT復元を完了するために、最後のスナップショットに復元した後、操作を再実行する必要があります。スナップショット間の時間が短いほど、再生しなければならない操作は少なくなります。したがって、バックアップポリシーで最適化された復元を優先し、より頻繁なスナップショットを要求することで、RTO を短縮することができます。

包括的なバックアップ戦略を確保するために、以下のデフォルトバックアップポリシーを出発点として使用することを推奨します。貴社のデータ保持および障害復旧ニーズに応じて、このポリシーを調整してください。

ポリシー タイプ
階層
継続的なクラウドバックアップ
取得されたスナップショット
保持されたスナップショット

1時間ごと

NVMe

enabled

12時間ごと

7 日間

1時間ごと

non-NVMe

enabled

6時間ごと

7 日間

毎日

すべて

または

毎日

7 日間

毎週

すべて

または

毎週土曜日

4 週間

毎月

すべて

または

月末日

12 か月

毎年

すべて

または

12月1日ごと

1 年

シングルリージョンでの配置における耐障害性をさらに高めるために、Atlas を構成して、プライマリ リージョンからセカンダリ バックアップ リージョンにスナップショットをコピーすることを推奨します。これにより、プライマリ リージョンがダウンした場合でも、以前のバージョンに復元できます。詳細については、「スナップショットの分散」を参照してください。

Atlas のバックアップ コンプライアンス ポリシーを適用することを推奨します。これにより、バックアップの不正な変更や削除を防止し、データ保護と堅牢な障害復旧を確保できます。

継続的なクラウドバックアップにより、正確なポイントインタイム(PIT)リカバリが可能となり、障害時のデータ損失を最小限に抑えることができます。Atlas は、障害イベント発生前の正確なタイムスタンプに迅速に復元でき、少なくとも1分の RPO を保証します。これは、Atlas が希望する時点より前の最新のスナップショットを復元し、その特定の時点に復元するために oplog の変更を再生するためです。リカバリ時間は、クラウドプロバイダーのディスク ウォーミングと、復元中に再生する必要がある oplog の量によって異なる場合があります。復元後にクラウドプロバイダーのディスクウォーミングが完了するまで、クラスターのパフォーマンスが低下する可能性があります。リカバリーの要件に柔軟性がある場合は、合理的なリカバリーオプションとコストの最適な妥協点を特定するテンプレートを設計することをお勧めいたします。

Atlasのバックアップコストを最適化するためには、データの重要度に応じてバックアップの頻度と保持ポリシーを調整し、不必要なストレージ費用を削減することができます。例えば、データ復旧が重要でない開発環境やテストクラスターなどの低環境では、バックアップを無効にすることをお勧めします。上位環境では、バックアップスナップショットをリージョン間で分散させる際に、リージョン間のデータ転送コストと高可用性要件のバランスを取ることを推奨します。

次の例で、Atlas のオートメーションツールを使用したバックアップと復元操作が可能になります。

これらの例は、クラスターのバックアップが有効なステージングおよび本番環境にのみを対象とします。

クラウドクラウドプロバイダーのストレージバケットへのスナップショットのエクスポートや Terraform のバックアップ コンプライアンス ポリシーの構成など、クラスターバックアップを自動化するプラグとプレイのモジュールについては、 クラスター モジュールのバックアップガイドを参照してください。モジュールをNVMeストレージと併用する場合、1 時間あたりのスナップショットfrequency_interval を12 に明示的に設定する必要があります。これは、モジュールがインスタンス階層から 1 時間あたりの間隔を生成しないためです。

次のコマンドを実行して、myDemo という名前のクラスターのバックアップ スナップショットを取得し、7 日間保持します。

atlas backups snapshots create myDemo --desc "my backup snapshot" --retention 7

指定された承認済みユーザー(governance@example.org)を用いてプロジェクトのバックアップコンプライアンスポリシーを有効にします。このユーザーのみが、MongoDB サポートとの検証プロセスを完了した後に、この保護を解除することができます。

atlas backups compliancePolicy enable \ --projectId 67212db237c5766221eb6ad9 \ --authorizedEmail governance@example.org \ --authorizedUserFirstName john \ --authorizedUserLastName doe

次のコマンドを実行して、スケジュールされたバックアップショットのコンプライアンスポリシーを作成し、スナップショットを取得する必要がある回数(6 時間ごととスナップショットを保持する期間(1 月に設定)を強制します。

atlas backups compliancePolicy policies scheduled create \ --projectId 67212db237c5766221eb6ad9 \ --frequencyInterval 6 \ --frequencyType hourly \ --retentionValue 1 \ --retentionUnit months