Recover the service, not only the files
A resilient recovery design preserves usable points in time, keeps copies beyond the original failure boundary and defines how applications return to operation. Snapshots, replication, backup and disaster recovery each solve a different part of that task.
Five methods protect five different objectives
A resilient design combines methods instead of expecting a single mechanism to protect against every failure scenario.
Continue after a component fails
Redundant paths, controllers or nodes reduce interruption. They do not provide an older copy of the data.
Return to a local point in time
A fast recovery point can help reverse deletion or unwanted change while the source system remains usable.
Maintain data on another system
Synchronous or scheduled copying protects different recovery objectives and introduces different dependencies.
Retain recoverable history
Backups preserve selected versions according to policy and should remain sufficiently independent from production.
Restore a usable business service
Data, compute, networking, identity, applications and an operational runbook come together at another recovery boundary.
Key distinction: high availability reduces downtime from expected infrastructure failures. Backup and disaster recovery address the ability to return from damaged data, operational mistakes, security incidents or wider outages.
Choose a recovery control for the event
No single column should be expected to cover the whole table.
| Failure or event | HA / failover | Snapshot | Replica | Independent backup | DR procedure |
|---|---|---|---|---|---|
| Controller, node or path failure | Primary control | No | May assist recovery | Restore if required | For wider interruption |
| Accidental deletion | No | Fast local recovery | Only if an older point remains | Historical recovery | Usually not required |
| Application or data corruption | No | If detected in time | Can copy corruption | Select a known good point | Coordinates application return |
| Ransomware or destructive credentials | No | May share the same risk boundary | May copy encrypted data | Requires protected, usable copies | Contain, recover and validate |
| Complete system loss | Only if another node survives | Not if stored only on that system | Activate the separate copy | Restore to replacement capacity | Returns the complete service |
| Site outage | Not within the same site | Not when local only | If placed beyond the site | If a remote copy is available | Required for dependencies and operations |
Coverage depends on the actual placement, retention, permissions and supported product configuration. “Backup”, “replica” or “snapshot” is a design role—not proof that the copy survives a particular event.
The restore is only one step in the recovery chain
A business service is available again only after the incident is contained and the recovered application is validated.
Detect
Confirm the failure, affected services and last known healthy state.
Contain
Stop damaged or compromised systems from changing recovery copies.
Select
Choose the correct recovery point for the application and its dependencies.
Recover
Fail over, activate a replica, restore data or start a recovered virtual machine.
Validate
Check data consistency, identity, networking and application behaviour.
Return
Reconnect users and monitor the service before closing the incident.
Place recovery points across meaningful boundaries
Local snapshots for rapid rollback
Fast recovery
Point-in-time recovery on the production storage can minimise transfer time and simplify recovery from recent mistakes.
- Useful for rapid file, dataset or volume recovery
- Retention must match how long problems may remain undetected
- A source-system loss can remove both production and local history
Scheduled copy to another system or site
Separate boundary
Data is copied at defined intervals to separate capacity. The last successful cycle determines the potential data gap.
- Protects against complete source-system loss
- Activation, addressing and application dependencies need a runbook
- Retention is still needed because unwanted change can be copied
Independent backup with retention
Historical recovery
Selected recovery points are retained under a separate policy and protected from the same operational or credential failure where possible.
- Supports selection of an older known good state
- Access, deletion protection and credentials are part of the design
- Regular restore tests confirm that the content is usable
Service-level disaster recovery
Business continuity
A documented workflow combines recovery data with compute, networks, identity and application-specific validation.
- RPO defines the acceptable data gap
- RTO includes every step until the service is usable
- Exercises reveal missing dependencies before an incident
Protect recovery options from the same compromise
Ransomware recovery is not simply a larger restore. The team must determine what was affected, prevent reinfection, select a clean point and validate applications before reconnecting users.
- Keep more than one recovery point so delayed detection does not remove every clean version.
- Separate administrative access and protect credentials used to manage recovery copies.
- Place at least one recovery option beyond the production system’s immediate failure boundary.
- Test complete application recovery—not only whether individual files can be read.
A recoverable copy needs four qualities
Technology alone does not make a copy safe or useful.
Backup & Disaster Recovery is a core part of eEVOS
eEVOS integrates virtualisation with Backup & Disaster Recovery workflows. This keeps protection and recovery close to VM operations while preserving the distinction between keeping a VM available and recovering an earlier usable state.
Instant Backup & Recovery is designed to create VM backups and return protected virtual machines within seconds. It complements the other backup and recovery methods; it does not replace off-system copies or operational validation.
Choose the backup path for the recovery objective
eEVOS provides complementary methods for rapid local recovery, separate network and S3-compatible cloud copies, off-site Disaster Recovery and established third-party backup processes.
| Method | What it protects | Destination or boundary | Recovery value |
|---|---|---|---|
| Instant Backup & Recovery | Complete virtual machines, with file-level recovery when only individual files are required | eEVOS-managed VM recovery points | Fastest return: backup and whole-VM recovery are designed to complete within seconds |
| Network Backup | Efficient, deduplicated virtual-machine backups, including file-level recovery | A user-selected NAS server reached over the network | Separate system: keeps a recovery copy beyond the virtualisation host |
| Cloud Backup (S3-compatible) | Space-saving, deduplicated virtual-machine backups, including file-level recovery | Any S3-compatible cloud or object-storage service | Remote copy: extends protection beyond the local infrastructure |
| Disaster Recovery | Virtual machines required after a wider infrastructure or site event | Asynchronous replication to a remote location, run on a schedule or manually | Service continuity: VMs can be restored from the off-site location when the primary site is unavailable |
| External Backup | Live virtual-machine images prepared for an organisation’s existing backup process | A supported third-party backup tool and its configured repository | Policy integration: retains an established backup product where organisational rules require it |
Design principle: Instant Backup & Recovery addresses recovery speed. Network, S3-compatible cloud and Disaster Recovery options add different levels of separation from the production environment. The appropriate combination depends on RPO, RTO, retention and failure boundaries.
euroNAS products protect different layers
The product should be selected by workload, failure boundary and recovery objective—not by the longest feature list.
| Product | Primary role | Relevant protection | Best fit in this design | Important distinction |
|---|---|---|---|---|
| euroNAS Premium | Standalone storage OS for one server, including Virtual Storage Appliance deployment | Snapshots and scheduled replication to another system or location | Rapid storage rollback and a separate recovery copy | Replication does not turn one storage server into an automatic local HA pair |
| euroNAS HA Cluster | Two-node storage with automatic service failover | Synchronous Mirror or shared-storage failover, plus snapshots and scheduled replication | Local storage availability combined with separate recovery points | The synchronous Mirror keeps services available; historical recovery still requires snapshots or another retained copy |
| eEKAS | Distributed Ceph scale-out storage | Replication or erasure coding across defined failure domains | Continued storage service and data protection during infrastructure failures | Distributed redundancy and self-recovery do not replace a historical backup |
| eEVOS | Virtualisation platform | Integrated Backup & Disaster Recovery, including Instant Backup & Recovery workflows | VM protection, recovery and service return within the virtualisation workflow | VM availability and recovery from an earlier state are separate objectives |
euroNAS Premium
Snapshots and scheduled replication for standalone storage designs.
HA Cluster
Automatic local failover with separate snapshot and replication options.
eEKAS
Ceph protection profiles across nodes and defined failure domains.
eEVOS
Integrated virtual-machine protection, recovery and Instant Backup & Recovery.
Ask operational questions, not only capacity questions
Independent guidance for recovery planning
Security guidance and product capabilities change. Validate the complete design and its procedures against current documentation.
SNIA data protection practices
Recovery objectives, data-protection strategy and the operational context around RPO and RTO.
CISA #StopRansomware Guide
Organisational practices for preventing, responding to and recovering from ransomware incidents.
NIST contingency planning
Planning, recovery strategies, testing and maintenance for information-system contingency plans.
Define recovery objectives before selecting the mechanism
We can review application dependencies, failure boundaries, retention, RPO, RTO and recovery tests for a business storage or virtualisation design.