What is the best storage architecture for disaster recovery for banks in Dubai and Abu Dhabi?

Technology

It’s 11:40 on a Tuesday morning. A core banking system in a Dubai data centre becomes unavailable. Could be a hardware failure. Could be a network fault. Could be something worse. The operations team has thirty seconds before the calls start coming in from branches, from treasury, from the CEO’s office.

What happens next depends entirely on decisions made months or years earlier. Architecture decisions. Contractual decisions. Testing decisions. And in the UAE banking context, regulatory decisions, because the CBUAE has specific expectations about how banks manage business continuity and disaster recovery that go well beyond general IT best practice.

Most banks in Dubai and Abu Dhabi have some form of DR. The question worth asking is whether that DR would actually work under the conditions it’s designed for, and whether it satisfies what a regulator would expect to see documented and tested.

What the CBUAE Expects From DR Architecture

The Central Bank of the United Arab Emirates (CBUAE’s) Outsourcing Regulation for Banks, Circular No. 14/2021, requires that the Master System of Record for all confidential customer data be continuously maintained and stored within the UAE. This single requirement shapes every DR architecture decision a UAE bank makes.

It means your secondary site, the one that activates when the primary fails, must also be within the UAE. A DR setup that replicates to a data centre in India, Germany or the US to reduce costs is non-compliant by design, regardless of how fast the failover is.

The CBUAE’s broader operational risk management framework, which sits alongside Circular 14/2021, requires banks to maintain documented business continuity plans, conduct regular DR testing, and demonstrate that recovery objectives are achievable. Recovery time objective (RTO, meaning how quickly systems come back online after a failure) and recovery point objective (RPO, meaning how much data can be lost in the event of an outage) aren’t just internal KPIs. They’re regulatory commitments a bank should be able to defend during a supervisory review.

The Core Architecture Choice: Active-Passive vs Active-Active

This is where most serious DR conversations start. And there isn’t one universal answer.

Active-passive means your primary site runs all live workloads and your secondary site sits in a warm or cold standby state, ready to take over when needed. It’s the more common approach for mid-sized banks and finance companies. Lower cost than active-active. Simpler to manage. The trade-off is failover time. Warming up a passive site and redirecting traffic takes minutes at best, longer if the failure is complex.

Active-active means both sites run live workloads simultaneously, with traffic distributed between them. Failover is near-instantaneous because the secondary site is already processing transactions. The trade-off is cost and complexity. You’re essentially running two full production environments. Data synchronisation between sites must be near-real-time, which demands high-bandwidth, low-latency connectivity between the Dubai and Abu Dhabi locations.

For large retail banks with high transaction volumes and tight SLA (service level agreement) commitments to customers, active-active is increasingly the standard. For smaller institutions or those with more tolerance for brief outages, a well-configured active-passive setup with a warm secondary site is often the right call. The honest answer is that the choice should follow the RTO and RPO commitments, not the other way around.

Storage Architecture That Actually Supports DR

The failover decision is only as good as the storage architecture underneath it.

Synchronous replication means data is written to both the primary and secondary site simultaneously before a transaction is confirmed. Zero data loss. The downside is latency: every write operation waits for both sites to confirm. For this to work without degrading performance, the distance between sites matters. Dubai and Abu Dhabi are well within the distance threshold where synchronous replication is operationally viable over a dedicated link.

Asynchronous replication writes to the primary first and replicates to the secondary with a short delay. Better performance, but there’s a window of potential data loss if the primary fails between writes. For non-critical systems or secondary data sets, this is a reasonable trade-off.

For core banking workloads, the combination that most UAE banks should be working toward is synchronous replication between a Dubai primary and Abu Dhabi secondary (or vice versa) for tier-one systems, with asynchronous replication for less critical workloads. Storage platforms from vendors including NetApp, Pure Storage and Dell, all of which Brilyant works with, support this tiered replication model natively.

