Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Dell PowerScale: SmartLock Best Practices > Automated data retention
SmartLock software delivers secure, powerful data retention in a simple, general-purpose NAS architecture that scales to petabytes. SmartLock is flexible and does not require application integration, specialized hardware, or a dedicated minimum storage capacity.
Because it is integrated with the OneFS file system, SmartLock is designed to work seamlessly with OneFS core capabilities and other key storage functions. These functions include snapshots, replication, provisioning, backup and restore, deduplication, and virtual environments. Integration with OneFS also means your retention environment can grow easily, with one file system to manage, from terabytes to over 80 petabytes in the same cluster.
SmartLock is implemented at the directory-level in the file system. With one cluster, you can store both general data and data with retention requirements, regardless of your capacity requirements or growth patterns. As capacity requirements increase, the entire cluster grows as a whole—you are not required to provision general data capacity separately from retained data capacity.
Most software-based retention solutions that work with traditional NAS systems require you to dedicate, at a minimum, an entire storage volume for data retention. Typically, this requirement includes a minimum capacity investment to get started and an incremental capacity investment every time you want to grow. Volume-based approaches also have maximum size limitations, forcing you to split data across multiple management points as you grow, increasing complexity and administration overhead.
OneFS combines traditional volume management, a file system, and RAID data protection into a flexible and powerful software layer that is space efficient and simple to manage and scale. Because OneFS does not rely on underlying RAID structures like volume groups, data management with OneFS is flexible and granular. This design means you can implement automatic data retention with any amount of data—from one file to billions of files.
After you create a directory and mark it as a SmartLock directory, files committed in this directory are immutable until their retention time expires. You cannot delete, move, or change these files. The administrator sets retention dates on files, and can extend them but not shorten them. When a file retention policy expires, it becomes a normal file that can be deleted as required, allowing you to reclaim that storage capacity for general-purpose or retained data.
For files that you place in a SmartLock directory, you can change or move them until they are committed. This design allows time for administrative changes and appends before the file becomes immutable. You can commit files to a SmartLock directory locally or over a network (by NFS or SMB/CIFS).
You can commit a file with write bits into the WORM state manually using one of the following two commands by removing write permissions:
# chmod a-w <file>
# chmod 444 <file>
To commit the file by SMB, in the Properties window of a file, check Read-only as shown in Figure 1.
Also, users can run the chmod command to commit a file into the WORM state from the OneFS command-line interface (CLI) without removing the write permissions of end users. This option alleviates the need for storage administrators to reenable the permissions for users to modify the files after the files have been released from WORM retention. To commit the file into the WORM state, add the readonly flag using the following command:
# chflags dos-readonly <file>
Note: When using the cp -p command to copy a file with a readonly flag from the OneFS CLI to WORM domains, the target file enters a WORM state immediately. You can remove readonly flags from source files before copying them using the cp -p command to WORM domains so that the target file will be uncommitted.
File retention times can be set in two ways: on a per-file basis, or using the directory default setting. If you set the retention date on the file basis and the directory default setting simultaneously, the file’s retention date overrides the directory default retention date. If you must have a specific file committed for a specific amount of time, you set that file’s retention date individually. For example, you can commit a file to be retained for seven days using the following command:
# touch -at `date -v+7d -j +”%y%m%d%H%M.%S”` <file_name>
Note: For an existing WORM state file, the administrator sets the retention date on a file basis, and they can extend it but not shorten it.
If data that is committed to a SmartLock directory must be retained for the same length of time, you can set the directory default setting to the required period. In this scenario, any file committed to that directory without a unique retention date takes that directory default.
Even after the retention date has expired, you cannot alter files that are protected with SmartLock while they remain in a SmartLock directory. You must copy these files to a non-SmartLock directory, and the target files become normal files for modification.
Note: In an enterprise SmartLock directory, the WORM state file can have the privileged delete capability within the retention period when the privileged delete is enabled.
In some situations, such as legal-discovery actions, you must guarantee that data remains protected until that specific situation is resolved. In these cases, a directory-level override of retention dates is available (the Override Retention Date). This override automatically extends the retention date of any file to or beyond the expected resolution time. This functionality only extends retention times, and files with retention times that are already beyond the scope of the override are not affected.
In Table 4, the Directory Default Retention Offset is one year for both example 1 and example 2. In example 1, any file that is committed to that directory and does not have a specific expiry date automatically gets a one-year expiry date from the date it is committed. This setting means that the SmartLock protection of a file that is committed on January 1, 2021 lasts until January 1, 2022, based on the one-year default setting. In examples 2 and 3, a specific retention date of February 1, 2022 is specified for a file. In these cases, the specific file-retention date takes precedence over any Directory Default Retention Offset period.
In example 4, the company receives a one-year litigation hold on all data that pertains to a case that is under investigation on December 31, 2021. The Override Retention Date setting at the directory level is used, and all data in that SmartLock directory is automatically protected through a minimum of December 31, 2022.
| Example 1: No file-retention date set | Example 2: File-retention date > directory offset | Example 3: Directory offset > file-retention date | Example 4: Litigation hold added |
File-retention date | None | February 1, 2022 | February 1, 2022 | February 1, 2022 |
Directory-offset retention date | 1 year | 1 year | 2 years | 1 year |
File-committed date | January 1, 2021 | January 1, 2021 | January 1, 2021 | January 1, 2021 (1-year litigation holds added on December 31, 2021) |
Expiration date | January 1, 2022 | February 1, 2022 | February 1, 2022 | December 31, 2022 |