Il snapshot-only tiering-policy si applica solo ai blocchi non condivisi con il file system attivo. Essenzialmente si traduce in tiering dei backup del database. I blocchi diventano candidati per il tiering dopo la creazione di uno snapshot e il blocco viene quindi sovrascritto, generando un blocco presente solo all'interno dello snapshot. Il ritardo prima di un snapshot-only il blocco è considerato freddo e controllato da tiering-minimum-cooling-days impostazione del volume. L'intervallo a partire da ONTAP 9,8 è compreso tra 2 e 183 giorni.

Molti set di dati hanno tassi di cambiamento bassi, con conseguenti risparmi minimi derivanti da questa policy. Ad esempio, un database tipico osservato con ONTAP ha un tasso di variazione inferiore al 5% alla settimana. I log di archivio dei database possono occupare spazio esteso, ma in genere continuano a esistere nel file system attivo e pertanto non possono essere candidati per il tiering in base a questa policy.

Il auto la policy di tiering estende il tiering sia a blocchi specifici di snapshot che a blocchi nel file system attivo. Il ritardo prima che un blocco venga considerato freddo è controllato dall' tiering-minimum-cooling-days impostazione del volume. L'intervallo a partire da ONTAP 9,8 è compreso tra 2 e 183 giorni.

Questo approccio abilita opzioni di tiering che non sono disponibili con snapshot-only policy. Ad esempio, un criterio di protezione dei dati potrebbe richiedere la conservazione di 90 giorni di determinati file di registro. L'impostazione di un periodo di raffreddamento di 3 giorni comporta il tiering di tutti i file di registro precedenti a 3 giorni dal livello delle prestazioni. Questa azione libera spazio sostanziale sul Tier delle performance, consentendoti comunque di visualizzare e gestire tutti e 90 i giorni di dati.

Il none la policy di tiering impedisce il tiering di blocchi aggiuntivi dal layer di storage, ma i dati ancora presenti nel tier di capacità rimangono nel tier di capacità fino a quando non vengono letti. Se quindi il blocco viene letto, viene tirato indietro e posizionato nel Tier di performance.

Il motivo principale per cui si utilizza none la policy di tiering impedisce il tiering dei blocchi, ma nel tempo potrebbe risultare utile modificarli. Ad esempio, supponiamo che un set di dati specifico venga suddiviso in Tier per il livello di capacità, ma sorge un'esigenza inaspettata di funzionalità di performance complete. La policy può essere modificata per impedire qualsiasi tiering aggiuntivo e per confermare che i blocchi letti nuovamente quando l'io aumenta rimangono nel Tier di performance.

Il all la policy di tiering sostituisce backup Policy in data ONTAP 9,6. Il backup Policy applicata solo ai volumi di data Protection, che significa destinazione SnapMirror o NetApp SnapVault. Il all le funzioni dei criteri sono identiche, ma non si limitano ai volumi di protezione dei dati.

Grazie a questa policy, i blocchi vengono immediatamente considerati COOL e possono essere immediatamente suddivisi in Tier nel livello di capacità.

Questo criterio è particolarmente appropriato per i backup a lungo termine. Può anche essere utilizzato come forma di gestione gerarchica dello storage (HSM, Hierarchical Storage Management). In passato, HSM veniva comunemente utilizzato per eseguire il tiering dei blocchi di dati di un file su nastro, mantenendo il file stesso visibile nel file system. Un volume FabricPool con all il criterio consente di archiviare i file in un archivio visibile e gestibile pur non occupando quasi nessuno spazio nel livello di storage locale.