Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/ /
Atlas Architecture Center
/

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

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

  • クラウドバックアップ:クラウドプロバイダーのネイティブ スナップショット機能を使用して、フルコピー スナップショットとローカライズされたスナップショットストレージをサポートします。これらのスナップショットは常に低コストと高速復元を実現するために自然に増分されます。時間単位、毎日、毎週ごと、毎月のスナップショットの頻度と保持期間を指定するバックアップポリシーを選択します。

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

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

Atlas は、ポイントインタイムデータリカバリとシャーディングされたクラスターを含むすべてのクラスターの一貫したクラスター全体のスナップショットを含む、データのフルマネージドバックアップを提供します。 Atlas では、時間ごと、毎日、毎週ごと、毎月、年間の 5 つのスナップショット頻度から選択でき、それぞれの保持期間は独自です。

クラウドバックアップ

この機能は、クラスターのクラウドサービス プロバイダーのネイティブ スナップショット機能を使用して、ローカライズされたバックアップストレージを提供します。メリットとしては、12 か月という強力なデフォルトのバックアップ保持スケジュール、スナップショットと保持スケジュールをカスタマイズする完全な柔軟性、および業界を満たすためにさまざまなスナップショット頻度(リカバリでは 1 時間ごと、長期保持の場合は 毎月)を設定できる能力などです。規則。バックアップデータにはすぐにアクセスできるため、監査、コンプライアンス、またはデータ復旧目的で役立ちます。

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

この機能は、ポイントインタイム(PIT)リカバリを提供するために、クラウドバックアップに対して有効にすることができます。継続的なクラウドバックアップは、スナップショットをクラスターのoplogとともにカスタマイズ可能な ポイントインタイム復元(PITr)ウィンドウまで保存することで機能し、最後のスナップショットに復元して、スナップショットが取得されて以降のすべての操作を再生できます。これにより、 サーバー攻撃 などの障害やデータ損失イベントが発生する直前の正確な時点(特定の点)にデータを回復することができます。

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

この機能を使用すると、バックアップショットと oplog のコピーを、デフォルトのプライマリ リージョンに加えて、地理的リージョン全体に分散することで回復力を高めることができます。この構成は、リージョン停止が発生した場合に障害復旧を確保するために、異なる地理的場所にバックアップを保存するというコンプライアンス要件を満たしています。

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

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

この機能は、Atlas に保存されているすべてのスナップショットと oplog が変更または削除されるのを防ぐことで、ビジネス重要なデータをさらに保護し、バックアップが完全に WORM(ReadMany)に準拠していることを保証します。 MongoDBサポートによる検証プロセスが完了した後に、この保護をオフにすることができます。この機能を無効にするには必須のクールダウン期間があり、攻撃者がバックアップポリシーを変更してデータをエクスポートすることはできません。

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

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

障害シナリオの性質と回復方法は、実行可能な RPO RTO に影響します。 MongoDB のデフォルトの高可用性アーキテクチャは、停止の範囲と選択した配置パラダイムに応じて、一時的なクラウドプロバイダーの停止から回復するための自動フェイルオーバーをサポートしており、停止時の範囲と選択した配置パラダイムに応じて、ほぼゼロの RTO RPO で構成されます。自動フェイルオーバーをサポートする配置構成の詳細については、「 Atlas 高可用性に関する ガイダンス 」を参照してください。データベース全体を破損するコードエラーや、誤ってクラスターを削除するなど、バックアップからの復元 が必要な障害シナリオの場合、配置の RTO RPO は次によって異なります。

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

  • RTO は、バックアップのサイズと 復元操作の効率によって異なります。大規模なレプリカセット(およびシャード)の復元には時間がかかります。復元を高速化するために、Atlas は スナップショット コピーを保存するのと同じプロジェクトとリージョンに基づくクラスターに対して、最適化された直接接続復元を自動的に実行します。使用可能なローカル スナップショットがない場合、またはクラスターが標準の 一般または低 CPUストレージの代わりにNVMeストレージを使用する場合、Atlas はデフォルトでストリーミング復元を遅くします。さらに、 継続的なクラウドバックアップ を有効にする場合、PIT 復元を完了するために、Atlas は最後のスナップショットに復元した後に操作を繰り返す必要があります。スナップショット間の時間が短いほど、繰り返される操作の数も少なくなります。したがって、最適化された復元を優先し、バックアップポリシーでより頻繁なスナップショットを必要とすることで、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 日ごと: 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
}
}

戻る

回復力

項目一覧