Docs Menu
Docs Home
/
MongoDB Atlas
/ /

レガシーバックアップ スナップショットからクラスターを復元

項目一覧

  • Considerations
  • 前提条件
  • 手順

重要

レガシーバックアップの廃止

2020 年 3 月 23 日以降、すべての新しいクラスターが使用できるのはクラウドバックアップのみです

5.0 にアップグレードすると、バックアップ システムがレガシーバックアップに設定されている場合、クラウドバックアップにアップグレードされます。このアップグレード後:

  • 既存のレガシーバックアップのスナップショットはすべて引き続き利用できますが、 保持ポリシー に従い、時間の経過とともに期限が切れます。

  • バックアップ ポリシーデフォルト スケジュールにリセットされます。レガシーバックアップでカスタム バックアップ ポリシーを設定していた場合は、 クラウドバックアップに関するドキュメントに記載されている手順に従ってポリシーを再作成する必要があります。

注意

この機能は、 M0 無料クラスター、M2M5 クラスターでは使用できません。使用できない機能の詳細については、「 Atlas M0 (無料クラスター)、M2 、および M5 の制限 を参照してください。

Atlas では、スケジュールされたレガシーバックアップ スナップショットから、またはスナップショット間の選択されたポイントからデータを復元できます。

注意

ある Atlas クラスターから別の Atlas クラスターにデータを復元するには、ソース クラスターとターゲット クラスターを含む Atlas プロジェクトに対してProject Ownerロールが必要です。

  • レプリカセットの場合は、過去 24 時間以内の選択した時点から復元できます。

  • 実行中のシャーディングされたクラスターの場合:

    • FCV4.2 またはそれ以前の場合、過去24 時間以内のスナップショット間のチェックポイントから復元できます。

    • FCV4.2 以降では、過去24 時間以内の選択した時点から復元できます。

スナップショットが取得されたのと同じクラスター、または Atlas または Cloud Manager が管理する他のクラスターにデータを復元できます。

同じメジャーリリース バージョンまたはそれ以降のバージョンで実行中のクラスターに、バックアップを復元する必要があります。Atlas は古いバージョンへの復元をサポートしていません。

アップグレード前に作成されたバックアップは引き続き使用できます。

4.0 クラスターを 4.2 に復元する方法:

  1. 古い 4.0 バックアップを別の 4.2 クラスターに復元します。

  2. 復元されたクラスターを 4.2 にアップグレードします。

クラウドバックアップからデータを復元する手順については、「クラスターの復元 」を参照してください。

復元プロセスには、ターゲット クラスターのダウンタイムが必要です。

MongoDB のバージョンも互換性がある必要があります。 たとえば、5.0 クラスターのスナップショットから 4.2 またはそれ以前のクラスターに復元することはできません。

適切なプロジェクト権限がある場合は、AtlasまたはCloud Manager の別のプロジェクトのクラスターに復元できます。

でのプロジェクトへの復元
移行先プロジェクトで必要なロール

Atlas

Cloud Manager

次のいずれかの Cloud Manager ロール:

  • 組織所有者

  • プロジェクトオーナー

  • プロジェクトバックアップ管理者

復元中に、ターゲット Atlas クラスターがクライアント リクエストを受信しないことを確認する必要があります。 新しいクラスターに復元し、その新しいクラスターを使用するようにアプリケーションを再構成して、最大アップタイムで実行できます。

標準のスナップショットと継続的なクラウドバックアップに加えて、ローカルにダウンロードされたスナップショット ファイルからレガシーバックアップを復元できます。

1
レガシーバックアップ ボタン
2

Legacy BackupページのOverviewタブには、プロジェクト内のクラスタが一覧表示されます。

  • クラスターのバックアップが有効になっている場合、 StatusActiveです。

  • クラスターのバックアップが無効になっている場合、 StatusInactiveです。

クラスターの復元を開始するには、次のいずれかを実行します。

  • クラスターの ステータスにカーソルを合わせ、 をクリックするActiveRestore or Download か、

  • からクラスターの横にある [] メニューでRestore ] を選択します。

