Skip to main content
BlueXP backup and recovery
すべてのクラウドプロバイダ
  • Amazon Web Services の
  • Google Cloud
  • Microsoft Azure
  • すべてのクラウドプロバイダ
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

BlueXP バックアップおよびリカバリにおけるオブジェクトへのバックアップ ポリシー オプション

共同作成者 amgrissino

BlueXP backup and recoveryを使用すると、オンプレミスのONTAPおよびCloud Volumes ONTAPシステム用のさまざまな設定でバックアップ ポリシーを作成できます。

メモ これらのポリシー設定は、オブジェクトストレージへのバックアップにのみ関連します。これらの設定はいずれもスナップショットまたはレプリケーション ポリシーには影響しません。

注意 BlueXP backup and recoveryのワークロードを切り替えるには、 "さまざまなBlueXP backup and recoveryワークロードに切り替える"

バックアップスケジュールのオプション

BlueXPのバックアップとリカバリでは、作業環境(クラスタ)ごとに一意のスケジュールで複数のバックアップポリシーを作成できます。RPO(目標復旧時点)が異なるボリュームには、異なるバックアップポリシーを割り当てることができます。

各バックアップポリシーには、バックアップファイルに適用可能な_Labels & Retention__というセクションがあります。ボリュームに適用されるSnapshotポリシーは、BlueXPのバックアップとリカバリで認識されるポリシーのいずれかである必要があります。そうでない場合、バックアップファイルは作成されません。

バックアップポリシー作成時のバックアップスケジュール設定のスクリーンショット。

スケジュールには、ラベルと保持の値の2つの部分があります。

  • 「* label *」は、ボリュームからバックアップファイルを作成(または更新)する頻度を定義します。次のタイプのラベルを選択できます。

    • 1つまたは* hourly daily weekly monthly *の組み合わせを選択できます。 および*年単位*の期間。

    • システム定義のポリシーの中から、3カ月、1年、7年のバックアップと保持を提供するポリシーを1つ選択できます。

    • ONTAP System ManagerまたはONTAP CLIを使用してクラスタにカスタムのバックアップ保護ポリシーを作成した場合は、作成したポリシーを1つ選択できます。

  • 「* retention *」の値は、各ラベル(期間)に保持するバックアップ・ファイルの数を定義します。カテゴリまたは間隔内で最大数のバックアップに達すると、古いバックアップは削除されるため、常に最新のバックアップが保持されます。これにより、廃止されたバックアップではクラウドのスペースが消費され続けることがないため、ストレージコストも削減されます。

たとえば、週7回*、月12回*のバックアップを作成するバックアップ・ポリシーを作成したとします。

  • ボリュームのバックアップファイルは、週ごと、月ごとに1つずつ作成されます

  • 8週間目には、最初の週次バックアップが削除され、8週間の新しい週次バックアップが追加されます(最大7週間ごとのバックアップを保持)。

  • 13カ月目には、最初の月単位のバックアップが削除され、13カ月分に新しい月単位のバックアップが追加されます(最大12個の月単位のバックアップを保持)。

年次バックアップは、オブジェクトストレージに転送された後、ソースシステムから自動的に削除されます。このデフォルトの動作は、作業環境の「詳細設定」ページで変更できます。

DataLockとランサムウェア対策のオプション

BlueXPのバックアップとリカバリは、DataLockとランサムウェア対策をボリュームのバックアップに提供します。これらの機能を使用すると、バックアップファイルをロックしてスキャンし、バックアップファイルでランサムウェアの可能性を検出できます。この設定はオプションで、クラスタのボリュームバックアップの保護を強化する場合にバックアップポリシーで定義できます。

これらの機能はどちらもバックアップファイルを保護するため、ランサムウェア攻撃がバックアップに試みられた場合にデータをリカバリするための有効なバックアップファイルを常に保持できます。また、バックアップを一定期間ロックして保持する必要がある規制要件にも対応すると便利です。[DataLock and Ransomware Protection]オプションを有効にすると、BlueXPのバックアップとリカバリのアクティブ化でプロビジョニングされるクラウドバケットでオブジェクトのロックとオブジェクトのバージョン管理が有効になります。

この機能では、ソースボリュームは保護されません。保護されるのは、ソースボリュームのバックアップのみです。いくつかの "ONTAP が提供するアンチランサムウェア防御"ソースボリュームを保護します。

