Two options exist for tiering inactive snapshot blocks to the capacity tier. First, the snapshot-only policy only targets the snapshot blocks. Although the auto policy includes the snapshot-only blocks, it also tiers blocks from the active file system. This might not be desirable.

The tiering-minimum-cooling-days value should be set to a time period that makes data that might be required during a restoration available on the performance tier. For example, most restore scenarios of a critical production database include a restore point at some time in the previous few days. Setting a tiering-minimum-cooling-days value of 3 would make sure that any restoration of the file results in a file that immediately delivers maximum performance. All blocks in the active files are still present on fast storage without needing to recover them from the capacity tier.

A snapshot that is replicated with SnapMirror or SnapVault that is only used for recovery should generally use the FabricPool all policy. With this policy, metadata is replicated, but all data blocks are immediately sent to the capacity tier, which yields maximum performance. Most recovery processes involve sequential I/O, which is inherently efficient. The recovery time from the object store destination should be evaluated, but, in a well-designed architecture, this recovery process does not need to be significantly slower than recovery from local data.

If the replicated data is also intended to be used for cloning, the auto policy is more appropriate, with a tiering-minimum-cooling-days value that encompasses data that is expected to be regularly used in a cloning environment. For example, a database's active working set might include data read or written in the previous three days, but it could also include another 6 months of historical data. If so, then the auto policy at the SnapMirror destination makes the working set available on the performance tier.