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

NetApp Backup and Recovery のオブジェクトへのバックアップ ポリシー オプション

共同作成者 netapp-mwallis

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

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

注意 NetAppのバックアップとリカバリのワークロードを切り替えるには、"さまざまなNetAppバックアップおよびリカバリワークロードに切り替える"

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

NetApp Backup and Recovery を使用すると、システム (クラスタ) ごとに固有のスケジュールを持つ複数のバックアップ ポリシーを作成できます。異なる復旧ポイント目標 (RPO) を持つボリュームに、異なるバックアップ ポリシーを割り当てることができます。

各バックアップ ポリシーには、バックアップ ファイルに適用できる「ラベルと保持」のセクションが用意されています。ボリュームに適用されるスナップショット ポリシーは、 NetApp Backup and Recovery によって認識されるポリシーのいずれかである必要があることに注意してください。そうでないと、バックアップ ファイルは作成されません。

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

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

    • 時間別日別週別月別、*年別*の時間枠のいずれか、または組み合わせを選択できます。

    • 3 か月、1 年、または 7 年間のバックアップと保持を提供するシステム定義のポリシーのいずれかを選択できます。

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

  • 保持 値は、各ラベル (期間) に保持されるバックアップ ファイルの数を定義します。カテゴリまたは間隔内のバックアップの最大数に達すると、古いバックアップが削除されるため、常に最新のバックアップが保持されます。また、古いバックアップがクラウド内のスペースを占有し続けることがなくなるため、ストレージ コストも節約できます。

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

  • 毎週、毎月、ボリュームのバックアップファイルが作成されます

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

  • 13 か月目に、最初の月次バックアップが削除され、13 か月目の新しい月次バックアップが追加されます (最大 12 個の月次バックアップが保持されます)

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

DataLockとランサムウェア保護オプション

NetApp Backup and Recovery は、ボリューム バックアップに対する DataLock およびランサムウェア保護のサポートを提供します。これらの機能を使用すると、バックアップ ファイルをロックしてスキャンし、バックアップ ファイル上のランサムウェアの可能性を検出できます。これは、クラスターのボリューム バックアップをさらに保護したい場合に、バックアップ ポリシーで定義できるオプションの設定です。

これら 2 つの機能はバックアップ ファイルを保護するため、バックアップに対してランサムウェア攻撃が試みられた場合でも、常に有効なバックアップ ファイルがあり、そこからデータを回復することができます。また、バックアップをロックして一定期間保持する必要がある特定の規制要件を満たすのにも役立ちます。DataLock および Ransomware Resilience オプションを有効にすると、 NetApp Backup and Recovery アクティベーションの一部としてプロビジョニングされるクラウド バケットで、オブジェクトのロックとオブジェクトのバージョン管理が有効になります。

この機能はソース ボリュームを保護するものではなく、ソース ボリュームのバックアップのみを保護します。いくつかの "ONTAPが提供するランサムウェア対策"ソースボリュームを保護します。

注意
  • DataLock とランサムウェア保護を使用する予定の場合は、最初のバックアップ ポリシーを作成し、そのクラスターに対してNetApp Backup and Recovery をアクティブ化するときに、これを有効にできます。後で、 NetApp Backup and Recovery の詳細設定を使用して、ランサムウェア スキャンを有効または無効にすることができます。

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

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 回の保持期間を持つ月次バックアップ スケジュールを作成した場合、バックアップは 12 か月間 (プラス 31 日間) ロックされた後、削除され (次のバックアップ ファイルに置き換えられます) ます。

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

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

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

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

  • 24 の保持期間を持つ 1 時間ごとのバックアップ スケジュールを作成すると、バックアップが 24 時間ロックされると思われるかもしれません。ただし、これは最小期間の 30 日未満であるため、各バックアップは 61 日間 (30 日 + 31 日のバッファ) ロックされ、保持されます。

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

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

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

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

  1. ポリシーを作成するときは、DataLock および Ransomware Resilience セクションを展開します。

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

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

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

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

ランサムウェア対策とは

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

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

  • クラウド バックアップ オブジェクトのスキャンは、クラウド オブジェクト ストレージに転送されるとすぐに開始されます。バックアップ ファイルが最初にクラウド ストレージに書き込まれるときにスキャンが実行されず、次のバックアップ ファイルが書き込まれるときにスキャンが実行されます。

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

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

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

