Home SmartFiles (File and Object Services) NAS Tiering

NAS Tiering
21 October 2024 6 min read

In primary storage devices such as NAS, there is unused or infrequently used data that remains relevant to the organization or must be
retained for future reference or regulatory compliance reasons. As a result, the growing data takes more space in primary storage, which has a
higher cost than secondary storage.

Cohesity supports the tiering of unused or infrequently used data from NAS primary storage to the Cohesity cluster. The process of moving
unused data from the primary NAS storage to the Cohesity cluster is called down-tiering. Based on a tiering policy the administrator sets while
creating a data tiering task, the data from the NAS primary storage that is unused or infrequently used is periodically moved to the Cohesity
cluster. When creating a data tiering task, the administrator determines how frequently the data tiering task runs and sets a tiering policy based
on various parameters, such as:

The last time the file was accessed

The last time the file was modified

The size of the file

The file type to be allowed or denied for down-tiering

Note:

Data tiering is supported only for NAS storage that is registered as mount points of type SMB or NFS.

Important:

By default, both Uptiering and orphan data deletion are disabled.

When data is tiered from the primary storage, a symbolic link is created for the original file. The name of this symbolic link is the same as that
of the original file, ensuring that users and applications continue to access the data as before. On a Windows server, local-to-local symbolic
links and local-to-remote symbolic links are enabled. However, remote-to-local symbolic links and remote-to-remote symbolic links are
disabled by default. Therefore you must run the following commands on the Windows server to enable the symbolic link access:

C:\Windows\system32>fsutil behavior set SymlinkEvaluation R2R:1

C:\Windows\system32>fsutil behavior query SymlinkEvaluation

If you are permanently moving the unused data to the Cohesity cluster, you can choose not to create this symbolic link after tiering while
creating a tiering task.

For NFS shares, for the user or applications to access the data that was tiered to the Cohesity View, the View needs to be mounted on the NFS
client. The mount path where the Cohesity View will be mounted on the host must be provided when you create the data tiering task. This
mount path cannot be changed later. All the NFS clients should use this mount path to mount the Cohesity View. For more information on
mounting a view using NFS, see Mount a View Using NFS.

Once the data is tiered to the Cohesity cluster, the subsequent read and write operations of the tiered data are performed on the Cohesity
server hosting the data.

A user with an admin role also can restore the tiered data back to the primary storage by mounting the Cohesity target (server hosting the
data) view on a Windows client and then copying the data.

Supported Sources for NAS Tiering

The following is the support matrix for NAS Tiering:

Source Protocol Without Stubbing With Stubbing

Unix/Linux NFSv3 Yes Yes

Windows SMB Yes Yes

NFSv3 Yes Yes

Cohesity SMB Yes Yes

S3 No No

MultiProtocol No No

Isilon NFSv3 Yes Yes

SMB Yes Yes

S3 No No

MultiProtocol No No

NetApp NFSv3 Yes Yes

SMB Yes No

S3 No No

MultiProtocol No No

Note:

Currently, you must add all sources as Generic NAS only.

Backups and Access to Older Versions of Tiered Files

NAS downtiering is not a replacement for backing up primary NAS storage.

Changes made to files in the target are not visible to the primary storage. Consequently, Cohesity recommends taking snapshots of the target
storage and replicating them, similar to the backup process for any SmartFiles content on Cohesity. You cannot restore these files from
snapshots on the primary storage but can recover them by mounting the target view.

Prevent Unintentional Access to the Target View

For symlinks to work, there needs to be a connection from the user's systems to the target. To facilitate backup and restore, the target view is
available in SmartFiles. You must choose a view name that indicates its purpose is solely for file recovery. If users mount the target and delete
files, the symlinks on the source will become inactive.

Considerations
Considerations
Cohesity does not support downtiering of junction points present on the NAS source.

If the down-tiering task was created in a version prior to 7.0 and if the Cohesity cluster is upgraded to 7.0, the down-tiering task is based
on the old policy. You cannot edit the down-tiering task. If you want to edit the down-tiering task, Cohesity recommends doing the
following:

Delete the previously created down-tiering task

Create a new down-tiering task

If the down-tiering task was created in a version prior to 7.0 and if the Cohesity cluster is upgraded to 7.0, the down-tiering task is based
on the old policy. You cannot edit the grouping of this down-tiering task. If you want to edit the grouping, Cohesity recommends doing
the following:

Delete the previously created down-tiering task

Create a new down-tiering task and edit the grouping

If you intend to use Mac clients to access data tiered with symbolic links, note that this is not supported.

If SMB permissions are modified on the original source, these changes are not fetched and applied to the data tiered on Cohesity.

Avoid utilizing NAS downtiering for home directories or datasets with active user modifications. If used for such cases, consider the
following:

When using Save As within certain applications after accessing the symlink, the new file is automatically written to the target instead of
the source by default. Consequently, when searching for such files later, you must check the target location.

Installer programs that delete themselves upon completion may erase the file in the target, rather than removing the symbolic link on
the primary. This results in a non-functional link remaining on the primary system.

Users with an older version of Windows 10 that does not support long path names might encounter difficulties when mass copying
files from the downtiered target for tasks such as manual uptiering or restoring older versions. To address this, a newer system that
supports long path names may be necessary to easily copy the files back.

Deleting the symbolic link will not automatically free up space on Cohesity.
Contact Cohesity Support to free up space.

Before 6.8.1_u7, commands existed to uptier and delete orphaned files — files whose symlinks were deleted or renamed by the user. If
a user moves or renames one of the Cohesity-created symlinks, the delete orphaned command removes the file from Cohesity, and
the uptier command restores the file under its old name, potentially overwriting a new file that reuses the original symlink name. To
mitigate this risk, uptier and delete orphaned commands were removed in 6.8.1_u7 or later versions. If link alterations may have
occurred, contact Cohesity Support to run diagnostics to identify and address such issues.