Skip to content
CBN data localisation deadline, 1 Jan 2027: 99d 00h 31m left.Talk to us →
NuxFamily

A second site in Nigeria, replication you can measure and DR tests that run themselves.

Disaster recovery that stays in Nigeria and is proven every month

Replication between two Nigerian data centres for virtual machines, Kubernetes, databases and streams, with RPO and RTO you can show the regulator and failover tests that are automated rather than promised.

Book a Discovery SessionSee the CBN compliance path

The challenge

The challenge

Under the CBN directive, backups and secondary sites for payment data are as much in scope as the primary environment. A disaster recovery region in Frankfurt or Cape Town is a cross-border replica, and cross-border replication of payment data is expressly prohibited. This is regulatory context, not legal advice.

The journey with NuxFamily

  1. 01Assess
  2. 02Design
  3. 03Build
  4. 04Migrate
  5. 05Operate
  6. 06Evolve

Every family is delivered through the same six-stage journey, with official 24×7 support and knowledge transfer built in.

Our approach

How we design it

  1. 01

    Classify services by tier

    Each application gets a tier with an RPO and RTO agreed with the business. Payment authorisation is not the same as the intranet, and the design should not pay for treating them the same.

  2. 02

    Select the second site

    A second Nigerian data centre on a different power and network path, with latency measured for synchronous or asynchronous replication per tier.

  3. 03

    Replicate per layer

    Storage-level replication for VMs, streaming replication for PostgreSQL, mirrored topics for Kafka, GitOps for Kubernetes state and bucket replication for S3-compatible storage.

  4. 04

    Automate failover

    Runbooks turned into code: DNS and network switch, database promotion, consumer re-pointing and application start-up in a defined order with checkpoints.

  5. 05

    Test on a schedule

    Automated DR tests on a monthly cadence, from isolated component failovers to a full site exercise, with measured RPO and RTO recorded each time.

  6. 06

    Report and improve

    Test results become audit evidence. Gaps found in tests feed the next iteration of the design.

Outcomes

Outcomes

100 %

in-country replication

Primary, secondary and backups all in Nigerian data centres; no cross-border copy.

< 30 min

RTO for tier-1 services

Indicative target for payment processing, achieved through automated failover rather than manual runbooks.

12

DR tests per year

Monthly automated tests with measured results, ready for the auditor.

Use cases

Use cases

Use case 01

Active-passive DR for core payment processing

A bank's payment platform runs on Kubernetes and PostgreSQL in a Lagos data centre. It needs a second site in Nigeria that can take over within the recovery objectives agreed with its risk committee.

Technologies

  • Proxmox VE
  • VMware vSphere
  • OpenShift
  • PostgreSQL
  • Patroni
  • Apache Kafka
  • MirrorMaker 2
  • MinIO
  • Argo CD

Expected outcome

A second Nigerian site that takes over payment processing on demand, with results the auditor can read.

Metric: RPO < 1 min · RTO < 30 min in monthly tests

Active-passive DR for core payment processingA bank's payment platform runs on Kubernetes and PostgreSQL in a Lagos data centre. It needs a second site in Nigeria that can take over within the recovery objectives agreed with its risk committee. A second Nigerian site that takes over payment processing on demand, with results the auditor can read.1Establish the second siteProxmox VE / VMware · OpenShift2Stream database changesPostgreSQL · Patroni3Mirror event streamsMirrorMaker 24Replicate state and secretsArgo CD5Sync object storageMinIO6Fail over automaticallyFailover pipeline7Measure and recordOpenSearch
  1. 1Establish the second site. A matching hypervisor and Kubernetes footprint stood up in a second data centre from the same infrastructure code.
  2. 2Stream database changes. PostgreSQL streaming replication to a hot standby with Patroni managing promotion.
  3. 3Mirror event streams. Kafka topics mirrored continuously so consumers can resume from the same offsets at the secondary site.
  4. 4Replicate state and secrets. Kubernetes manifests, config and sealed secrets applied at both sites through GitOps.
  5. 5Sync object storage. Buckets replicated with versioning; backups written to both sites with immutable retention.
  6. 6Fail over automatically. A single pipeline promotes the database, re-points consumers, switches DNS and verifies health.
  7. 7Measure and record. RPO and RTO measured on every test and stored as evidence for the risk committee.

Use case 02

Automated DR testing for an existing private cloud

Built on these families

Built on these families

FAQ

FAQ

For payment data covered by the CBN directive, cross-border replication is prohibited, so the design keeps both sites in the country. How the rules apply to any other data is a question for your compliance team.

Over two decades

Built by the team behind the platforms of Santander, ING, Bankinter, Mapfre and Inditex

More than twenty years designing, building and operating private clouds for institutions that cannot afford to fail, and a delivery model where we stay with you from assessment to operation.

See our track record

20+

Years building private clouds

40+

Private clouds delivered

Start with a Discovery Session

Sixty minutes with an architect who has delivered this before. No slideware.

No mailing lists, no automated follow-ups. We reply personally within one working day.