ランサムウェア攻撃が検出されると、サービスは Active Data Console エージェントの Integrity Checker REST API を使用して回復プロセスを開始します。データ オブジェクトの最も古いバージョンが真実のソースであり、回復プロセスの一環として現在のバージョンに作成されます。

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

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

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

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

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

サポートされているシステムとオブジェクトストレージプロバイダー

次のパブリックおよびプライベート クラウド プロバイダーのオブジェクト ストレージを使用する場合、次のシステムのONTAPボリュームで DataLock およびランサムウェア保護を有効にできます。

ソースシステム バックアップファイルの保存先 ifdef::aws[]

AWS のCloud Volumes ONTAP

Amazon S3 endif::aws[] ifdef::azure[]

Azure のCloud Volumes ONTAP

Azure BLOB endif::azure[] ifdef::gcp[]

Google Cloud のCloud Volumes ONTAP

Google Cloud endif::gcp[]

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

ifdef::aws[] Amazon S3 endif::aws[] ifdef::azure[] Azure Blob endif::azure[] ifdef::gcp[] Google Cloud 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:オブジェクトのタグ付け

      • s3:オブジェクトの削除

      • s3:オブジェクトのタグ付けを削除

      • s3:GetObjectRetention

      • s3:オブジェクトバージョンタグ付けの削除

      • s3:PutObject

      • s3:GetObject

      • s3:PutBucketObjectLockConfiguration

      • s3:GetLifecycleConfiguration

      • s3:GetBucketTagging

      • s3:オブジェクトバージョンの削除

      • s3:バケットバージョンのリスト

      • s3:リストバケット

      • s3:PutBucketTagging

      • s3:GetObjectTagging

      • s3:PutBucketバージョン管理

      • s3:PutObjectVersionTagging

      • s3:GetBucketVersioning

      • s3:GetBucketAcl

      • s3:バイパスガバナンス保持

      • s3:PutObjectRetention

      • s3:GetBucketLocation

      • s3:GetObjectVersion

  • Azureの場合:

    • クラスタはONTAP 9.12.1以降を実行している必要があります

    • コンソールエージェントはクラウドまたはオンプレミスに導入できます

  • Google Cloud の場合:

    • クラスタはONTAP 9.17.1以降を実行している必要があります

    • コンソールエージェントはクラウドまたはオンプレミスに導入できます

  • StorageGRIDの場合:

    • クラスタはONTAP 9.11.1以降を実行している必要があります

    • StorageGRIDシステムは11.6.0.3以降を実行している必要があります

    • コンソール エージェントは、オンプレミスで展開する必要があります (インターネット アクセスの有無にかかわらずサイトにインストールできます)

    • 次の S3 権限は、コンソール エージェントに権限を提供する IAM ロールの一部である必要があります。

      StorageGRID S3 権限
      • s3:GetObjectVersionTagging

      • s3:GetBucketObjectLockConfiguration

      • s3:GetObjectVersionAcl

      • s3:オブジェクトのタグ付け

      • s3:オブジェクトの削除

      • s3:オブジェクトのタグ付けを削除

      • s3:GetObjectRetention

      • s3:オブジェクトバージョンタグ付けの削除

      • s3:PutObject

      • s3:GetObject

      • s3:PutBucketObjectLockConfiguration

      • s3:GetLifecycleConfiguration

      • s3:GetBucketTagging

      • s3:オブジェクトバージョンの削除

      • s3:バケットバージョンのリスト

      • s3:リストバケット

      • s3:PutBucketTagging

      • s3:GetObjectTagging

      • s3:PutBucketバージョン管理

      • s3:PutObjectVersionTagging

      • s3:GetBucketVersioning

      • s3:GetBucketAcl

      • s3:PutObjectRetention

      • s3:GetBucketLocation

      • s3:GetObjectVersion