注意
  • DataLockとRansomware Protectionを使用する場合は、最初のバックアップポリシーを作成し、そのクラスタに対してBlueXPのバックアップとリカバリをアクティブ化するときに有効にすることができます。ランサムウェアスキャンは、BlueXP  のバックアップとリカバリの詳細設定を使用してあとから有効または無効にすることができます。

  • BlueXPがボリュームデータをリストアするときにバックアップファイルをスキャンしてランサムウェアを検出すると、クラウドプロバイダからバックアップファイルの内容にアクセスするための追加の出力コストが発生します。

DataLockとは

この機能を使用すると、 SnapMirror経由でクラウドに複製されたクラウドスナップショットをロックできるほか、ランサムウェア攻撃を検出してオブジェクトストア上のスナップショットの整合性のあるコピーを復元する機能も有効になります。この機能はAWS、Azure、 StorageGRIDでサポートされています。

DataLockは、バックアップファイルが一定期間変更または削除されないように保護します。これは_不変ストレージ_とも呼ばれます。この機能では、オブジェクトストレージプロバイダのテクノロジを「オブジェクトロック」に使用します。

クラウドプロバイダーは、スナップショットの保持期間に基づいて計算される「保持期限(RUD)」を使用します。スナップショットの保持期間は、ラベルとバックアップポリシーで定義された保持回数に基づいて計算されます。

スナップショットの最小保存期間は 30 日です。この機能の例をいくつか見てみましょう。

  • 保持回数 20 で 毎日 ラベルを選択した場合、スナップショットの保持期間は 20 日となり、デフォルトで最小の 30 日になります。

  • 保持回数 4 で Weekly ラベルを選択した場合、スナップショットの保持期間は 28 日となり、デフォルトで最小の 30 日になります。

  • 保持回数 3 で 月次 ラベルを選択した場合、スナップショットの保持期間は 90 日になります。

  • 保持回数 1 で Yearly ラベルを選択した場合、スナップショットの保持期間は 365 日になります。

保持期限 (RUD) とは何ですか? また、それはどのように計算されますか?

保持期限 (RUD) は、スナップショットの保持期間に基づいて決定されます。保存期限は、スナップショットの保存期間とバッファーを合計して計算されます。

  • バッファは、転送時間のバッファ (3 日間) + コスト最適化のバッファ (28 日間) で、合計 31 日間になります。

  • 最小保持期間は 30 日 + 31 日のバッファ = 61 日です。

以下にいくつかの例を示します。

  • 月単位のバックアップスケジュールを作成する場合、バックアップは、削除される(次のバックアップファイルに置き換えられて)12カ月間(31日)はロックされます。

  • 毎日 30 回、毎週 7 回、毎月 12 回のバックアップを作成するバックアップ ポリシーを作成する場合、ロックされる保持期間は 3 つあります。

    • 「毎日30回」のバックアップは61日間(30日間31日間のバッファ)保持されます。

    • 「7週間ごと」のバックアップは11週間(7週間31日間)保持され、

    • 「12 か月ごと」のバックアップは 12 か月間 (プラス 31 日間) 保持されます。

  • 保持期間が24回の毎時バックアップスケジュールを作成する場合、バックアップは24時間ロックされると考えられることがあります。ただし、最低30日未満のため、各バックアップは61日間(30日と31日のバッファ)ロックされ、保持されます。

注意 古いバックアップは、バックアップ ポリシーの保持期間後ではなく、DataLock の保持期間が終了した後に削除されます。

DataLock の保持設定は、バックアップ ポリシーのポリシー保持設定よりも優先されます。これにより、バックアップファイルがオブジェクトストアに長期間保存されるため、ストレージのコストに影響する可能性があります。

DataLockとランサムウェア保護を有効にする

ポリシー作成時に、DataLockとランサムウェア保護を有効にできます。ポリシー作成後は、これを有効化、変更、無効化することはできません。

  1. ポリシーを作成するときは、*DataLock およびランサムウェア保護*セクションを展開します。

  2. 次のいずれかを選択します。

    • なし: DataLock 保護とランサムウェア保護は無効になっています。

    • ロック解除:DataLock保護とランサムウェア保護が有効になっています。特定の権限を持つユーザーは、保存期間中に保護されたバックアップファイルを上書きまたは削除できます。

    • ロック:DataLock保護とランサムウェア保護が有効になっています。保存期間中、ユーザーは保護されたバックアップファイルを上書きまたは削除できません。これにより、完全な規制コンプライアンスが満たされます。