Snapshot-based recovery is worth mentioning separately. Even with synchronous replication, a logical corruption event (where bad data is replicated correctly to both sites before anyone notices) can affect both environments. Immutable snapshots, meaning point-in-time copies of data that cannot be altered or deleted for a defined period, provide a third layer of protection. For BFSI workloads, this is increasingly considered a baseline, not an optional extra.

The Network Layer: Often the Weakest Link

Storage architecture and failover logic are only as reliable as the network connecting the two sites.

A DR setup that depends on a single connectivity path between primary and secondary sites has a single point of failure built in. Best practice for Dubai to Abu Dhabi connectivity involves dedicated leased lines with full path redundancy, ideally across different physical routes and different carriers. MPLS (Multiprotocol Label Switching, a method of directing network traffic along predetermined paths for speed and reliability) remains widely used for this purpose among UAE banks, sometimes in combination with SD-WAN (Software-Defined Wide Area Networking, which adds flexibility and centralised management on top of the underlying links).

The failover trigger mechanism also matters. Automated failover based on health monitoring reduces human reaction time but introduces the risk of false positives, flipping to DR mode when the primary is recoverable. Manual failover avoids false triggers but adds minutes to the response time. Most mature implementations use automated detection with a short human confirmation window before the switch completes.

Testing: The Part Most Banks Do Least

A DR architecture that hasn’t been tested under realistic conditions is a theoretical architecture. The CBUAE’s operational risk framework expects banks to test their business continuity and DR capabilities, and the test results should be documented.

What this means in practice: a full failover test at least annually, where production traffic is actually switched to the secondary site and the primary is deliberately taken offline. Tabletop exercises and partial tests have value, but they don’t tell you whether the storage replication, the network routing, the application configurations, and the access controls all work together the way they’re supposed to.

Here’s the part that catches people out. A DR test that’s run at 2am on a Sunday with a skeleton crew is not the same as a DR event that happens at midday on a busy transaction day. Both the architecture and the runbook need to be stress-tested under conditions closer to the second scenario.

Frequently Asked Questions

Can a Dubai bank use a data centre outside the UAE as its DR site?

No. Under CBUAE Circular 14/2021, Article 6.1, the Master System of Record including all confidential customer data must be stored within the UAE continuously. A DR site outside the UAE would breach this requirement unless specific prior CBUAE approval has been obtained.

What is the difference between RTO and RPO and why do they matter for DR architecture?

RTO (recovery time objective) is how quickly your systems need to be back online after a failure. RPO (recovery point objective) is the maximum amount of data you can afford to lose. These two figures directly determine which storage replication method and which DR architecture model is appropriate. Tight RTO and RPO requirements point toward active-active synchronous replication. More tolerance allows for active-passive with asynchronous replication.

Is cloud-based DR compliant for UAE banks?

It can be, provided the cloud infrastructure is located within the UAE, the data processing agreements meet CBUAE requirements, and the arrangement has received prior CBUAE approval as a material outsourcing decision. Both AWS and Microsoft Azure have operational regions within the UAE that can support DR workloads.

How often should banks test their DR setup?

The CBUAE’s operational risk framework expects documented DR testing. Industry practice for banks is at minimum one full failover test annually, with partial or component tests more frequently. Test results should be documented and remediation tracked.

Where Brilyant Can Help

The DR projects that go wrong aren’t usually the ones with bad intentions. They’re the ones where the storage architecture was designed for cost efficiency rather than regulatory compliance, or where the network redundancy between sites wasn’t validated before the first real failure occurred.

Brilyant works with banks across Dubai and Abu Dhabi to design and implement storage and DR architectures built for CBUAE compliance from day one. We’re a certified partner with NetApp, Pure Storage and Dell on the storage side, and with AWS and Microsoft Azure for cloud-based DR workloads. We design the replication topology, validate the network paths, and build the testing framework alongside the implementation.

Talk to Brilyant’s infrastructure team about DR architecture for UAE banks.