

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# SnapLock の仕組み
<a name="how-snaplock-works"></a>

SnapLock を使うと、ファイルが削除、変更されたり、その名前が変更されたりするのを防ぐことにより、規制やガバナンス上の目的を満たすことができます。SnapLock ボリュームを作成する際は、ファイルを WORM (Write Once, Read Many) ストレージにコミットし、データの保持期間を設定します。ファイルは、指定した期間だけ、または無期限に、消去不可または書き込み不可の状態で保存できます。

**重要**  
ボリュームの作成時に、SnapLock の設定を使用するかどうかを指定する必要があります。作成後は、SnapLock ではないボリュームを SnapLock に変換することはできません。

## リテンションモード
<a name="snaplock-retention-modes"></a>

SnapLock には、Compliance と Enterprise という 2 種類の保持モードがあります。Amazon FSx for NetApp ONTAP は、両方のモードをサポートしています。これらはユースケースが異なり、機能も一部異なりますが、どちらも WORM モデルを使うことでデータを変更または削除から保護します。以下の表は、両方の保持モードの類似点と相違点をまとめたものです。


| SnapLock 機能 | [SnapLock コンプライアンスについて](snaplock-compliance.md) | [SnapLock エンタープライズ について](snaplock-enterprise.md) | 
| --- | --- | --- | 
| 説明 | Compliance ボリューム上の WORM に移行したファイルは、保持期間が終了するまで削除することはできません。 | Enterprise ボリューム上の WORM に移行したファイルは、権限を持つユーザーが特権削除を使用すると、保持期間の終了前に削除することができます。 | 
| ユースケース |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/how-snaplock-works.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/how-snaplock-works.html)  | 
| [自動コミット](worm-state.md#worm-state-autocommit) | はい  | はい | 
| [イベントベースの保持 (EBR)](worm-state.md#worm-state-ebr)1 | はい | はい | 
| [リーガルホールド](worm-state.md#worm-state-legal-hold)1 | はい | なし | 
| [特権付き削除の使用](snaplock-enterprise.md#privileged-delete) | なし | はい | 
| [ボリューム付加モード](worm-state.md#worm-state-append) | はい | はい | 
| [SnapLock 監査ログボリューム](#snaplock-audit-log-volume) | はい | はい | 

**注記**  
1 EBR および法的保持操作は、ONTAPCLI および REST API でサポートされています。

**注記**  
FSx for ONTAP は、SnapLock タイプに関係なく、すべての SnapLock ボリュームの容量プールへのデータの階層化をサポートしています。詳細については、「[ボリュームデータの階層化](volume-storage-capacity.md#volume-data-tiering)」を参照してください。

## SnapLock 管理者
<a name="snaplock-admin"></a>

SnapLock ボリュームで特定のアクションを実行するときは、SnapLock 管理者権限が必要になります。SnapLock 管理者権限は、ONTAP CLI の `vsadmin-snaplock` のロールで定義されます。SnapLock 管理者ロールを持つ、ストレージ仮想マシン (SVM) 管理者アカウントを作成できるのは、クラスター管理者です。

次のアクションは、ONTAP CLI の `vsadmin-snaplock` のロールを使用することで実行できます。
+ 自分のユーザーアカウント、ローカルパスワード、キー情報を管理する
+ ボリュームを管理する (ボリュームの移動は除く)
+ クォータ、qtree、スナップショットのコピー、ファイルを管理する
+ 特権削除やリーガルホールドなど、SnapLock のアクションを実行する
+ ネットワークファイルシステム (NFS) とサーバーメッセージブロック (SMB) プロトコルを設定する 
+ ドメインネームシステム (DNS)、Lightweight Directory Access Protocol (LDAP)、Network Information Service (NIS) の各サービスを設定する 
+ ジョブをモニタリングする

以下の手順では、ONTAP CLI で SnapLock 管理者を作成する方法について説明します。このタスクを実行するには、Secure Shell Protocol (SSH) などの安全な接続で、クラスター管理者としてログインする必要があります。

**ONTAP CLI で vsadmin-snaplock ロールを持つ SVM 管理者アカウントを作成するには**
+ 以下のコマンドを実行してください。*SVM\$1name* と *SnapLockAdmin* を、自分の情報に置き換えます。

  ```
  cluster1::> security login create -vserver SVM_name -user-or-group-name SnapLockAdmin -application ssh -authentication-method password -role vsadmin-snaplock
  ```

詳細については、「[ONTAP ロールとユーザー](roles-and-users.md)」を参照してください。

## SnapLock 監査ログボリューム
<a name="snaplock-audit-log-volume"></a>

 SnapLock 監査ログボリュームには SnapLock 監査ログが含まれ、監査ログには、SnapLock 管理者が作成された日時、特権削除が実行された日時、ファイルにリーガルホールドが適用された日時などの、イベントのタイムスタンプが含まれています。SnapLock 監査ログのボリュームは、消去できないイベントの記録です。

以下のアクションを行うには、SnapLock 監査ログボリュームを SnapLock ボリュームと同じ SVM に作成する必要があります。
+ 特権削除を SnapLock Enterprise ボリュームで有効または無効にするには 
+ リーガルホールドを SnapLock Compliance ボリューム内のファイルに適用するには 

**警告**  
 SnapLock 監査ログボリュームの最小保持期間は 6 か月間です。この保持期間が終了しないと、SnapLock 監査ログボリュームが SnapLock Enterprise モードで作成されている場合であっても、そのボリュームとそれに関連付けられている SVM およびファイルシステムは削除できません。
特権削除を使用してファイルを削除した際に、ファイルの保持期間がボリュームの保持期間よりも長い場合、監査ログボリュームはファイルの保持期間を継承します。例えば、特権削除を使用して、保持期間が 10 か月のファイルを削除した際に、監査ログボリュームの保持期間が 6 か月の場合、この監査ログボリュームの保持期間は 10 か月に延長されます。

 SVM で使用できるアクティブな SnapLock 監査ログボリュームは 1 つのみですが、これは SVM 内の複数の SnapLock ボリュームで共有できます。SnapLock 監査ログボリュームを正常にマウントするには、ジャンクションパスを `/snaplock_audit_log` に設定します。このジャンクションパスは、監査ログボリュームではないボリュームを含め、他のボリュームが使用することはできません。

 SnapLock 監査ログは、監査ログボリュームのルートの下にある `/snaplock_log` ディレクトリにあります。特権削除のオペレーションは、`privdel_log` サブディレクトリにログ記録されます。リーガルホールドの開始および終了オペレーションは、`/snaplock_log/legal_hold_logs/` にログ記録されます。それ以外のログはすべて、`system_log` サブディレクトリに保存されます。

SnapLock 監査ログボリュームは、Amazon FSx コンソール、 AWS CLI、Amazon FSx API、および ONTAP CLI と REST API を使用して作成できます。

**注記**  
 データ保護 (DP) ボリュームを SnapLock 監査ログボリュームとして使用することはできません。

Amazon FSx API を使用して SnapLock 監査ログボリュームをオンにするには、[https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateSnaplockConfiguration.html](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateSnaplockConfiguration.html) で `AuditLogVolume` を使用します。Amazon FSx コンソールの **[監査ログボリューム]** で、**[有効]** を選択します。**[ジャンクションパス]** が `/snaplock_audit_log` に設定されていることを確認します。

## SnapLock ボリューム内のデータへのアクセス
<a name="accessing-snaplock-data"></a>

SnapLock ボリューム内のデータには、NFS や SMB など、オープンファイルのプロトコルを使用することでアクセスできます。SnapLock ボリュームにデータを書き込んだり、WORM で保護されたデータを読み込んだりしても、パフォーマンスには影響しません。

NFS や SMB を使うことで SnapLock ボリューム間でファイルをコピーできます。ただし、元の WORM プロパティはコピー先の SnapLock ボリュームでは保持されません。コピーしたファイルの変更または削除を防ぐには、コピーしたファイルを WORM に再コミットする必要があります。詳細については、「[ファイルを WORM 状態にコミットする](worm-state.md)」を参照してください。

また、SnapMirror を使って SnapLock データをレプリケートすることも可能ですが、レプリケート元のボリュームとレプリケート先のボリュームは同じ保持モードの SnapLock ボリュームでなければなりません (共に Compliance モードまたは Enterprise モードであるなど)。

## SnapLock および SSD の容量削減オペレーション
<a name="snaplock-ssd-decrease"></a>

SnapLock ボリュームを作成する前に、SSD の減少に関する以下の点を考慮してください:
+ Amazon FSx は、SnapLockボリュームを含むファイルシステムの SSD 容量削減リクエストを拒否します。
+ SSD 容量削減オペレーション中にSnapLockボリュームを作成することはできません。

これらの制限が存在するのは、ONTAPによってSnapLock監査ログボリュームに 6 か月の最小保有期間が適用されるためです。これにより、SSD 減少操作の一環としてSnapLockボリュームが移動された場合、その期間中にファイルシステムが削除されることはありません。

SnapLock ボリュームのあるファイルシステムで SSD 容量を減らす必要がある場合は、SSD 容量が小さい新しいファイルシステムにデータを移行する必要があります。制限事項や考慮事項など、SSD 容量減少操作の詳細については、[ファイルシステム SSD ストレージと IOPS の更新](storage-capacity-and-IOPS.md#increase-primary-storage)をご参照ください。