3
  1. バックアップを復元するポイントを選択します。

    復元タイプ
    説明
    アクション
    Snapshot
    保存されたスナップショットを 1 つ選択できます。
    復元する既存のスナップショットを選択します。
    Point In Time

    選択した時間までのすべての操作を含むカスタム スナップショットを作成します(選択した時間は含みません)。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。

    たとえば、 12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。

    重要:次の継続的なクラウドバックアップの時間枠の制限を考慮してください。

    • 最新のバックアップ再同期の前の時間をカバーする継続的なクラウドバックアップは実行できません。

    • FCV 4.0またはそれ以前を実行しているシャーディングされたクラスターの場合、シャーディングされたクラスターでPIT復元を実行するには、クラスター チェックポイントを有効にする必要があります。 日付と時刻を含むチェックポイントが利用できない場合、Atlas はchoose another point in timeを要求します。

    • FCV 4.2以降を実行しているシャーディングされたクラスターの場合、oplog の期間内の任意の時点から復元できます。

    DateTimeを選択します。
    Oplog Timestamp

    重要: FCV 4.0またはそれ以前を実行中しているシャーディングされたクラスターではOplog Timestampを選択できません。 FCV 4を実行中しているレプリカセットとシャーディングされたクラスターのバックアップ点目的としてOplog Timestampのみを選択できます。 2 。

    入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプは 2 つのフィールドとして表されます。

    Timestamp
    Increment
    その秒に適用される操作の順序を 32 ビット序数として表します。

    oplog TimestampIncrement を入力します。

    レプリカセットでlocal.oplog.rsに対してクエリを実行し、目的のタイムスタンプを見つけます。

  2. [Next] をクリックします。

最新のoplogエントリの検索

最新のoplogエントリを見つけるには、 mongoshで次のクエリを実行します。

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()
{
"ts": Timestamp(1537559320, 1),
"h": NumberLong("-2447431566377702740"),
"v": 2,
"op": "n",
"ns": "",
"wall": ISODate("2018-09-21T19:48:40.708Z"),
"o": {
"msg": "initiating set"
}
}

ts値の部分は、Timestamp ボックスとIncrement ボックスに必要な値に対応します。

エポック時間を人間が判読できるタイムスタンプに変換するには、 Eポック 変換 のようなツールを使用してみてください MongoDB はこのサービスをサポートしていません。その参照は情報提供のみを目的としています。

4
  1. [Choose Cluster to Restore to] をクリックします。

  2. 次のフィールドを入力します。

    フィールド
    アクション
    Project
    スナップショットを復元するプロジェクトを選択します。
    Cluster to Restore to

    スナップショットを復元するクラスターを選択します。

    Atlas は、ターゲット レプリカセットを管理する必要があります。

    警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットは保持されます。

  1. [Restore] をクリックします。

    Atlas は、復元に必要なストレージ領域の量を示します。

5
6

Atlas はスナップショットを.tar.gzファイルに圧縮します。 このアーカイブには、スナップショットとmongodログが含まれています。

  1. アーカイブ内のファイルを抽出します。

    次のコマンドは、 tarユーティリティを使用してtar``archive with ``gzip圧縮を抽出します。

    tar -xvzf ~/Downloads/mongodb-snapshots/my-cluster-snapshot.tar.gz
  2. データファイルにアクセスするには、ホスト上でmongodインスタンスを起動し、 --dbpathオプションを使用して抽出ディレクトリに差し向けます。 詳細については、「 mongod プロセスの開始 」を参照してください。

    次のコマンドは、抽出したデータファイル ディレクトリを使用してmongodインスタンスを起動します。

    mongod --dbpath ~/Downloads/mongodb-snapshots/my-cluster-snapshot/
1
レガシーバックアップ ボタン
2

Legacy BackupページのOverviewタブには、プロジェクト内のクラスタが一覧表示されます。

  • クラスターのバックアップが有効になっている場合、 StatusActiveです。

  • クラスターのバックアップが無効になっている場合、 StatusInactiveです。

クラスターの復元を開始するには、次のいずれかを実行します。

  • クラスターの ステータスにカーソルを合わせ、 をクリックするActiveRestore or Download か、

  • からクラスターの横にある [] メニューでRestore ] を選択します。

3
4
5

注意

ダウンロード リンクは 1 時間後に期限切れになります。 リンクは複数回使用することはできません。 これらの制限を超えてリンクをクリックすると、 HTTP404 エラー。

6

Atlas はスナップショットを.tar.gzファイルに圧縮します。 このアーカイブには、スナップショットとmongodログが含まれています。

  1. アーカイブ内のファイルを抽出します。

    次のコマンドは、 tarユーティリティを使用してtar``archive with ``gzip圧縮を抽出します。

    tar -xvzf ~/Downloads/mongodb-snapshots/my-cluster-snapshot.tar.gz
  2. データファイルにアクセスするには、ホスト上でmongodインスタンスを起動し、 --dbpathオプションを使用して抽出ディレクトリに差し向けます。 詳細については、「 mongod プロセスの開始 」を参照してください。

    次のコマンドは、抽出したデータファイル ディレクトリを使用してmongodインスタンスを起動します。

    mongod --dbpath ~/Downloads/mongodb-snapshots/my-cluster-snapshot/

戻る

レガシーバックアップ(非推奨)