を参照してください "[Advanced Settingsページでランサムウェア対策オプションを更新する方法"]。

ランサムウェアからの保護

ランサムウェア防御は、バックアップファイルをスキャンしてランサムウェア攻撃の兆候を探します。ランサムウェア攻撃の検出は、チェックサム比較を使用して実行されます。ランサムウェアの可能性が以前のバックアップファイルではなく新しいバックアップファイルで特定された場合、その新しいバックアップファイルはランサムウェア攻撃の兆候を示さない最新のバックアップファイルに置き換えられます。(ランサムウェア攻撃を受けていると特定されたファイルは、置き換えられてから1日後に削除されます)。

スキャンは次の状況で発生します。

  • クラウド バックアップ オブジェクトのスキャンは、クラウド オブジェクト ストレージに転送されるとすぐに開始されます。スキャンは、クラウドストレージへの初回の書き込み時ではなく、次のバックアップファイルの書き込み時に、バックアップファイルに対して実行されます。

  • 復元プロセスのためにバックアップを選択すると、ランサムウェア スキャンを開始できます。

  • スキャンはいつでもオンデマンドで実行できます。

回復プロセスはどのように機能しますか?

ランサムウェア攻撃が検出されると、サービスはActive Data Connector Integrity Checker REST APIを使用して復旧プロセスを開始します。データオブジェクトの最も古いバージョンが真の情報源となり、復旧プロセスの一環として最新バージョンに作成されます。

これがどのように機能するか見てみましょう:

  • ランサムウェア攻撃が発生した場合、サービスはバケット内のオブジェクトを上書きまたは削除しようとします。

  • クラウドストレージはバージョン管理に対応しているため、バックアップオブジェクトの新しいバージョンが自動的に作成されます。バージョン管理が有効な状態でオブジェクトを削除すると、削除済みとしてマークされますが、引き続き取得可能です。オブジェクトが上書きされた場合は、以前のバージョンが保存され、マークされます。

  • ランサムウェアスキャンが開始されると、両方のオブジェクトバージョンのチェックサムが検証され、比較されます。チェックサムが一致しない場合は、潜在的なランサムウェアが検出されます。

  • 回復プロセスでは、最後に正常だったコピーに戻す作業が行われます。

サポートされている作業環境とオブジェクトストレージプロバイダ

以下のパブリッククラウドプロバイダとプライベートクラウドプロバイダでオブジェクトストレージを使用する際に、ONTAP ボリュームに対するDataLock保護とRansomware保護を有効にすることができます。クラウドプロバイダは今後のリリースで追加される予定です。

ソースの作業環境

バックアップファイルの保存先


ifdef:aws []

AWS の Cloud Volumes ONTAP

Amazon S3

endif::aws[]


ifdef:Azure []

Azure の Cloud Volumes ONTAP

Azure Blob の略

endif::azure[]

ifdef ::gcp[]

endif:GCP []

オンプレミスの ONTAP システム

ifdef:aws []

Amazon S3

endif::aws[]


ifdef:Azure []

Azure Blob の略

endif::azure[]

ifdef ::gcp[]

endif:GCP []

NetApp StorageGRID

