Recovery Manager Configuration

Introduction

Recovery Manager restores data affected by a confirmed ransomware event, using snapshots taken at the time of detection along with any pre-existing snapshots on the cluster. It is available on the Items & Recovery tab of the Investigate & Recover page, and through the Actions menu on the Threat Detections page.

For the current step-by-step procedure — accessing Recovery Manager, reviewing recovery statistics, filtering affected files, and running a recovery job — see Recovery on the Threat Detections page. This page covers the durable reference material that page doesn't: how Recovery Manager decides which file version to restore, the quarantine/forensics workflow, and platform-specific behavior for both PowerScale and ECS.

Example

• A file /ifs/test/document.txt is renamed to /ifs/test/document.locky at 5:00 PM.
• A snapshot was taken on the path /ifs/test/ at 4:00 PM. Result: The file is recoverable.
• If the only snapshot is from 5:03 PM and no earlier snapshot exists, the file is not recoverable.
• If a snapshot exists on a different path, such as /ifs/otherpath/, but not for /ifs/test/, the file is unrecoverable.

Prerequisites

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

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

Recovery Manager Availability

• For active events, the Recovery Manager option is always available from the event's Actions menu.
• For archived events in the History tab, Recovery Manager is available only if the event's underlying Kafka topic (its cached audit history) still exists — that is, only within the retention window described above.

Understanding Kafka topics

A Kafka topic is a message queue where audit records for each event are temporarily stored. When a new event is raised in Ransomware Defender, recent audit logs are searched to gather the affected user's activity from the hour before the event, and this information is saved to a Kafka topic. Once the retention period elapses, the topic is deleted automatically — after which Recovery Manager can no longer be opened for that archived event, and the event's Activity Log tab shows only a limited activity sample rather than the full file list.

How Recovery Manager Determines Which Version to Restore

When a ransomware event is raised, Recovery Manager tracks all activity by the bad actor starting from one hour before the event.

Recovery Manager compiles a list of every file — or object, in the case of ECS — that the bad actor modified. Modifications include writing to files or objects, creating new ones, deleting existing ones, and renaming them.

For each file or object, Recovery Manager identifies the snapshot that was created before the event and restores the version of the file from that snapshot — the version that predates the bad actor's first modification within the one-hour pre-event window.

PowerScale case: finding the correct snapshot

1. Snapshot location: The snapshot must exist on the same path as the file.
2. Snapshot timing: The snapshot's timestamp must be earlier than the timestamp of the first event the bad actor triggered on that file.
3. Best snapshot selection: Among snapshots meeting the above criteria, Recovery Manager selects the one closest in time to the first event on the file, ensuring the most recent valid version is recovered.

Example — recoverable: A snapshot of /ifs/test/ was taken at 4:00 PM. A bad actor renames document.txt to document.locky at 5:00 PM. The original document.txt is recoverable — the snapshot predates the change.

Example — not recoverable (no prior snapshot): The only snapshot on /ifs/test/ was taken at 5:03 PM, after the rename. No valid pre-attack snapshot exists, so the file is not recoverable.

Example — not recoverable (wrong path): A snapshot exists only for /ifs/otherpath/, not /ifs/test/. The file is not recoverable because no snapshot covers its directory.

note

If a previous ransomware event corrupted a file and an administrator restored it to an earlier version after acknowledging and archiving that event, there is a chance the most recent snapshot may still contain the corrupted version if another ransomware event is raised against the same file within the following hour.

ECS case: recovering an object

For Recovery Manager behavior specific to Dell ECS object storage — bucket/region display, versioning setup, sorting and filtering, status options, and how object renames are handled — see Recovery — Platform-specific setup and differences.

To recover an object, bucket versioning must be enabled. Recovery Manager restores the most recent version from before the bad actor's first tracked modification.

To display the Earliest Recoverable Version Time column in Recovery Manager, the Eyeglass /opt/superna/sca/data/system.xml file must have the versioningEnabled property (inside the <process> tag) set to true. If it's set to false, Recovery Manager instead displays a Bucket Versioning Status column.

versioningEnabled	Column shown	Values
false	Bucket Versioning Status	Disabled, Enabled, Suspended (was updated from ON to OFF)
true	Earliest Recoverable Version Time	NO_VERSIONS_EXIST, a date/time stamp, or NO_VERSIONS_EXIST (if suspended)

Note: ECS Recovery Manager is currently available in the legacy UI only. The new Cyber Recovery Manager UI does not yet have an ECS view. Use the legacy UI for ECS object recovery operations.

For ECS, recovery is based entirely on bucket versioning rather than snapshots — there is no filesystem-style snapshot mechanism on ECS. If a bad actor triggers a ransomware event and a pre-event version of the object exists, Recovery Manager restores it. If no such version exists, the object is quarantined instead.

note

There is a small chance a corrupted version is chosen for restoration if the same user triggers a second ransomware event either (a) within 1 hour of the first event, where the file was corrupted within the hour before the second event and the bad actor modified it again in that same window, or (b) more than 1 hour after the first event, where the object was restored within the hour before the second event and the bad actor wrote to it again before that restoration.

Recovery outcomes fall into two categories: restored (the file did not use a recognized ransomware extension, so it's placed back in its share or bucket) or deleted (the file used a recognized banned extension, such as .locky, so it is not placed back).

Post-Mortem Analysis and Forensics

Recovery Manager includes an automated quarantine feature that moves affected files to a hidden location for analysis, isolating them from end users while keeping them accessible for investigation.

1. Compromised files are moved during recovery to /ifs/.ransomwaredefender/corrupted/.
2. Under this location, each affected user's SID is created as a subfolder, with the full relative path to each file preserved — allowing targeted scanning with security or decryption tools.
3. This structure also maps the attack across the file system, letting the recovery team analyze the attack pattern.
4. The quarantine location is secured outside of any SMB or NFS exports, keeping the data hidden from normal access.
5. If needed, create a read-only SMB share over the quarantine location so the recovery team can analyze the quarantined data directly.

See also

• Recovery — Current step-by-step procedure for accessing, filtering, and running a recovery job.
• Recovery — Platform-specific setup and differences — Full ECS-specific reference: bucket versioning setup, sorting/filtering, and object rename handling.
• Investigate & Recover — Snapshots Tab — Snapshots taken automatically at detection time.
• Investigate & Recover — Assets Tab — Share permissions for the affected user.
• Snapshot Settings — How and when protective snapshots are taken.