Recovery

What Recovery Manager does

Recovery Manager orchestrates data recovery after a confirmed ransomware event. It uses the snapshots taken at the time of detection — along with any pre-existing snapshots on your PowerScale cluster — to identify which affected files can be restored, and then automates the restoration process.

Recovery Manager extends beyond simple file recovery with an automated quarantine feature: when recovering files, it moves the affected (encrypted or renamed) versions to a hidden quarantine location for forensic analysis, while simultaneously restoring the original clean versions from the most recent valid snapshot. This means:

• The ransomware-affected files are isolated and invisible to end users.
• The original clean files are restored to their original paths.
• The quarantined files remain accessible to security teams for investigation.

Recovery Manager is available on the Items & Recovery tab of the Investigate & Recover page, and also through the Actions menu on the Threat Detections page for both active events and archived events that still have an active audit cache.

Quick path: Threat Detections → open the event's detail slide-out → Investigate & Recover → Items & Recovery tab → select items → Recover.

For snapshot-selection logic (including the AWS/ECS versioning case), the quarantine/forensics workflow, and ECS-specific behavior, see the dedicated Recovery Manager Configuration page.

Prerequisites

• Eyeglass version 2.5.9 or later.
• An Eyeglass DR license (for inventory and snapshot management).
• An Eyeglass RWD (Ransomware Defender) license (for event detection).

Platform-specific setup and differences

PowerScale

The steps in this page apply as written. No additional platform-specific setup is required beyond the prerequisites above.

ECS

While the Recovery Manager UI for ECS closely mirrors the PowerScale interface, there are a few important distinctions:

• Instead of cluster information, the interface shows bucket and region details, along with the bucket's versioning status.
• Bucket users must be added to Inventory for their activity to appear in Recovery Manager.
• The system.xml parameter <versioningEnabled> has a UI performance trade-off: setting it to true displays the Earliest Recoverable Version Time column but can significantly slow UI load times; setting it to false displays Bucket Versioning Status instead and loads faster.

Basic setup:

1. Enable versioning on the target bucket (for example, in S3 Browser) and confirm file versions are visible.
2. In Eyeglass, add the bucket user to the node in Inventory.
3. Set the versioningEnabled property inside the <process> tag of /opt/superna/sca/data/system.xml according to which column you want displayed (see above).

Sorting and filtering: As with PowerScale, Recovery Items are sorted by the timestamp of the first event associated with the item. Recovery Items can be filtered by bucket, path, and status.

Status options:

• When versioningEnabled is true: RECOVERED, RECOVERABLE, NO_RECOVERABLE_VERSION, NO_VERSIONS_EXIST, UNKNOWN.
• When versioningEnabled is false: RECOVERED, UNRECOVERED.

Submitting a recovery job: ECS has no single RENAME_OBJECT event. A rename is represented as two separate events: DELETE_OBJECT (removing the old name) and COPY_OBJECT (creating the new name). Select both events when submitting a recovery job involving a renamed object, or the recovery will be incomplete.

Example: present1.locky is renamed to present2.locky. The DELETE_OBJECT event removes present1.locky; the COPY_OBJECT event creates present2.locky. Selecting both ensures the renamed file is fully covered by the recovery job.

Data retention and audit cache

Recovery Manager uses a cached history of user activity from one hour before the event was detected. Retention depends on the event's status: active events retain user activity for 120 days; once an event is closed, retention drops to 3 days.

Best practice: Don't close an event until its data has been recovered. Closing drops the retention window from 120 days to 3 days, and you cannot recover items once user activity has expired — so closing early can permanently remove your ability to recover.

Important: If the cache is purged, the Recovery Manager option is no longer available for archived events in History.

To adjust the retention period, on ECA Node 1, edit /opt/superna/eca/eca-env-common.conf:

• ECA_KAFKA_USER_ACTIVE_TOPIC_RETENTION_DAYS — how long user activity is stored for active events.
• ECA_KAFKA_USER_TOPIC_RETENTION_DAYS — how long user activity is stored for closed events.

nano /opt/superna/eca/eca-env-common.conf

Set the desired value(s), save and exit (Ctrl + X), then restart the cluster for the change to take effect:

ecactl cluster down
ecactl cluster up

Recoverability — how it works

A file is recoverable if a snapshot exists that was taken before the attack affected that file.

Example:

