。 snapshot-only tiering-policy 僅適用於未與作用中檔案系統共用的區塊。它基本上會導致資料庫備份分層。在建立快照之後、區塊會成為分層的候選項目、然後區塊會被覆寫、導致區塊只存在於快照中。A 之前的延遲 snapshot-only 區塊視為冷區、由控制 tiering-minimum-cooling-days 音量設定。ONTAP 9.8 的範圍為 2 至 183 天。

許多資料集的變更率都很低、因此這項原則可節省的成本極低。例如、在 ONTAP 上觀察到的典型資料庫每週變更率低於 5% 。資料庫歸檔記錄檔可能佔用大量空間、但通常會繼續存在於作用中的檔案系統中、因此不會成為根據此原則分層的候選項目。

。 auto 分層原則可將分層延伸至快照專用區塊、以及作用中檔案系統內的區塊。區塊冷卻前的延遲由控制 tiering-minimum-cooling-days 音量設定。ONTAP 9.8 的範圍為 2 至 183 天。

此方法可啟用無法與搭配使用的分層選項 snapshot-only 原則。例如、資料保護原則可能需要保留 90 天的特定記錄檔。如果將冷卻期設定為 3 天、則任何超過 3 天的記錄檔都會從效能層中分層移出。此動作可釋放效能層級上的大量空間、同時仍可讓您檢視及管理完整的 90 天資料。

。 none 分層原則可防止任何額外的區塊從儲存層分層、但容量層中的任何資料仍會保留在容量層中、直到讀取為止。如果接著讀取區塊、則會將其拉回並放置在效能層上。

使用的主要原因 none 分層原則旨在防止區塊分層、但隨著時間推移而變更原則可能會很有用。例如、假設某個特定資料集已廣泛分層至容量層、但卻產生對完整效能功能的非預期需求。可變更原則以防止任何額外的分層、並確認隨 IO 增加而讀取的任何區塊仍保留在效能層中。

。 all 分層原則取代了 backup 原則自 ONTAP 9.6 起。。 backup 原則僅套用至資料保護磁碟區、意指 SnapMirror 或 NetApp SnapVault 目的地。。 all 原則的功能相同、但不限於資料保護磁碟區。

有了這項原則、就能立即將區塊視為酷炫、並立即分層至容量層。

此原則特別適用於長期備份。它也可以用作階層式儲存管理（ HSM ）的形式。過去、 HSM 通常用於將檔案的資料區塊分層至磁帶、同時讓檔案本身在檔案系統上保持可見。具有的 FabricPool Volume all 原則可讓您將檔案儲存在可見且可管理的環境中、但幾乎無需佔用本機儲存層的空間。