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…….
