The EU’s Digital Operational Resilience Act (DORA) is forcing a fundamental rethink of infrastructure design in financial services. It is no longer sufficient to have backup plans or theoretical disaster recovery procedures. Regulators now expect provable, testable, and continuously enforced resilience — particularly around data.
Traditional approaches to infrastructure resilience have always involved a tradeoff. Synchronous replication gives you high availability but limits geographic distance. Asynchronous replication covers long-haul DR but accepts data loss risk. Backup-based recovery is flexible but operationally heavy and slow.
None of these alone meet what DORA now demands from organizations operating critical infrastructure in the EU. The regulation isn’t prescriptive about technology — but it is explicit about outcomes: continuous availability, measurable recovery objectives, testable multi-scenario resilience, and reduced concentration risk.
Everpure FlashArray’s trisync replication model, exposed natively through OpenStack Cinder, addresses all of these simultaneously.
What trisync actually does
Trisync combines synchronous and asynchronous replication into a single volume abstraction in OpenStack. A Cinder volume with trisync enabled is simultaneously:
- Synchronously replicated between two metro sites — providing active-active storage with zero data loss
- Asynchronously replicated to a third independent site — providing geographically separated DR coverage
- Presented as a single volume abstraction in the OpenStack API — the complexity is in the platform, not your procedures
Operationally, this means configuring both sync and async replication targets in the Cinder driver and enabling pure_trisync_enabled=True. The complexity lives in the platform, not in your procedures.
The result is a dual-layer resilience model embedded at the storage level:
Loss of one data centre → no interruption (sync failover). Loss of an entire region → recovery from a third site (async copy). Both handled, simultaneously, without manual intervention.
What this means for DORA specifically
1. Deterministic RPO and RTO — With an Important Caveat on the Async Tier
DORA emphasises measurable resilience — especially Recovery Point Objective (RPO) and Recovery Time Objective (RTO). With trisync, the metro (synchronous) tier delivers deterministic, platform-inherent recovery characteristics. The async tier is more nuanced.
| Failure scenario | RPO | RTO | Notes |
|---|---|---|---|
| Metro site failure (sync) | 0 — zero data loss | Near-zero | Inherent to synchronous design |
| Regional disaster (async) | Up to 15 minutes | Low, orchestration-dependent | See caveat below |
The async caveat: FlashArray async replication has a minimum replication interval of 15 minutes, meaning the DR copy at Site C can be up to 15 minutes behind at the point of a regional failure. DORA does not mandate a specific RPO number — the regulation requires financial entities to define their own RPOs through a Business Impact Analysis (BIA), proportionate to the criticality of each function. For many workloads, a 15-minute RPO is entirely defensible and will pass regulatory scrutiny. For others — payment processing, real-time trading, settlement systems — it almost certainly will not. Architects and compliance teams should classify workloads explicitly before relying on the async tier as a DORA-compliant recovery target for critical functions. For those workloads, trisync’s synchronous metro tier must carry the compliance argument; the async copy is best treated as an additional layer of geographic protection rather than a primary recovery SLA.
2. Policy-driven compliance through Cinder volume types
One of DORA’s less-discussed requirements is consistent and enforceable controls. Cinder’s volume type system turns replication policy into a declarative construct:
| Tier | Volume type | Protection |
|---|---|---|
| Gold | replication_type=trisync | Full 3-site trisync |
| Silver | replication_type=async | Single async copy |
| Bronze | replication_enabled=False | Local only |
Compliance becomes declarative. Enforcement is automatic. Audit visibility is API-native. This is the kind of control model regulators expect to see.
3. Reduced operational risk during incidents
Traditional DR introduces operational risk precisely when you can least afford it: manual failover steps, reconfiguration of storage mappings, human error under pressure.
With trisync, metro failover is effectively transparent — data consistency is guaranteed and volume identity remains stable throughout. Less operational complexity during recovery means fewer failure modes. That’s not a soft benefit — it directly addresses DORA’s incident response requirements.
4. Data sovereignty and concentration risk
DORA explicitly targets over-reliance on single providers or locations. An OpenStack + trisync architecture enables
- Multi-site deployment across jurisdictions
- Independence from hyperscaler regions
- Full control over data placement.
This supports sovereign cloud strategies, regulatory data residency requirements, and credible exit planning.
Beyond OpenStack: Native FlashArray Closes the Gap for Critical Workloads
It is worth being explicit about a current limitation in the OpenStack Cinder driver: the async replication tier uses standard async replication with a minimum interval of 15 minutes. As noted above, that RPO will not satisfy a DORA Business Impact Analysis for critical financial functions.
Outside of OpenStack Cinder, Everpure FlashArray now supports a fully DORA-aligned 3-site architecture using ActiveCluster and ActiveDR:
- ActiveCluster provides synchronous replication between two metro sites — RPO of zero, RTO near-zero — identical to the sync tier in the Cinder trisync model.
- ActiveDR provides continuous replication to a geographically and logically separate third site, with RPO targets of under 30 seconds for critical financial workloads. This is fundamentally different from standard async replication — near-synchronous in practice — and directly addresses the gap that the Cinder driver’s 15-minute async interval leaves open.
The practical implication: organisations running workloads directly on FlashArray — outside of OpenStack — can achieve a genuinely DORA-compliant 3-site configuration today, with sub-30-second RPO across all three sites. ActiveDR is not currently supported in the Everpure Cinder driver. For OpenStack environments with critical financial workloads, this is a meaningful gap that architects should account for in their DORA compliance planning. It also represents a clear roadmap item: when ActiveDR support lands in the Cinder driver, the OpenStack trisync story becomes unambiguously DORA-compliant for all workload tiers.
For critical financial workloads on OpenStack today, the DORA compliance argument rests on the synchronous metro tier. ActiveDR — when it reaches the Cinder driver — closes that argument completely.
The Strategic Shift: Storage as a Compliance Control Plane
The deeper significance here isn’t just technical. Trisync changes what storage is in the architecture. It moves from a component that supports resilience to a control plane that enforces resilience policy — defined in OpenStack APIs, applied consistently across workloads, and visible to governance and audit systems.
DORA is pushing the industry toward design-time controls rather than procedural controls. Trisync is exactly that.
What Organisations Still Need to Do
Even with trisync, DORA compliance isn’t automatic. Organisations must still:
- Regularly test failover scenarios
- Document resilience classifications
- Monitor replication health
- Integrate with incident reporting frameworks
The platform doesn’t replace the programme — it makes the programme credible. Trisync handles the hardest part: ensuring data survives failure at the platform level.
Conclusion
DORA is raising the bar from “we have DR” to “we are operationally resilient by design.”
- OpenStack provides the control plane.
- Cinder provides the abstraction and policy engine.
- Everpure FlashArray trisync provides zero-loss high availability at the metro tier, geographically independent DR at the regional tier, and policy-driven auditable enforcement — with the honest caveat that the async tier’s 15-minute minimum RPO must be validated against each workload’s BIA before being treated as a compliant recovery target for critical functions.
For EU organisations navigating DORA, that is not just a technical win. It is a strategic one.one.
That’s a really important point about DORA and the need for continuous testing. The synchronous replication approach definitely seems like a more robust solution than relying solely on backups.