Snapshot Settings
Overview
When a security event reaches a lockout threshold, the system automatically takes snapshots of the file shares accessible to the affected user. These snapshots serve as recovery points — they preserve the state of the data at the moment of detection, so that even if files were encrypted or deleted before the lockout was applied, a clean version can be recovered.
Snapshot settings are configured in Detection Controls → Settings → Snapshot Settings.
Snapshot settings on this page apply to PowerScale (OneFS) only. ECS uses bucket versioning for recovery instead of filesystem snapshots — see Lockout Settings — ECS versioning and recovery.
SMB and NFS snapshot behavior
By default, the system takes snapshots on both SMB and NFS share paths when a security event triggers a lockout.
SMB snapshots are taken on every SMB share the affected user has access to, determined by their Active Directory group membership at the time of the event. The snapshot is taken at the share path level — the entire share is snapshotted, not just the files the user touched.
NFS snapshots follow the same logic for NFS export paths the user has access to via IP-based access. NFS snapshotting is included by default when NFS is selected in the protocol settings.
To configure which protocols are snapshotted: Go to Detection Controls → Settings → Snapshot Settings → Select Protocols to Snapshot. Choose SMB, NFS, or both. The default is both.
Snapshot expiry: Snapshots taken during a security event expire after 48 hours by default. This gives administrators sufficient time to assess the event and initiate file recovery before the snapshot is deleted. Snapshots can be manually deleted earlier to free quota using the Snapshots tab on the Investigate & Recover page.
To change the default expiry from the UI: Set Hours Until Expiry in Detection Controls → Settings → Snapshot Settings (New GUI). The equivalent field in the Old (legacy) GUI is on the Ransomware Defender Settings → Snapshots screen, under General Settings.
To change the default expiry from the CLI: SSH to the Eyeglass appliance and run:
igls rsw generalsettings set --snapshot_expiry_hours <hours>
For example, igls rsw generalsettings set --snapshot_expiry_hours 72 extends the default to 72 hours. Run igls rsw generalsettings with no arguments to view all current Ransomware Defender settings, including the current expiry value.
If you change any setting in Detection Controls → Settings → Snapshot Settings and save it from the UI, a custom expiry set via the CLI command above is reverted back to the 48-hour default (or to whatever value is currently set in the UI). Re-apply the CLI command after making UI changes if you need a non-default expiry.
To extend the expiry of an already-created event's snapshots (rather than changing the default for future events), use Retain Snapshots directly from the event — see Retain Snapshots. Snapshots already extended this way are no longer governed by Hours Until Expiry — their expiry is whatever Retain Snapshots set, independent of later changes to the default.
Snapshot Reuse and Deduplication
Before creating a new snapshot for a Ransomware Defender or Active Auditor event, Eyeglass checks whether a suitable snapshot already exists for the same (or a parent) share/export path, on the same storage node, created within a configurable reuse window. If one exists, Eyeglass reuses it instead of creating a new snapshot on PowerScale — cutting down on redundant PowerScale calls and unnecessary snapshot volume when multiple events or users trigger snapshot creation on the same path in quick succession.
How matching works:
- Path matching compares the share/export path as text — a snapshot for a parent path (for example,
/ifs/data/share) is reused for a later request on a subfolder of that path, but not for an unrelated path. - Matching is scoped per storage node/cluster — a snapshot on one PowerScale cluster is never reused for a path on a different cluster, even if the path string is identical.
- Manually triggered snapshots (created directly from the UI rather than automatically by an event) always bypass reuse and create a new snapshot.
- This mechanism currently applies to PowerScale (OneFS) snapshots only. Other supported storage platforms create a snapshot per event as before.
- Applies equally to Ransomware Defender events and Active Auditor events — both use the same setting and reuse logic. See Active Auditor snapshots below.
Configuring the reuse window:
The reuse window is controlled by the rsw_snapshot_reuse_minutes setting in system.xml (default: 60 minutes). It's measured from the moment a snapshot is first created, not from when it was last reused — reusing a snapshot does not reset or extend its window. Once the window elapses since original creation, the next job creates a new snapshot regardless of how many times the previous one was reused in between. Setting the value to 0 disables reuse entirely, so a new snapshot is always created.
The reuse window is tracked in memory and is cleared on an Eyeglass/NDE service restart or upgrade. Immediately after a restart, the next event for a given path creates a new snapshot even if a still-valid, recently created snapshot for that path already exists — reuse resumes normally for events afterward. You may see one extra snapshot right after a restart or upgrade even if a recent one already existed for that path.
Snapshot budget logic
The Snapshot Quota setting controls the maximum number of snapshots the system is permitted to maintain across the cluster at any time. The default value is 500.
When a security event triggers, the system evaluates the current snapshot count before creating any new snapshots. The evaluation follows this logic in order:
| Condition | Result |
|---|---|
Current snapshots X > quota SB | No snapshots taken. Quota already exceeded. |
X + C > SB (critical-path snapshots alone would exceed quota) | No snapshots taken. |
X + C ≤ SB but X + C + U > SB | Critical-path snapshots taken only. User-share snapshots skipped. |
X + C + U ≤ SB | All snapshots taken normally. |
Where:
- SB = configured snapshot quota
- X = current number of snapshots on the cluster
- C = number of critical-path snapshots required for this event
- U = number of user-share snapshots required for this event Practical implication: When the cluster is near quota, the system always prioritizes critical-path snapshots over general user-share snapshots. This ensures your most important data paths are always protected, even when overall snapshot capacity is constrained.
To adjust the quota: Change the Snapshot Quota value in Detection Controls → Settings → Snapshot Settings. Set it according to the storage capacity of your cluster and the typical number of security events you expect. Monitor actual snapshot counts in the Snapshots tab on the Investigate & Recover page.
Critical-path snapshots
Critical-path snapshots are snapshots taken on specific, designated share paths regardless of whether the user involved in the event has direct access to those paths. They are always taken when a lockout occurs and are prioritized over user-share snapshots in the budget evaluation.
When to use critical-path snapshots: Use this feature in environments where users have access to a very large number of shares and snapshot quota would be exhausted by snapshotting all of them. By designating your most important paths as critical, you guarantee those paths are always snapshotted — even in high-share-count environments where the user-share quota logic would otherwise skip them.
How to identify your critical paths: Designate paths that meet one or more of the following criteria:
- Financial records, HR data, legal files, or compliance-governed data
- Application or service data required for daily business operations
- Data with tight RPO/RTO requirements
- Data that is not replicated, backed up externally, or otherwise protected by other means To configure critical-path snapshots:
- Go to Detection Controls → Settings → Snapshot Settings.
- Enable the Take Snapshots for Critical Paths Only toggle.
- Choose which protocols to enable for critical-path snapshots — SMB, NFS, or All.
- Click + Critical Path, select the managed device the path belongs to, and enter the path. Repeat for each path you want to designate as critical.
This toggle-and-path-entry workflow in the new Settings tab is the complete configuration — no additional CLI steps are required.
Recommendation: In environments where all users have access to all shares and permissions are managed primarily at the NTFS level, and where the number of shares is large, enable critical-path snapshots only and disable all user-initiated snapshots for both SMB and NFS. This prevents quota exhaustion and ensures consistent protection for the paths that matter most.
Active Auditor snapshots
Security events triggered by Active Auditor policies (Mass Delete, Data Loss Prevention, Custom Triggers) also trigger automatic snapshot creation, using the same snapshot settings configured in this section.
When an Active Auditor event triggers a snapshot, the snapshots are taken on the SMB share paths of all shares the affected user has access to, based on their Active Directory group membership. The snapshot expiry, quota, and reuse/deduplication logic are identical to Ransomware Defender events, governed by the same rsw_snapshot_reuse_minutes setting.
Enable the Active Auditor Snapshots toggle on Detection Controls → Settings → Snapshot Settings for automatic snapshots to be created when an Active Auditor trigger's threshold is exceeded.
Active Auditor events (Mass Delete, Data Loss Prevention, Custom Triggers) snapshot SMB share paths only. Active Auditor policies are supported for SMB only, so there are no NFS paths to snapshot for these events.
Ransomware Defender events snapshot both SMB and NFS paths by default, per the protocol selection described in SMB and NFS snapshot behavior above.
CLI commands to manage snapshots
The default expiry for event snapshots can also be set from the CLI — see Snapshot expiry above (igls rsw generalsettings set --snapshot_expiry_hours <hours>).
Listing and deleting individual event snapshots is a UI-only workflow — see Investigate & Recover — Snapshots Tab. The CLI setting above only controls the cluster-wide default expiry.
See also
- Lockout Settings — How lockout is triggered and what it does.
- Threat Response, Lockout and Snapshots — Overview of the full threat response (lockout + snapshots).
- Retain Snapshots — Extending the expiry of an active event's snapshots directly from the event.
- Investigate & Recover — Snapshots Tab — How to view, use, and delete snapshots from within an active event.
- Health Check — Security Guard — How to validate that snapshots are being created