Cloud services · Disaster recovery
Disaster recovery in Saudi Arabia: a recovery site you have actually tested
Disaster recovery is the plan and the infrastructure that bring your systems back after a serious failure: a lost data centre, a region outage, ransomware or a destructive mistake. For a Saudi organisation it answers two questions: how fast each system must return and how much data it may lose, and where the recovery copy may live. Interkey designs, builds, tests and operates disaster recovery on partner cloud platforms and on your own infrastructure, from Riyadh.
Orientation
At a glance
The whole page in one table, before the detail.
- What it decides
- For each system: the recovery time objective (RTO) and the recovery point objective (RPO)
- Patterns
- Backup and restore, cold standby, warm standby, hot standby
- Where the copy can live
- A second zone, an in-Kingdom cloud region, a local provider or your own second site
- Databases
- Native replication, or iblync, Interkey's replication platform, between different kinds of system
- Proof
- A recovery test with a written result, repeated on a schedule
- What Interkey does
- Assessment, design, build, recovery tests and operation, from Riyadh
In short, for decision makers
- Start with the business: every system gets an RTO and an RPO agreed by its owner.
- Then choose a pattern: the shorter the targets, the more of the recovery site runs all the time.
- Residency applies to the copy: backups and the recovery site follow the same rules as production.
- Untested means unknown: a disaster recovery plan is only as good as its last recovery test.
RTO and RPO: the two numbers a disaster recovery plan is built on
The recovery time objective is how long a system may be down before the damage is unacceptable. The recovery point objective is how much recent data the business can afford to lose, measured in time: an RPO of fifteen minutes means the last fifteen minutes of changes may be gone. Our glossary entry on RTO and RPO explains both in more detail.
Both numbers belong to the business owner of each system. A payments platform and an internal reporting tool rarely deserve the same targets, and giving every system the tightest one doubles the budget without making anything safer. A business continuity plan sets the order in which services return and who invokes recovery; disaster recovery is its technical part.
Four disaster recovery patterns, from cheapest to fastest
Typical orders of magnitude, not promises: data volume, rebuild automation and the database method decide where a system lands.
| Pattern | What runs at the recovery site | Typical recovery time | Data loss exposure | Running cost |
|---|---|---|---|---|
| Backup and restore | Nothing; backups are stored there | Hours to days | Back to the last backup | Lowest: storage only |
| Cold standby | Infrastructure defined as code, not running; data copied on a schedule | Hours | Back to the last copy | Low |
| Warm standby | A reduced copy running, with databases replicated continuously | Minutes to hours | Seconds to minutes | Medium |
| Hot standby | A full-size copy running and ready to take traffic | Minutes | Close to none, depending on replication | Highest: close to a second production |
Most estates mix patterns: warm or hot standby for the few systems the business cannot run without, cheaper patterns for the rest. Every pattern still needs backups, because a replica copies a deletion or an encrypted file as faithfully as good data.
Keeping the disaster recovery site inside Saudi Arabia
A recovery copy is still your data. If your classification policy says a class of data must stay in the Kingdom, its backups and recovery site must stay too. That narrows the options, but rarely to one:
- A second zone in the same region. Covers the loss of one facility, not a regional outage.
- A cloud region in the Kingdom. Google Cloud runs a region in Dammam (me-central2). AWS says its announced Saudi Region is on track for December 2026; do not plan recovery on it until it appears in AWS's list of available Regions.
- A local provider. A Saudi-operated cloud as the recovery site.
- Your own second site. A second data centre, or recovery in an in-Kingdom cloud region for systems you host.
Mixing locations this way is a hybrid cloud design: identity that works at the recovery site when the primary is gone, network paths ready before they are needed, and guardrails that build recovery the same way as production.
Relatedhybrid cloud
Database replication for disaster recovery, with iblync where systems differ
Applications can be rebuilt from code; data cannot, so the database method sets the RPO. Where the database's own replication covers the case, use it first. Where the source and the standby are different kinds of system, iblync real time replication, Interkey's own platform, streams each change to the target shortly after it happens.
Two properties matter for recovery. Changes queue while the target is unavailable and are processed when it returns, so a dropped link loses nothing. Throttling limits what replication takes from production, so catching up after an outage does not slow the systems you are protecting. iblync's website lists sources including MySQL, PostgreSQL, SQL Server and IBM DB2, and where it runs is confirmed per engagement. The lag between source and standby is your real RPO, so it is measured and alerted on.
Read more
Backups need the same care. Keep at least one copy that production credentials cannot change or delete, so ransomware that reaches production cannot reach the copy, and keep it where your classification allows. Record how long each backup is kept, and prove by restoring that it is complete. Interkey's managed service for data platforms includes backup verification by actual restore.
Relatediblync real time replication
Testing disaster recovery: the part most plans skip
A recovery design that has never been exercised is an assumption. A test shows whether backups restore, whether the runbook matches the systems, whether credentials work at the recovery site and how long recovery takes. We plan three depths:
- Restore test. A backup restored to an isolated environment and checked, system by system.
- Walkthrough. The runbook read step by step with the people who would run it.
- Failover test. A system moved to the recovery site and back, with time and data loss recorded against its RTO and RPO.
Each test ends with a dated result and a list of fixes. Repeat on a schedule your policy sets, and after significant changes.
NCA ECC and other expectations, as general context
The National Cybersecurity Authority (NCA) issues the Essential Cybersecurity Controls; the current edition on its site is ECC-2:2024, and its main domains include cybersecurity resilience. NCA's implementation guide names government organisations and their affiliated entities as its scope, and sector regulators may add expectations. Read the current text with your compliance owner. What an assessor asks for is evidence: the agreed RTO and RPO, the design that meets them and the result of the last test. Our NCA ECC guide covers the evidence side.
How a disaster recovery project with Interkey runs
-
Assessment.
Systems in scope, their dependencies, current backups, and an agreed RTO and RPO for each.
-
Design.
A pattern per system, the recovery location your classification allows, the database method and the invocation procedure.
-
Build.
The recovery environment defined as code on the partner cloud or your infrastructure, replication set up and lag monitored.
-
First test.
A restore test and a failover test, with results recorded against the targets and fixes made.
-
Operation.
Backup checks by real restore, replication health and scheduled tests, by your team or by Interkey under a written scope.
What drives the cost and timeline of disaster recovery
There is no list price, because the cost follows the design. Five things drive it: the number of systems, how tight their targets are, the pattern each needs, how much data is copied and kept, and how often recovery is tested. Warm or hot standby carries running cost every month; cold standby and backup carry mostly storage. The timeline depends on the same things, plus how much of the environment is already defined as code. We give both as a range after the assessment, with the reasons.
Read more
Disaster recovery as a service (DRaaS) means a provider runs the recovery environment and the tests for you. With Interkey that is managed services: scope, tests and monthly report written down before the service starts, by a team in Riyadh. It is the wrong fit if your recovery is already tested against targets the business has signed.
Relatedmanaged services
Interkey is a partner of Google Cloud and of AWS; the cloud services practice covers the landing zone and operation recovery depends on.
Relatedcloud services practice
Questions buyers ask about disaster recovery
How do we decide the RTO and RPO for each of our systems?
Ask each system's business owner what an hour of downtime and an hour of lost data would cost, then set targets to match. Most estates end with two or three tiers.
Can our disaster recovery site stay inside Saudi Arabia?
Yes. The recovery copy can sit in a second zone, a cloud region in the Kingdom such as Google Cloud's Dammam region, a local provider or your own second site. Your classification policy decides which are allowed.
How much does disaster recovery cost for a Saudi organisation?
It depends on the number of systems, their targets, the pattern each needs, the data volume and the test schedule. We quote a range after the assessment.
How long does it take to put disaster recovery in place?
It depends on the systems in scope, their targets and how much of the environment is defined as code. We give an estimated range after the assessment; the first recovery test is part of the project.
Is database replication enough for disaster recovery on its own?
No. Replication keeps a standby close to production, but it also copies deletions and encrypted data. You still need separate backups and tested restores.
Who runs our recovery tests and supports us after go-live?
Your team with the project's runbooks, or Interkey under a written managed-services scope. Support comes from our engineers in Riyadh, in Arabic or English, on the Saudi working week.
Next
Related pages
Next step
Plan a disaster recovery design for your systems
Tell us which systems matter most, where they run, whether recovery has been tested, and whether the data must stay in Saudi Arabia. We will reply with the first step we would take.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia