NETAPP_SNAPLOCK

NETAPP_SNAPLOCK

One day I was giving an technical interview, in which interviewer asked me a question, it was related to NetApp storage technology, and the question was that what is the “Compliance volume”, I got stuck and was not able to give any reply, because I was not aware of compliance volume, so after the interview got finished, I star searching for the compliance volume in NetApp and then I found that compliance volume is also know or called as snap lock volume.

I knew about snap lock volume in NetApp, but I did not know that the snap lock volume is also known as compliance volume.

After getting rejected in that interview, I thought of writing something about the snap lock volume, as the snap lock is not much used in most of the companies, so most of the NetApp administrator is not aware of this feature in NetApp and some who knows about this feature have not used it.

SnapLock is NetApp WORM (Write Once Read Many)

Some regulated environment require business records be archived on WORM media to maintain a non-erasable and nonrewritable electronic audit trail that can be used for discovery or investigation.

DataONTAP SnapLock software complies with the regulations of those markets. With SnapLock, the media is rewritable but the integrated hardware and software controlling access to the media prevents modification or deletion.

SnapLock is available in tow version: SnapLock compliance for strict regulatory environment, and SnapLock Enterprise, for more flexible environments.

SnapLock can integrates with the snap Mirror and snap vault, and snap mirror allows the SnapLock volumes to be replicated to another storage system and Lock vault backs up SnapLock volumes to a secondary storage system to ensure that if the original data is destroyed than the data can be restored or accessed from another location.

Once the data is created in the SnapLock volume they comes under the retention period and these files get treated as WORM, so that nobody can delete or modify the data until and unless it reach to its retention period, the SnapLock volumes cannot be deleted by the user, administrator nor by the application, the retention date on a WORM file is set when the file is committed to WORM state, but it can be extended at any time. The retention period can never be shortened for any WORM file.

SnapLock Compliance (SLC)

SnapLock Compliance is used in strictly regulated environment, where data is retained for longer period of time and these data are accessed frequently only for readable purpose.

SnapLock Compliance even does not allow the storage administrator’s to perform any operations that might modify the file, it uses the feature called “ComplianceClock” to enforce the retention periods. SnapLock Compliance requires the SnapLock license to enable the SnapLock features and to restrict the administration access to the file.

SnapLock Enterprise (SLE)

SnapLock Enterprise allows the administrator to destroy the SnapLock volume before all the file on the volume reach their expiration date. However no one else can delete or modify the files.

It requires the SnapLock _enterprise license

NOTE:

1.       From dataontap 7.1 and later, SnapLock compliance and SnapLock Enterprise can be installed on the same storage system.

2.       Uninstalling the SnapLock license does not undo the SnapLock volume or the Worm file properties. When uninstalling the license, existing SnapLock volumes are still accessible for general reading and writing, but won’t allow new files to be committed to WORM state on the SnapLock volume, or the creation of any new SnapLock volumes.

SnapLock Configuration Steps

1.       Verify that the storage systems time zone time and date are correct.

2.       License SnapLock.

3.       Initialize  the compliance clock

4.       Create SnapLock aggregate and volume.

5.       Set retention periods

6.       Create files in the SnapLock volume

7.       Commit files to a WORM stat.

Use the “date –c initialize” command to initialize the compliance clock.

After compliance clock is initialized, it cannot be altered and WORM files, SnapLock compliance volumes, or aggregates cannot be destroyed. As compliance volume get in sync mode with the system clock, so when the volumes is taken offline then the compliance volume will get out of sync with the system clock, but when the volumes is brought online back the data ontap will start to make up the time difference, the rate at which the compliance clock catches up depends on the version of data ontap your system is running.

Creating the snaplock volumes

Snaplock type, compliance or Enterprise, is determined by the installed license.

 

Creating the snap lock traditional volumes

“vol create –L vol_name <n_disk>”

 

For ex :

System> vol create viptrd –L 14

 

For creating the SnapLock flexible volumes, you need to create the snaplock aggregate first

 

“aggr create –L aggr_name <n_disks>”

“vol create vol_name aggr_name <size>”

 

For ex:

System> aggr create vipaggr –L 3

System> vol create vipflex  vipaggr 100m

System> vol status vipflex (for checking the status of the vipflex volume)

 

Volume Retention Periods.

The retention periods are the volume’s attributes. If you do not explicitly specify an expiration date for a WORM file, the file inherits the retention periods set at the volume level.

 

There are three retention periods per volume: a minimum, a maximum and a default.

1.       Until you explicitly reconfigure it, the maximum retention period for all WORM files in a snap Lock Compliance volume is 30 years.

2.       If you change the maximum retention period on a SnapLock Compliance volume, you also change the default retention period.

3.       If you change the minimum retention period on a SnapLock Enterprise volume you also change the default retention period. The minimum retention period is 0 years.

How to set the Retention Periods.

Use the vol options command to set the retention period values.

For ex:

System> vol options vol_name snaplock_minimum_period [{period} |min |max | infinite <count>d|m|y]

System>vol options vipvol snaplock_minimum_period 1d

System> vol options vipvol snaplock_default_period min

Min is the retention period specified by the snaplock_minimum_period option, max is the retention period specified by the snaplock_maximum_period option, infinite specifies that files committed to WORM state are retained forever.

For storage system using dataOntap 7.1 and later , the maximum retention period can be extended up to 70 years.

You can also extend the retention date for a WORM file before or after the file retention date has expired by updating its last accessed timestamp. This will re_enable WORM protection on the file as if it were being committed for the first time. Once the retention date expires, you can re_enable the write permission on the file and then delete it. However the file contents still cannot be modified.

Note: the SnapLock volume maximum retention period restrictions are not applied when extending the retention date of a WORM file.

Committing Data to WORM

After placing a file on a snaplock volume, the file attributes must be explicitly changed to read-only before it becomes a WORM file. These operations can be done interactively or programmatically, the exact command or program required depends on the file access protocol (CIFS, NFS, and so on) and client operating system being used.

Below command could be used to commit the document .txt file to a WORM state, with a retention date of November 21,2020 ,using a unix shell.

touch –a –t 202011210600 document.txt

chmod –w document.txt

For a windows client, to make a file read-only, right-click the file, select properties, checks the read only checkbox and then clicks OK.

The last accessed timestamp of the file at the time it is committed to WORM state becomes its retention date unless it is limited by the minimum or maximum retention period of the SnapLock volume. If the date was never set, the default retention period of the SnapLock volume is used.

If a file is initially copied read-only, it is not automatically committed to WORM state. The only way to guarantee that a file is committed to WORM state is explicitly assign a read-only attribute and optionally modify the last access time to set a retention date while the file is in the SnapLock volume.

Auto-Committing Files.

A time-delay commit to WORM with an adjustable timer is available in Data Ontap 7.2 or later. If the file does not change during the delay period, the file is committed to WORM at the end of the delay period. Auto-commit does not take place instantly when the delay period ends. Auto-commit are performed using a scanner and can take some time. The retention date on the committed file will be determined by the volume’s default retention period.

To specify a time delay, set the global option snaplock.autocommit_period to a value consisting of an integer count followed by an indicator of the time period: “h” for hours, “d” for days. “m” for months, or “y” for years.

System> options snaplock.autocommit_period none | [count (h | d | y)]

The default value is none and the minimum delay that can be specified is two hours.

The following example sets the auto-commit period to 24 days.

System> options snaplock.autocommit_period 24d

Appending WORM File

A WORM file can be appended by simple creating an empty Snaplock file, appending data to it, and then locking the file in place again, data is committed to WORM state in 256 Kb chunks; the previous 256 kb segment automatically becomes immutable. This procedure can be done from ontap7.1 onward.

For ex:

1.       Inside a WORM volume create a zero-length file with the desired retention date.

touch  -a  -t  202012150600 file

 

2.       Update the file access time to indicate the file’s desired expiration.

 

3.       Make the file read-only.

chmod 444 file

 

4.       Make the file writable again.

chmod 755 file

 

5.       Start writing data to the file.

echo test data > file

 

at this stage you have a WORM appendable file. Data is committed to WORM in 256 kb chunks. Once data is written to byte n*256K+1 of the file, the previous 256Kb segment is in a WORM state and cannot be rewritten.

 

6.       Make the file read-only again. The entire file is now in the WORM state and cannot be overwritten or erased.

chmod 444 file

 

Deleting WORM volumes and Aggregates

 

You cannot delete SnapLock compliance volumes that contain unexpired WORM data. You can delete the volume only when all the WORM files have passed their retention dates.

 

Note: If a compliance volume cannot be destroyed, it remains offline. It should be immediately brought online so that retention period problem can be fixed and to keep the complianceclock from falling behind.

 

You can destroy the compliance aggregates if they don’t contain volumes. The volume contained by a snaplock compliance aggregate must be destroyed first.

 

You can destroy snaplock Enterprise volumes at any time, provided you have the appropriate authority.

 

………..if you like this blog please comment……..Thanks…….