Docs Menu
Docs Home
/ /

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

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

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

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

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

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

クラウドバックアップ

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

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

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

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

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

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

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

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

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

バックアップ戦略は、特にクリティカルなアプリケーションやほぼゼロに近いダウンタイムが要求されるケースにおいて、ビジネス継続性要件を満たすために、明確なリカバリポイント目的(RPO)とリカバリ時間目的(RTO)を定義する必要があります。RPO は、障害や中断が発生した際に許容可能な最大データ損失量を定義します。一方、RTO は、クラスターやサービスが復旧するまでに要する最大時間を定義します。アプリケーションの重要度に基づいて、RPORTO の基準を計算しなければなりません。例えば、ミッションクリティカルなデータは通常、クリックストリーム分析よりも低い RPO を必要とします。

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

Tip

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

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

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

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

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

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

次のコマンドを実行して、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

次の例は、デプロイメント中にバックアップを設定する方法を示しています。Terraform でリソースを作成する前に、次の手順を実行する必要があります。

の例ごとに次のファイルを作成する必要があります。各例のファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。次に、コマンドを実行して Terraform を初期化し、Terraform プランを表示して変更を適用します。

variable "org_id" {
description = "Atlas organization ID"
type = string
}
variable "project_name" {
description = "Atlas project name"
type = string
}
variable "cluster_name" {
description = "Atlas Cluster Name"
type = string
}
variable "point_in_time_utc_seconds" {
description = "PIT in UTC"
default = 0
type = number
}

以下を使用して、次のスナップショット頻度と保存期間でクラスターのバックアップ スケジュールを構成してください。

  • 毎時: 12 時間ごとに、7 日間保持

  • 毎日: 1 日 1 回、7 日間保持

  • 毎週: 土曜日、4 週間保持

  • 毎月: 月の最終日、3 か月間保持

locals {
atlas_clusters = {
"cluster_1" = { name = "m10-aws-1e", region = "US_EAST_1" },
"cluster_2" = { name = "m10-aws-2e", region = "US_EAST_2" },
}
}
resource "mongodbatlas_project" "atlas-project" {
org_id = var.org_id
name = var.project_name
}
resource "mongodbatlas_advanced_cluster" "automated_backup_test_cluster" {
for_each = local.atlas_clusters
project_id = mongodbatlas_project.atlas-project.id
name = each.value.name
cluster_type = "REPLICASET"
replication_specs {
region_configs {
electable_specs {
instance_size = "M10"
node_count = 3
}
analytics_specs {
instance_size = "M10"
node_count = 1
}
provider_name = "AWS"
region_name = each.value.region
priority = 7
}
}
backup_enabled = true # enable cloud backup snapshots
pit_enabled = true
}
resource "mongodbatlas_cloud_backup_schedule" "test" {
for_each = local.atlas_clusters
project_id = mongodbatlas_project.atlas-project.id
cluster_name = mongodbatlas_advanced_cluster.automated_backup_test_cluster[each.key].name
reference_hour_of_day = 3 # backup start hour in UTC
reference_minute_of_hour = 45 # backup start minute in UTC
restore_window_days = 7 # Restore window for near-zero RPO
copy_settings {
cloud_provider = "AWS"
frequencies = ["HOURLY",
"DAILY",
"WEEKLY",
"MONTHLY",
"YEARLY",
"ON_DEMAND"]
region_name = "US_WEST_1"
zone_id = mongodbatlas_advanced_cluster.automated_backup_test_cluster[each.key].replication_specs.*.zone_id[0]
should_copy_oplogs = true
}
policy_item_hourly {
frequency_interval = 12 # backup every 12 hours, accepted values = 1, 2, 4, 6, 8, 12 -> every n hours
retention_unit = "days"
retention_value = 7 # retain for 7 days
}
policy_item_daily {
frequency_interval = 1 # backup every day, accepted values = 1 -> every 1 day
retention_unit = "days"
retention_value = 7 # retain for 7 days
}
policy_item_weekly {
frequency_interval = 7 # every Sunday, accepted values = 1 to 7 -> every 1=Monday,2=Tuesday,3=Wednesday,4=Thursday,5=Friday,6=Saturday,7=Sunday day of the week
retention_unit = "weeks"
retention_value = 4 # retain for 4 weeks
}
policy_item_monthly {
frequency_interval = 28 # accepted values = 1 to 28 -> 1 to 28 every nth day of the month
retention_unit = "months"
retention_value = 3 # retain for 3 months
}
depends_on = [
mongodbatlas_advanced_cluster.automated_backup_test_cluster
]
}

次の手順を使用して、クラウド バックアップ スナップショットと PIT 復元ジョブを構成します。

# Create a project
resource "mongodbatlas_project" "project_test" {
name = var.project_name
org_id = var.org_id
}
# Create a cluster with 3 nodes
resource "mongodbatlas_advanced_cluster" "cluster_test" {
project_id = mongodbatlas_project.project_test.id
name = var.cluster_name
cluster_type = "REPLICASET"
backup_enabled = true # enable cloud provider snapshots
pit_enabled = true
retain_backups_enabled = true # keep the backup snapshopts once the cluster is deleted
replication_specs {
region_configs {
priority = 7
provider_name = "AWS"
region_name = "US_EAST_1"
electable_specs {
instance_size = "M10"
node_count = 3
}
}
}
}
# Specify number of days to retain backup snapshots
resource "mongodbatlas_cloud_backup_snapshot" "test" {
project_id = mongodbatlas_advanced_cluster.cluster_test.project_id
cluster_name = mongodbatlas_advanced_cluster.cluster_test.name
description = "My description"
retention_in_days = "1"
}
# Specify the snapshot ID to use to restore
resource "mongodbatlas_cloud_backup_snapshot_restore_job" "test" {
count = (var.point_in_time_utc_seconds == 0 ? 0 : 1)
project_id = mongodbatlas_cloud_backup_snapshot.test.project_id
cluster_name = mongodbatlas_cloud_backup_snapshot.test.cluster_name
snapshot_id = mongodbatlas_cloud_backup_snapshot.test.id
delivery_type_config {
point_in_time = true
target_cluster_name = mongodbatlas_advanced_cluster.cluster_test.name
target_project_id = mongodbatlas_advanced_cluster.cluster_test.project_id
point_in_time_utc_seconds = var.point_in_time_utc_seconds
}
}

戻る

回復力

項目一覧