要件

  • AWSの場合:

    • クラスタでONTAP 9.11.1以降が実行されている必要があります

    • コネクタは、クラウドまたはオンプレミスに導入できます

    • 次のS3権限は、コネクタに権限を付与するIAMロールに含まれている必要があります。これらは、リソースarn:aws:s3:::NetApp-backup-*」の「backupS3Policy」セクションに含まれています。

      AWS S3権限
      • S3 : GetObjectVersionTagging

      • S3 : GetBucketObjectLockConfiguration

      • S3:GetObjectVersionAcl

      • S3 : PutObjectTagging

      • S3 : DeleteObject

      • S3 : DeleteObjectTagging

      • S3 : GetObjectRetention

      • S3 : DeleteObjectVersionTagging

      • S3 : PutObject

      • S3 : GetObject

      • S3 : PutBucketObjectLockConfiguration

      • S3 : GetLifecycleConfiguration

      • S3 : GetBucketTagging

      • S3 : DeleteObjectVersion

      • S3 : ListBucketVersions

      • S3 : ListBucket

      • S3 : PutBucketTagging

      • S3 : GetObjectTagging

      • S3 : PutBucketVersioning

      • S3 : PutObjectVersionTagging

      • S3 : GetBucketVersioning

      • S3 : GetBucketAcl

      • S3:Bypassガバナー 保持

      • S3 : PutObjectRetention

      • S3 : GetBucketLocation

      • S3 : GetObjectVersion

  • Azureの場合:

    • クラスタでONTAP 9.12.1以降が実行されている必要があります。

    • コネクタは、クラウドまたはオンプレミスに導入できます

  • StorageGRID の場合:

    • クラスタでONTAP 9.11.1以降が実行されている必要があります

    • StorageGRID システムで11.6.0.3以降が実行されている必要があります

    • コネクタは、オンプレミスに導入する必要があります(インターネットにアクセスできるサイトまたはインターネットにアクセスできないサイトにインストールできます)。

    • 次のS3権限は、コネクタに権限を提供するIAMロールに含める必要があります。

      StorageGRID S3権限
      • S3 : GetObjectVersionTagging

      • S3 : GetBucketObjectLockConfiguration

      • S3:GetObjectVersionAcl

      • S3 : PutObjectTagging

      • S3 : DeleteObject

      • S3 : DeleteObjectTagging

      • S3 : GetObjectRetention

      • S3 : DeleteObjectVersionTagging

      • S3 : PutObject

      • S3 : GetObject

      • S3 : PutBucketObjectLockConfiguration

      • S3 : GetLifecycleConfiguration

      • S3 : GetBucketTagging

      • S3 : DeleteObjectVersion

      • S3 : ListBucketVersions

      • S3 : ListBucket

      • S3 : PutBucketTagging

      • S3 : GetObjectTagging

      • S3 : PutBucketVersioning

      • S3 : PutObjectVersionTagging

      • S3 : GetBucketVersioning

      • S3 : GetBucketAcl

      • S3 : PutObjectRetention

      • S3 : GetBucketLocation

      • S3 : GetObjectVersion

制限事項

  • バックアップポリシーでアーカイブストレージを設定している場合、DataLockとランサムウェアからの保護機能は使用できません。

  • BlueXPのバックアップとリカバリをアクティブ化するときに選択するDataLockオプションを、そのクラスタのすべてのバックアップポリシーに使用する必要があります。

  • 1つのクラスタで複数のDataLockモードを使用することはできません。

  • DataLockを有効にすると、すべてのボリュームバックアップがロックされます。1つのクラスタに、ロックされたボリュームバックアップとロックされていないボリュームバックアップを混在させることはできません。

  • DataLockとRansomwareによる保護は、DataLockとRansomwareによる保護が有効なバックアップポリシーを使用した新しいボリュームバックアップに適用されます。これらの機能は、[詳細設定]オプションを使用してあとで有効または無効にすることができます。

  • FlexGroupボリュームでDataLockとランサムウェア対策を使用できるのは、ONTAP 9.13.1以降を使用している場合のみです。

DataLockのコストを削減する方法のヒント

DataLock機能をアクティブにしたまま、ランサムウェアスキャン機能を有効または無効にすることができます。追加料金を回避するために、定期的なランサムウェアスキャンを無効にすることができます。これにより、セキュリティ設定をカスタマイズし、クラウドプロバイダからのコストを回避できます。

スケジュールされたランサムウェアスキャンが無効になっていても、必要に応じてオンデマンドスキャンを実行できます。

さまざまな保護レベルを選択できます。

  • * DataLock_without_ransomwareスキャン*:デスティネーションストレージのバックアップデータを、ガバナンスモードまたはコンプライアンスモードのいずれかで保護します。

    • ガバナンスモード:管理者は、保護されたデータの上書きや削除を柔軟に行うことができます。

    • 準拠モード:保持期間が終了するまで完全に消去できません。これにより、規制の厳しい環境で最も厳しいデータセキュリティ要件を満たすことができます。データのライフサイクル中は上書きや変更を行うことができないため、バックアップコピーを最も強力に保護できます。

      メモ Microsoft Azureでは、代わりにロックとロック解除モードが使用されます。
  • * DataLock_with_ransomwareスキャン*:データのセキュリティを強化します。この機能は、バックアップコピーの変更を検出するのに役立ちます。何らかの試行が行われると、新しいバージョンのデータが慎重に作成されます。スキャン周波数は1、2、3、4、5に変更できます。 六日又は七日スキャンを7日ごとに設定すると、コストが大幅に削減されます。