制限事項

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

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

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

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

  • DataLock およびランサムウェア保護は、DataLock およびランサムウェア保護が有効になっているバックアップ ポリシーを使用した新しいボリューム バックアップに適用されます。後で「詳細設定」オプションを使用してこれらの機能を有効または無効にすることができます。

  • FlexGroupボリュームは、 ONTAP 9.13.1 以降を使用している場合にのみ、DataLock およびランサムウェア保護を使用できます。

DataLockのコストを軽減するヒント

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

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

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

  • ランサムウェア スキャンなしの DataLock: ガバナンス モードまたはコンプライアンス モードのいずれかの宛先ストレージ内のバックアップ データを保護します。

    • ガバナンス モード: 管理者が保護されたデータを上書きまたは削除する柔軟性を提供します。

    • コンプライアンス モード: 保持期間が終了するまで完全に消去不可能な状態を保ちます。これにより、規制の厳しい環境における最も厳しいデータ セキュリティ要件を満たすことができます。データはライフサイクル中に上書きまたは変更できないため、バックアップ コピーに対して最強レベルの保護が提供されます。

      メモ 代わりに、Microsoft Azure ではロックおよびロック解除モードが使用されます。
  • ランサムウェア スキャン機能を備えた DataLock: データのセキュリティをさらに強化します。この機能は、バックアップ コピーを変更しようとする試みを検出するのに役立ちます。何らかの試みが行われた場合、データの新しいバージョンが慎重に作成されます。スキャン頻度は 1、2、3、4、5、6、または 7 日に変更できます。スキャンを 7 日ごとに設定すると、コストが大幅に削減されます。

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

さらに、DataLockに関連する費用の見積もりは、 "NetAppバックアップおよびリカバリの総所有コスト (TCO) 計算ツール"

アーカイブ保存オプション

AWS、Azure、または Google クラウド ストレージを使用する場合、一定の日数が経過すると、古いバックアップ ファイルをより安価なアーカイブ ストレージ クラスまたはアクセス層に移動できます。バックアップ ファイルを標準のクラウド ストレージに書き込まずに、すぐにアーカイブ ストレージに送信することも選択できます。バックアップ ファイルをアーカイブ ストレージに直接送信するには、「Archive After Days」に 0 と入力するだけです。これは、クラウド バックアップのデータにアクセスする必要がほとんどないユーザーや、テープ ソリューションへのバックアップを置き換えるユーザーにとって特に役立ちます。

アーカイブ層のデータは必要なときにすぐにアクセスできず、取得コストが高くなります。そのため、バックアップ ファイルをアーカイブするかどうかを決定する前に、バックアップ ファイルからデータを復元する必要がある頻度を考慮する必要があります。

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

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

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

各バックアップ ポリシーには、バックアップ ファイルに適用できる「アーカイブ ポリシー」のセクションが用意されています。

  • AWS では、バックアップは Standard ストレージ クラスで開始され、30 日後に Standard-Infrequent Access ストレージ クラスに移行します。

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

    • NetApp Backup and Recovery をアクティブ化するときに最初のバックアップ ポリシーでアーカイブ層を選択しなかった場合、将来のポリシーでは S3 Glacier が唯一のアーカイブ オプションになります。

    • 最初のバックアップ ポリシーで S3 Glacier を選択した場合は、そのクラスターの将来のバックアップ ポリシーを S3 Glacier Deep Archive 層に変更できます。

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

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

    クラスターでONTAP 9.10.1 以降を使用している場合は、古いバックアップを Azure Archive ストレージに階層化できます。"Azure アーカイブ ストレージの詳細"

  • GCP では、バックアップは Standard ストレージ クラスに関連付けられています。

    オンプレミスのクラスターでONTAP 9.12.1 以降を使用している場合は、コストをさらに最適化するために、一定の日数後にNetApp Backup and Recovery UI で古いバックアップをアーカイブ ストレージに階層化することを選択できます。"Google アーカイブ ストレージの詳細"

  • StorageGRIDでは、バックアップは Standard ストレージ クラスに関連付けられます。

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

+ ** AWS の場合、AWS S3 Glacier または S3 Glacier Deep Archive ストレージにバックアップを階層化できます。"AWSアーカイブストレージの詳細"

+ ** Azure の場合、古いバックアップを Azure Archive ストレージに階層化できます。"Azure アーカイブ ストレージの詳細"