ONTAP SnapLock Guide: WORM Storage, Compliance Clocks & Legal Hold

SnapLock overview: Compliance vs Enterprise

SnapLock is an integral ONTAP feature designed to meet stringent data retention and compliance requirements. ONTAP supports two distinct SnapLock operational modes configured at the aggregate and volume levels:

The ComplianceClock: Tamper-proof time

To prevent administrators or malicious actors from bypassing WORM retention by rolling back system or NTP clocks, SnapLock relies on a hardware-backed ComplianceClock on each storage controller:

• Independent Tick: Once initialized, the ComplianceClock advances independently of standard system/NTP time.
• Drift Prevention: Even if system NTP time is altered or desynchronized, the ComplianceClock guarantees that files remain protected until true chronological time has passed.
• Initialization Requirement: You must initialize the ComplianceClock on every node before creating SnapLock aggregates or volumes.
• ONTAP 9.14.1+ Reinitialization: Starting with ONTAP 9.14.1, administrators can reinitialize or reset the ComplianceClock if no active SnapLock volumes or locked snapshots exist on the cluster (resolving accidental early lab setup mistakes).

::> snaplock compliance-clock show
Node        System Time               ComplianceClock Time      Drift
----------- ------------------------- ------------------------- ---------
cluster1-01 Thu Aug 27 10:15:00 2026   Thu Aug 27 10:15:00 2026   0s
cluster1-02 Thu Aug 27 10:15:00 2026   Thu Aug 27 10:15:00 2026   0s

# Initialize ComplianceClock on a new node (one-time setup per controller)
::> snaplock compliance-clock initialize -node cluster1-01

SnapLock volume provisioning runbook

1. Create the SnapLock aggregate (if applicable)

::> storage aggregate create -aggregate aggr_sl_comp01 -node cluster1-01 -diskcount 12 -snaplock-type compliance
[Job 112] Aggregate "aggr_sl_comp01" created with SnapLock Compliance mode.

2. Provision the SnapLock volume

::> volume create -vserver vs_compliance -volume vol_records_sl -aggregate aggr_sl_comp01 -size 5TB -snaplock-type compliance
[Job 113] Volume "vol_records_sl" created with SnapLock Compliance mode enabled.

3. Verify SnapLock attributes

::> volume snaplock show -vserver vs_compliance -volume vol_records_sl
Vserver Name: vs_compliance
Volume Name: vol_records_sl
SnapLock Type: compliance
Default Retention Period: 30days
Minimum Retention Period: 0days
Maximum Retention Period: 30years
Autocommit Period: none
Privileged Delete: disabled
Is Volume Ready for Downgrade: false

Retention policies: Min, max & default periods

Every SnapLock volume enforces retention boundary limits. When a client application or script commits a file to WORM without explicitly setting a retention date in its filesystem access time (atime), the volume's -default-retention-period applies automatically:

::> volume snaplock modify -vserver vs_compliance -volume vol_records_sl \
    -minimum-retention-period 30days \
    -maximum-retention-period 7years \
    -default-retention-period 3years

• Minimum Retention: Rejects or clamps any client commit request specifying a shorter duration than this threshold.
• Maximum Retention: Rejects or clamps any client commit request exceeding this ceiling.
• Default Retention: Applied whenever a file's read-only bit is set without modifying its atime.
• Infinite Retention: Supported for files that must never expire unless released manually (common for permanent corporate archives).

Committing files to WORM & Autocommit

A standard file becomes a WORM file through one of three operational pathways:

1. Application atime Modification: An archiving application writes the file, sets the POSIX/NTFS atime to the desired expiry timestamp in the future, and sets the file to read-only (e.g., chmod 444 or attrib +r).
2. Autocommit Period: ONTAP automatically transitions unchanged files to WORM state if they remain unmodified for a configured time interval.
3. SnapLock Append Mode (WORM-appendable): Allows append-only files (such as database audit trails or security logs) to append data incrementally until sealed.

# Enable autocommit to lock files 2 hours after last write:
::> volume snaplock modify -vserver vs_compliance -volume vol_records_sl -autocommit-period 2hours

Legal hold & litigation management

When legal proceedings or regulatory audits arise, administrators can place specific files, directories, or entire volume paths under Legal Hold. A file under legal hold cannot be deleted even after its normal SnapLock retention period has elapsed, remaining immutable until the legal hold is explicitly released.

# 1. Begin legal hold for pending litigation
::> snaplock legal-hold begin -vserver vs_compliance -litigation-name Litigation_Case_2026A \
    -volume vol_records_sl -path /contracts/2024/

