Recover clean—not merely quickly
Ransomware recovery requires more than redundant storage. Preserve trustworthy recovery points, keep attackers away from every copy and define how a verified business service returns to operation.
the incident
a clean point
through separate control
Cyber resilience starts before the storage event
NIST frames ransomware readiness across Govern, Identify, Protect, Detect, Respond and Recover. Storage protection is one part of that wider operating model.
Govern
Assign ownership, acceptable risk, recovery authority and reporting obligations.
Identify
Know critical services, dependencies, data owners and restoration priorities.
Protect
Reduce exposure and preserve protected, independent recovery points.
Detect
Recognise abnormal access, change rates, deletion and control-plane activity.
Respond
Contain access, preserve evidence and coordinate technical and business decisions.
Recover
Restore a known state, verify applications and reconnect services deliberately.
Storage cannot prevent data exfiltration by itself. Recovery controls can restore availability and data integrity, but privacy, notification, forensics and credential response remain separate incident responsibilities.
Design for more than file encryption
Modern incidents can target production data, backup systems, administrative identities and sensitive information at the same time.
Usable data becomes unreadable
Recovery needs a point from before the damaging writes and enough clean infrastructure to use it.
Data and recovery points disappear
Retention, versioning, Object Lock/WORM or offline copies can restrict the attacker’s ability to remove every version.
Legitimate control paths become hostile
Separate identities, least privilege and protected recovery administration reduce the blast radius of one account.
Confidential data leaves the organisation
Restoring data does not undo disclosure. Detection, legal assessment, notification and key or credential response may still be required.
Do not trigger failover automatically just because production data is damaged
A secondary system may already contain the same unwanted writes, and reconnecting it to compromised identities or hosts can damage it again. Incident containment and a clean-point decision must precede recovery.
Protect the recovery path in layers
No single storage feature creates cyber resilience. Combine controls so one compromised identity or system cannot alter production and every recovery copy.
Separate administrative identity
Limit privilege, separate duties and protect recovery credentials. Production administrators should not automatically control every retained copy.
Segment control and data paths
Reduce lateral movement. Isolate management, storage, backup and recovery communication according to the threat model.
Retain version history
Snapshots and object versions provide selectable points. Their value depends on retention, access control and independence from the attacked system.
Use immutable or offline copies
Restrict deletion and overwrite. Correctly configured Object Lock/WORM or offline media can make a recovery copy harder to destroy.
Cross a failure and trust boundary
Keep at least one suitable copy beyond production control. A second site is useful only if the same compromise cannot administer both.
Test clean restoration
Validate more than file readability. Identity, applications, dependencies, malware checks and business acceptance belong in the exercise.
Know what each control can—and cannot—do
Use several layers. A control that protects hardware availability may offer no historical recovery, while a retained copy may not provide rapid service continuity.
| Control | Hardware continuity | Earlier data state | Deletion resistance | Separate trust boundary | Critical limitation |
|---|---|---|---|---|---|
| HA / controller failover | Primary purpose | No | No | Usually no | Can continue serving encrypted, deleted or corrupted data |
| Synchronous Mirror | Supports local continuity | No historical state by itself | No | No—both nodes form one HA system | Unwanted writes are synchronised |
| Local snapshot | No | Yes, according to schedule and retention | Only if access and retention protect it | Usually no | The source administrator or storage incident may affect snapshots |
| Asynchronous replica | Not automatic unless the wider design provides it | Potentially, before the next replication cycle | Only with retained versions or separate policy | Potentially, if identity and control are separated | Deletion or encryption can be replicated later |
| S3 versioning | No | Earlier object versions | Versions still require permissions and lifecycle protection | Depends on the bucket and account design | Does not by itself prevent privileged deletion of versions |
| S3 Object Lock / WORM | No | Protected retained object versions | Yes, during valid retention when correctly configured | Depends on identity and deployment | Configuration, retention mode, encryption keys and application behaviour still matter |
| Independent backup | No | Selected retained recovery points | Strong when offline, immutable or separately controlled | Should be designed explicitly | Recovery time and application consistency must be tested |
Immutability is a configuration property, not a marketing label. Verify who can change retention, which object versions are protected, how encryption keys are governed and what happens when lifecycle rules or credentials are compromised.
Return services through a controlled trust decision
Recovery speed matters, but reconnecting compromised hosts, identities or management paths can immediately damage the restored environment.
- Document who may declare an incident and authorise restoration.
- Preserve logs and evidence before destructive remediation where appropriate.
- Determine the last known clean point using security and application evidence.
- Restore dependencies in business priority order, not simply storage order.
- Measure the time until users receive a validated service—not only until bytes are copied.
Match the recovery method to the damaged scope
Restoring more than necessary increases time and risk. Restoring too little can leave hidden dependencies or compromise behind.
Granular recovery
Recover selected user files, database exports or object versions when the application and operating environment remain trusted.
Validate permissions, ownership, version and application context.Consistent application state
Restore data and logs according to the application’s consistency and sequencing requirements.
A readable volume is not proof of a valid database or application.Whole-system recovery
Return a complete VM when operating-system and application state belong together or the original instance is untrusted.
Patch, scan, rotate credentials and validate dependencies before reconnecting.Disaster recovery
Rebuild compute, identity, network, applications and data when the production boundary cannot be trusted or used.
The runbook must define ordering, authority and return-to-primary.Several VM recovery methods serve different boundaries
eEVOS is a virtualisation platform with integrated Backup & Disaster Recovery. Select the method by recovery speed, separation and retention—not by one universal hierarchy.
Place fast recovery and independent recovery on different boundaries
The exact implementation varies, but a credible design does not let one production identity alter every layer.
euroNAS platforms contribute at different protection layers
These capabilities support a wider cyber-resilience design. None replaces endpoint security, identity protection, monitoring, incident response or an independent recovery policy.
euroNAS Premium
Standalone storage for one physical server or Virtual Storage Appliance.
- Storage snapshots for point-in-time recovery
- Scheduled asynchronous replication to another system or location
- File, block and S3 services for suitable recovery architectures
HA Cluster
Automatic two-node storage failover using synchronous Mirror or dual-controller shared storage.
- Local service continuity for infrastructure failures
- Snapshots for historical storage points
- Separate asynchronous replication options
eEKAS
Graphically managed Ceph block, file and S3 storage across multiple nodes.
- Distributed infrastructure protection across defined failure domains
- S3 versioning and Object Lock/WORM controls
- Graphical bucket, policy, lifecycle and retention administration
eEVOS
A virtualisation platform rather than a storage product.
- Integrated Backup & Disaster Recovery
- Instant Backup & Recovery
- Network, S3-compatible cloud and external backup workflows
Make the recovery assumptions explicit
Rank business services and document their identity, network, application and data dependencies.
Map accounts, keys, consoles and automation that can modify production, snapshots, replicas and backups.
Set retention from detection time, dwell-time assumptions and business data-loss tolerance.
Define offline or immutable recovery points and verify retention mode, version scope and key governance.
Prepare clean compute, networking, identity, licences, documentation and administration tools.
Test files, applications, authentication, integrations, security posture and business acceptance.
Independent guidance for ransomware readiness
Threats and recommended practices change. Review current official guidance and validate the customer-specific incident and recovery plan.
NIST IR 8374 Rev. 1
The 2026 Cybersecurity Framework 2.0 Community Profile maps ransomware risk across Govern, Identify, Protect, Detect, Respond and Recover.
Open NIST guidance →CISA #StopRansomware Guide
Guidance covering prevention, offline or immutable backup, incident response and regular recovery testing.
Open CISA guidance →Amazon S3 Object Lock
Official explanation of WORM retention, legal holds, version scope and important operational considerations.
Open AWS documentation →Design the recovery path before an incident
We can review recovery points, trust boundaries, storage or VM protection, retention, RPO, RTO and restoration testing for a business architecture.