• A file /ifs/data/report.docx is renamed to /ifs/data/report.docx.blacksuit at 3:00 PM.
• A snapshot of /ifs/data/ was taken at 2:00 PM.
• Result: The file is recoverable — the pre-attack version exists in the snapshot.

Example (unrecoverable):

• The only available snapshot was taken at 3:05 PM, after the rename occurred.
• Result: The file is unrecoverable — no snapshot contains the original version.

Best practice: Configure regular scheduled snapshots on your critical data paths outside of Ransomware Defender's automatic snapshot creation. Automatic event snapshots capture the state at the moment of detection — but if the attack had been running for some time before detection, several files may already have been affected before the snapshot was taken. An older scheduled snapshot may cover files that the automatic snapshot missed.

Using Recovery Manager

Step 1 — Access Recovery Manager

1. Navigate to Threat Detections, click the event to open its detail slide-out, and select Investigate & Recover.
2. Select the Items & Recovery tab.
3. The recovery statistics and file list are displayed. The Recalculate Snapshots button refreshes the snapshot availability assessment using the most current inventory.

Step 2 — Review recovery statistics

The summary bar shows:

• Recoverable — files with a valid pre-attack snapshot (shown with a green indicator)
• Unrecoverable — files without a usable snapshot (shown with a red indicator)
• Recovered — files already successfully restored (shown with a green checkmark)

Step 3 — Browse and filter affected files

The folder tree on the left lets you navigate the affected directory structure. Click any folder to filter the file list to that location.

The Search folders field allows you to find specific paths within the tree.

Each file in the list shows:

• Full path
• Event type (for example: Copy, Rename, Delete)
• New extension (if the file was renamed with a ransomware extension)
• Event time
• Last version available (a clickable timestamp if a recoverable snapshot exists, or No Version Available)

You may see both the original filename and the renamed version (for example, report.docx and report.docx.blacksuit) in the list. This is expected — Recovery Manager shows all file activity associated with the event. The total file count may be higher than expected for this reason.

Step 4 — Select files to recover

Use the checkboxes to select individual files. To select all files on the current page, use Select Page. To select all files across all pages, use Select All.

Use the pagination controls to browse through all available files before making a final selection.

Step 5 — Recover

Click Recover. A confirmation dialog appears — click Yes to proceed.

Recovery Manager starts a background job. Monitor progress in the Jobs section of the left sidebar. Expand the job steps to see detail on each operation.

Recovery Manager automatically:

1. Moves the ransomware-affected file versions to a hidden quarantine location.
2. Restores the original file versions from the most recent valid pre-attack snapshot to their original paths.
3. Marks recovered files with a checkmark in the file list.

Recovery Manager selects the appropriate snapshot for each file individually — not all files in a single recovery job will necessarily use the same snapshot. This is normal and correct behavior.

Step 6 — Monitor and verify

After recovery completes:

• Files marked with a checkmark have been successfully restored.
• Switch the filter to Recovered to see all restored files.
• Verify with users that they can access the restored files correctly.

Step 7 — Close the event

After recovery is complete and user access has been restored, close the event using the Close Event wizard and select Close as Threat. This records the event as Threat Confirmed. See Closing Event for the full wizard walkthrough.

Cache and inventory notes

Recovery Manager's recoverability assessment is based on the most recent snapshot inventory. If new snapshots have been taken since you opened the page — for example, if you manually created additional snapshots — click Recalculate Snapshots to refresh the assessment. The page may initially show files as unrecoverable that become recoverable after recalculation.

Eyeglass becomes aware of new snapshots only after inventory is run. If Recovery Manager is accessed before inventory has been updated, the recoverability display may be incomplete. Click Recalculate Snapshots to force a refresh.

See also

• Recovery Manager Configuration — Snapshot-selection logic, quarantine/forensics workflow, and platform-specific decision logic (PowerScale and ECS).
• Lockout Settings — ECS object storage lockout — ECS bucket-versioning recovery in the context of lockout and restoration.
• Event Processing and Actions Available — The Actions menu, including Create Snapshot and Retain Snapshots.
• Snapshots Tab — Review the snapshots taken automatically when the event was detected.
• Assets Tab — Confirm the DENY permission has been removed after restoring access.
• Closing Event — Close the event as Close as Threat after recovery completes.
• Snapshot Settings — Snapshot budget logic and critical-path configuration.
• Threat Detections — Overview — Terminology and the severity-by-severity triage workflow.