# 2. View active legal holds across the SVM
::> snaplock legal-hold show -vserver vs_compliance -litigation-name Litigation_Case_2026A
Vserver       Litigation Name      Volume           Path
------------- -------------------- ---------------- ---------------------
vs_compliance Litigation_Case_2026A vol_records_sl   /contracts/2024/

# 3. Release legal hold upon case conclusion
::> snaplock legal-hold end -vserver vs_compliance -litigation-name Litigation_Case_2026A \
    -volume vol_records_sl -path /contracts/2024/

Privileged delete in SnapLock Enterprise

SnapLock Enterprise (SLE) allows organizations to delete unexpired WORM files when required by data privacy mandates (such as GDPR "Right to be Forgotten") or accidental data contamination. Privileged delete is strictly audited and requires a dedicated user role:

# 1. Enable privileged delete on the SnapLock Enterprise volume
::> volume snaplock modify -vserver vs_enterprise -volume vol_archive_sle -privileged-delete enabled

# 2. Create the specialized SnapLock security admin account
::> security login create -vserver cluster1 -user-or-group-name sl_sec_admin \
    -application ontapi|ssh|http -authmethod password -role vsadmin-snaplock

# 3. Log in as the privileged user and perform the file deletion
::> volume snaplock file privileged-delete -vserver vs_enterprise -volume vol_archive_sle \
    -path /user_profiles/case_9824/pii_records.pdf

Event-Based Retention (EBR)

Standard retention starts from file creation, but many business records (employee personnel files, mortgage contracts, lease agreements) require retention to start only when a specific business event occurs (e.g., employee termination or loan payoff). Event-Based Retention (EBR) policies link custom event policies to target directories:

# Create an EBR policy for loan lifecycles
::> snaplock event-retention policy create -vserver vs_compliance -policy-name Employee_Termination \
    -retention-period 7years

# Apply the EBR event trigger to an employee directory upon contract conclusion
::> snaplock event-retention apply -vserver vs_compliance -policy-name Employee_Termination \
    -volume vol_records_sl -path /personnel/emp_10482/

SnapLock audit logging configuration

Regulatory frameworks require an unalterable audit trail of all SnapLock operations, including clock updates, retention changes, privileged deletes, and legal hold executions. SnapLock logs are themselves stored in a dedicated SnapLock Compliance volume:

# 1. Create a dedicated log volume
::> volume create -vserver vs_compliance -volume vol_snaplock_audit -aggregate aggr_sl_comp01 \
    -size 500GB -snaplock-type compliance

# 2. Configure the audit log infrastructure
::> snaplock log create -vserver vs_compliance -volume vol_snaplock_audit \
    -max-log-size 20MB -default-retention-period 5years

# 3. Verify audit log operational state
::> snaplock log show -vserver vs_compliance
Vserver: vs_compliance
Log Volume: vol_snaplock_audit
Max Log Size: 20MB
Default Retention Period: 5years
Log Archive Interval: 1days

SnapLock in lab environments & simulator

When validating SnapLock workflows on the ONTAP Simulator or ONTAP Select in non-production labs, be aware of specific constraints:

• ComplianceClock Initialization: The simulator supports full ComplianceClock and SnapLock volume creation, but simulated hardware lacks battery-backed NVRAM/RTC tamper isolation.
• Irreversible Test Volumes: Creating a SnapLock Compliance volume on a simulator aggregate will permanently prevent deleting the aggregate until all volume retentions expire. Use -snaplock-type enterprise in test environments to allow clean teardown via privileged delete.
• Clock Drift Testing: Advancing the simulator hypervisor or host OS clock will cause ComplianceClock drift warnings and cannot artificially accelerate Compliance WORM expiry.

Frequently asked questions

Can a SnapLock Compliance volume be converted to SnapLock Enterprise?

No. Once a volume or aggregate is created as SnapLock Compliance, it cannot be converted to Enterprise or non-SnapLock storage. The mode is immutable by design.

Can SnapLock volumes be replicated with SnapMirror?

Yes. SnapLock volumes can be replicated using SnapMirror (SnapLock-to-SnapLock replication) to maintain WORM guarantees across primary and secondary disaster recovery sites.

Does SnapLock protect against ransomware attacks?

Yes. SnapLock immutable storage and Snapshot locking prevent ransomware payloads and compromised administrative credentials from encrypting, truncating, or deleting protected files and recovery snapshots.

Can SnapLock volumes use FabricPool cloud tiering?

Yes. Beginning in ONTAP 9.8+, SnapLock Enterprise and Compliance volumes support FabricPool tiering to cloud object storage (such as NetApp StorageGRID, AWS S3, or Azure Blob) while preserving end-to-end WORM immutability.