。 snapshot-only tiering-policy アクティブファイルシステムと共有されていないブロックにのみ適用されます。基本的には、データベースバックアップの階層化につながります。Snapshotが作成されてそのブロックが上書きされると、ブロックが階層化の候補となり、その結果、Snapshot内にのみ存在するブロックが作成されます。Aの前の遅延 snapshot-only ブロックは冷却されていると見なされ、によって制御されます。 tiering-minimum-cooling-days ボリュームの設定。ONTAP 9.8で指定できる範囲は2～183日です。

多くのデータセットは変更率が低いため、このポリシーによる削減効果は最小限に抑えられます。たとえば、ONTAPで観察される一般的なデータベースの変更率は、週あたり5%未満です。データベースのアーカイブログは大量のスペースを占有することがありますが、通常はアクティブファイルシステムに引き続き存在するため、このポリシーでは階層化の対象になりません。

。 auto 階層化ポリシーは、階層化をSnapshot固有のブロックだけでなく、アクティブなファイルシステム内のブロックにも拡張します。ブロックが冷却されるまでの遅延は、 tiering-minimum-cooling-days ボリュームの設定。ONTAP 9.8で指定できる範囲は2～183日です。

このアプローチでは、では使用できない階層化オプションが有効になります。 snapshot-only ポリシー：たとえば、データ保護ポリシーで特定のログファイルを90日間保持する必要がある場合があります。クーリング期間を3日に設定すると、3日を超過した古いログファイルがパフォーマンスレイヤから階層化されます。この操作により、パフォーマンス階層のかなりのスペースが解放されると同時に、90日間分のすべてのデータを表示して管理することができます。

。 none 階層化ポリシーを使用すると、追加のブロックがストレージレイヤから階層化されなくなりますが、大容量階層のデータは読み取りが行われるまで大容量階層に残ります。その後ブロックが読み取られると、元に戻されてパフォーマンス階層に配置されます。

を使用する主な理由は、 none 階層化ポリシーはブロックが階層化されないようにするためのものですが、時間の経過とともにポリシーを変更すると便利です。たとえば、あるデータセットが大容量レイヤに階層化されているとしますが、完全なパフォーマンス機能が予期せず必要になったとします。このポリシーを変更すると、追加の階層化が不要になり、I/Oの増加に伴って読み取られたブロックがパフォーマンス階層に残るようにすることができます。

。 all 階層化ポリシーで置き換えられる backup ONTAP 9.6以降のポリシー。。 backup データ保護ボリューム（SnapMirrorまたはNetApp SnapVaultのデスティネーション）にのみ適用されるポリシー。。 all ポリシーの機能は同じですが、データ保護ボリュームに限定されません。

このポリシーでは、ブロックはすぐにクールとみなされ、すぐに容量レイヤに階層化できるようになります。

このポリシーは、長期的なバックアップに特に適しています。Hierarchical Storage Management（HSM；階層型ストレージ管理）の一種としても使用できます。以前は、ファイルシステム上でファイル自体を認識したまま、ファイルのデータブロックをテープに階層化するためにHSMが一般的に使用されていました。FabricPoolボリューム all ポリシーを使用すると、表示および管理可能なにファイルを格納できますが、ローカルストレージ階層のスペースはほとんど消費しません。