Design for failure before it happens
Availability is the ability to continue a service. Resilience is the ability to absorb faults and recover. Replication, snapshots and backups protect different parts of that objective—and none of them replaces the others.
Four terms describe four different responsibilities
A clear architecture starts by defining what must remain online, how much data may be lost and how quickly a usable service must return.
Keep the service reachable
Redundant components and controlled failover reduce interruption when a path, controller or node fails.
Absorb and repair faults
The system maintains a valid state, isolates failure and rebuilds protection after components return or are replaced.
Preserve recoverable history
Snapshots, retention and independent copies provide points to recover from deletion, corruption or unwanted change.
Restore at another boundary
A separate system or site, operational procedure and verified dependencies allow service restoration after a wider event.
High availability usually protects against downtime, not against bad writes. Synchronous replication can copy accidental deletion or corruption immediately. Historical and independent recovery points are still required.
RPO and RTO turn risk into architecture
Recovery Point Objective describes the acceptable data gap after recovery. Recovery Time Objective describes the target time to restore a usable service.
- RPO near zero generally requires acknowledged writes to reach more than one failure domain.
- An asynchronous replica has an RPO determined by schedule, lag and the last successful transfer.
- RTO includes detection, ownership, service start, validation and application recovery.
- Different workloads on the same platform can require different objectives.
Choose the failure model before choosing the product
Each pattern protects a different boundary and creates different dependencies.
Standalone storage plus asynchronous replica
A primary storage server sends point-in-time changes to a second system according to a schedule. The replica can be placed in another room or site.
and active services
replica and snapshots
- Does not create local automatic controller failover by itself
- RPO follows the last completed replication point
- Activation, networking and application dependencies require a runbook
Two-node synchronous Mirror
Completed writes are synchronously maintained across two storage nodes. A controlled cluster decision transfers service ownership when the active node fails.
active service
synchronous Mirror
- Designed for a very small data gap for acknowledged writes
- Latency between nodes affects the synchronous write path
- Quorum, fencing and network separation must prevent split brain
Dual-controller shared storage
Two controllers provide service access to the same shared storage. Service ownership can move without maintaining a separate mirrored copy between servers.
service owner
shared data paths
- Controller redundancy and storage-path redundancy are separate
- The shared enclosure, cabling and power design remain critical
- Historical recovery still requires snapshots or separate copies
Distributed Ceph storage
Data is distributed across multiple nodes using replication or erasure coding. Placement policy can keep copies or shards in different failure domains.
service endpoints
and failure domains
- No fixed two-node boundary
- Availability depends on quorum and sufficient data fragments
- Recovery and rebalancing consume network and device resources
Availability models trade coupling, recovery and scale
| Architecture | Automatic local failover | Typical data point | Recovery behaviour | Primary dependency | Best starting point |
|---|---|---|---|---|---|
| Standalone + asynchronous replica | No—not from replication alone | Last completed snapshot or replication cycle | Activate the secondary service and validate dependencies | Replication schedule, destination integrity and runbook | Cost-conscious DR and site separation |
| Two-node synchronous Mirror | Yes, with a correctly designed cluster | Completed writes maintained on both nodes | Service ownership transfers to the surviving node | Inter-node latency, quorum, fencing and redundant networks | Compact HA with independent server storage |
| Dual-controller shared storage | Yes | Both controllers address the same shared data | Service ownership transfers while shared capacity remains available | Shared enclosure, redundant paths, cabling and power | Traditional two-controller storage architecture |
| Distributed Ceph | Service remains available while quorum and protection rules are satisfied | Committed data distributed according to pool policy | Cluster continues and rebuilds or rebalances protection | Node count, failure-domain design, quorum, network and free capacity | Scale-out services and larger failure domains |
| Backup or immutable copy | No | Selected historical recovery point | Restore data and then restore the application service | Copy independence, retention, credentials and tested restore | Deletion, corruption and ransomware recovery |
These are architectural characteristics, not guaranteed timings. RPO and RTO must be measured for the complete customer design, including hosts, networks, applications and operational response.
Split brain is a decision failure—not merely a link failure
If two nodes lose communication but both remain alive, each could incorrectly assume it should own the service. A cluster therefore needs an authoritative decision mechanism.
- Quorum determines which side may continue.
- Witness or tiebreaker can provide an additional vote where the architecture requires it.
- Fencing prevents a losing node from continuing to access protected resources.
The implementation varies by platform. Validate the supported topology rather than adding an improvised witness or disabling safety mechanisms.
Redundancy must cross the boundary that may fail
A second disk in the same enclosure does not protect against enclosure loss. A second node on the same switch does not protect against switch loss. Placement and dependencies must follow the business threat model.
Drive, HBA, NIC or cable
Controller or complete server
Shared switch, PDU or cooling
Building, connectivity or regional event
Test failures at the service level
A green dashboard does not prove that applications survive. Test the event, observe the client and validate the data after recovery.
Disconnect an approved network or storage path and verify client behaviour, latency and recovery.
Validate ownership transfer, service start, mount persistence and application I/O.
Confirm that only the authorised side continues and that the losing side is safely isolated.
Verify dependencies such as DNS, directory services, certificates, licences and routing.
Measure the actual data point, activation procedure and time until applications are usable.
Recover files or application data from a known point and verify consistency—not only readability.
euroNAS platforms address different resilience boundaries
The products are examples of the architecture patterns above. Selection should follow the required failure domain, recovery objectives and operating model.
| Platform | Primary operating model | Availability and protection role | Scaling boundary | Important distinction |
|---|---|---|---|---|
| euroNAS Premium | Standalone storage OS for one server, including Virtual Storage Appliance deployment | Snapshots and asynchronous ZFS replication can provide recovery points and a separate DR copy | Scale up within the selected server | Replication alone does not turn the standalone server into an automatic local HA pair |
| euroNAS HA Cluster | Two-node storage architecture | Automatic service failover using synchronous Mirror or a shared-storage model | Scale up within the two-node HA design | HA Cluster can also copy data to another system or location at scheduled intervals. This protects against wider failures, while the synchronous Mirror enables automatic failover between the two local nodes |
| eEKAS | Distributed Ceph scale-out storage | Data protection and service availability across multiple nodes using the selected pool and failure-domain policy | Add qualified storage nodes without a fixed two-node limit | Quorum, network design, free capacity and the protection profile determine tolerated failures |
| eEVOS | Virtualisation platform | Compute and VM availability plus integrated Backup & Disaster Recovery, including Instant Recovery workflows | Add compute nodes and use internal or qualified external storage according to the architecture | VM availability and historical VM recovery are separate objectives and both must be tested |
euroNAS Premium
Standalone storage with snapshots and asynchronous ZFS replication options.
Premium details →HA Cluster
Synchronous Mirror or shared-storage architecture with automatic service failover.
HA Cluster details →eEKAS
Distributed Ceph storage using defined protection profiles and failure domains.
eEKAS details →eEVOS
Virtualisation with integrated Backup & Disaster Recovery and Instant Recovery.
eEVOS details →Connect resilience to storage and virtualisation design
Technical guidance for recovery and distributed storage
Product support, operational behaviour and recommended topologies change over time. Validate the complete design against current documentation.
SNIA data protection practices
Recovery objectives, data-protection strategy and the operational context around RPO and RTO.
Open SNIA guidance →Ceph architecture
Cluster maps, monitor quorum, CRUSH placement and distributed service architecture.
Open Ceph documentation →Define the failure before selecting the architecture
We can review failure domains, application dependencies, RPO, RTO and operational recovery procedures for a business storage or virtualisation design.