DataLockコストを軽減するためのその他のヒントについては、を参照してください。 https://community.netapp.com/t5/Tech-ONTAP-Blogs/Understanding-BlueXP-Backup-and-Recovery-DataLock-and-Ransomware-Feature-TCO/ba-p/453475

さらに、にアクセスして、DataLockに関連するコストの見積もりを取得できます "BlueXPのバックアップ/リカバリ用Total Cost of Ownership(TCO;総所有コスト)試算ツール"

アーカイブストレージのオプション

AWS、Azure、Googleのクラウドストレージを使用している場合は、一定の日数が経過したら、古いバックアップファイルを低コストのアーカイブストレージクラスまたはアクセス階層に移動できます。また、標準のクラウドストレージに書き込まれることなく、バックアップファイルをすぐにアーカイブストレージに送信することもできます。「Archive after days」に「* 0 *」と入力するだけで、バックアップファイルをアーカイブストレージに直接送信できます。これは、クラウドバックアップからデータにアクセスする必要がほとんどないユーザや、テープの解決策にバックアップを取って代わるユーザに特に役立ちます。

アーカイブ層のデータには、必要なときにすぐにアクセスできないため、読み出しコストが高くなるため、バックアップファイルのアーカイブを決定する前に、バックアップファイルからデータをリストアする頻度を検討する必要があります。

メモ
  • すべてのデータブロックをアーカイブクラウドストレージに送信するために「0」を選択した場合でも、メタデータブロックは常に標準のクラウドストレージに書き込まれます。

  • DataLockを有効にしている場合、アーカイブストレージは使用できません。

  • 「* 0 *日」(すぐにアーカイブ)を選択した後、アーカイブポリシーを変更することはできません。

各バックアップポリシーには、バックアップファイルに適用できる_Archival Policy_に関するセクションがあります。

バックアップポリシーを作成するときのアーカイブポリシーの設定のスクリーンショット。

  • AWS では、バックアップは _Standard_storage クラスから開始し、 30 日後に _Standard-Infrequent Access_storage クラスに移行します。

    クラスタがONTAP 9.10.1以降を使用している場合は、古いバックアップをS3 Glacier Deep Archive_storageに階層化できます。"AWS アーカイブストレージの詳細は、こちらをご覧ください"です。

    • BlueXPのバックアップとリカバリをアクティブ化するときに最初のバックアップポリシーでアーカイブ階層を選択しない場合は、以降のポリシーでは_S3 Glacier_のみがアーカイブオプションになります。

    • 最初のバックアップポリシーで_S3 Glacier_を選択した場合は、そのクラスタの以降のバックアップポリシー用に_S3 Glacier Deep Archive_tierに変更できます。

    • 最初のバックアップポリシーで_S3 Glacier Deep Archive_を 選択した場合は、その階層がそのクラスタの今後のバックアップポリシーで使用できる唯一のアーカイブ階層になります。

  • Azure では、バックアップは _COOL アクセス層に関連付けられます。

    ONTAP 9.10.1以降を使用しているクラスタでは、古いバックアップを_Azure Archive_storageに階層化できます。"Azure アーカイブストレージの詳細については、こちらをご覧ください"です。

  • GCP では、バックアップは _Standard_storage クラスに関連付けられます。

    オンプレミスクラスタでONTAP 9.12.1以降を使用している場合は、コストをさらに最適化するために、BlueXPのバックアップとリカバリのUIで、古いバックアップを_Archive_storageに階層化することができます。"Googleアーカイブストレージの詳細をご覧ください"です。

  • StorageGRID では、バックアップは _Standard_storage クラスに関連付けられます。

    オンプレミスクラスタがONTAP 9.12.1以降を使用しており、StorageGRID システムが11.4以降を使用している場合は、古いバックアップファイルをパブリッククラウドアーカイブストレージにアーカイブできます。

+** AWSでは、AWS_S3 Glacier Deep Archive_storageにバックアップを階層化できます。"AWS アーカイブストレージの詳細は、こちらをご覧ください"です。

+** Azureでは、古いバックアップを_Azure Archive_storageに階層化できます。"Azure アーカイブストレージの詳細については、こちらをご覧ください"です。