Cloud services · Cloud backup
Cloud backup in Saudi Arabia: copies you have restored, kept where your data may live
Cloud backup is a copy of your data, kept on cloud storage away from the systems that produce it, that you can restore when something is deleted, corrupted or encrypted. The hard questions are not the storage: what is in scope, where the copies may live, how often they are taken and whether anyone has proved they restore. Interkey designs, builds and operates cloud backup on partner cloud platforms and for systems in your data centre, from Riyadh.
Orientation
At a glance
The whole page in one table, before the detail.
- What it protects
- Databases, servers and disks, file shares, object storage and the configuration needed to rebuild
- Where copies live
- A separate account in an in-Kingdom cloud region, or your own second site, as your classification allows
- How often
- Set from each system's recovery point objective (RPO), not from a default schedule
- Protection from ransomware
- At least one immutable copy that production credentials cannot change or delete
- Proof
- Scheduled restore tests with a dated, written result
- What Interkey does
- Assessment, design, build, restore tests and operation, from Riyadh
In short, for decision makers
- Scope first: list what must come back, including the keys a restore depends on.
- The copy follows the data: backups are subject to the same residency rules as production.
- Keep one copy out of reach: an immutable copy is what survives ransomware that reaches production.
- A backup is a claim until restored: budget for restore tests, not only storage.
What cloud backup has to cover, beyond the database
Most backup plans start with the main database and stop there. Before choosing cloud backup solutions, list everything that must come back for a service to work again:
- Databases. The data, and the transaction logs that allow a restore between two full backups.
- Servers and disks. Virtual machines that cannot be rebuilt from code, and their disks.
- File shares. Documents, scans and exports, with their folder permissions.
- Object storage. Buckets of uploads, reports and archives; often the largest data set and the least protected.
- Configuration. Infrastructure code, settings, and the keys a restored system needs to start. A backup encrypted with a key lost with production cannot be read.
Data in software-as-a-service applications belongs on the list too: check what the provider keeps, and whether it covers a deletion by one of your users.
A cloud backup plan by type of data
A starting point for the design, not a fixed schedule: each system's RPO and data volume decide the final numbers.
| Data | Backup method | How often, decided by | How to prove the restore |
|---|---|---|---|
| Databases | Native full and transaction log backups, copied off the host | The RPO: logs copied more often than the data loss accepted | Restore to an isolated instance at a chosen point in time; run the application's checks |
| Servers and disks | Snapshots or images, copied to a separate account | The rate of change, and before every significant change | Start the restored machine; confirm the service runs |
| File shares | Incremental file-level backup with permissions | Working-day change, usually daily | Restore a sample folder and check its contents and permissions |
| Object storage | Object versioning, plus a copy to a separate account or location | Continuous or scheduled, by how the bucket is used | Restore a sample of objects and compare them with the source |
| Configuration and keys | Version control; exported settings; keys in a separate controlled store | Every change | Rebuild an environment from code and the stored settings |
Database backup deserves the most care, because the database is usually where the RPO is won or lost. Keep the log chain unbroken, or a point-in-time restore stops at the first gap.
Where cloud backup copies may live in Saudi Arabia
A backup is still your data. If your classification policy says a class of data must stay in the Kingdom, its backups, snapshots and archived logs must stay too. Our data residency page covers that policy. The usual options:
- An in-Kingdom cloud region. Google Cloud runs a region in Dammam (me-central2). AWS says its announced Saudi Region is on track for December 2026; do not plan backups on it until it appears in AWS's list of available Regions.
- A separate account or project. Backups under different administrators and credentials, so one compromised account cannot reach both.
- Your own second site. For systems you host, a second data centre, or backup from your data centre to an in-Kingdom cloud region.
A copy in the same account and location protects you from a mistake, not from an attacker.
Relateddata residency
Immutable backup: the copy ransomware cannot change
An immutable backup is a copy that cannot be changed or deleted, by anyone, until its retention period ends. Ransomware with administrator rights in production usually looks for the backups first; an immutable copy is the one it cannot encrypt or erase. The object storage on partner cloud platforms can hold objects under a retention lock for this purpose, and the lock is set by people who do not administer production.
Set retention deliberately: a locked copy cannot be shortened if storage costs grow. And do not count replication as a backup: a replica copies a deletion or an encrypted file as faithfully as good data, which is why real time replication sits beside backups, not in place of them.
Relatedreal time replication
How often to back up, and proving that cloud backup restores
The recovery point objective (RPO) is the most data, measured in time, the business can afford to lose; the recovery time objective (RTO) is the longest a system may stay down (see our glossary entry on RTO and RPO). The RPO sets the backup interval: a system with an RPO of one hour cannot rely on a nightly backup. The RTO sets how quickly the copy must come back, and restoring many terabytes over a network takes time no schedule can remove.
Read more
If a system's RTO is shorter than its restore can ever be, it needs a standby copy; our disaster recovery page covers standby patterns and failover tests.
A successful backup job shows that data was written, not that it can be read back into a working system. A restore test answers four questions: is the copy complete, does it restore within the RTO, does the restored system start with its keys and settings, and does anyone besides its author know the steps.
We restore to an isolated environment, check each system with its owner, and record date, duration and fixes. Repeat on a schedule your policy sets, and after significant changes. Interkey's managed service for data platforms includes backup verification by actual restore.
Large backups and object storage migration with iblync
Moving to cloud backup often starts with an archive: years of backups and files that must move into cloud object storage, or between platforms, without gaps. iblync, Interkey's data migration and replication platform, is used for large-scale object storage migration.
What decides how long it takes is object count rather than total size: a million small objects is a different problem from a few large ones. The network path and any egress limits on it matter too. We measure on your estate during scoping rather than quote a throughput figure, and verify moved objects against the source before the old copy is retired.
How a cloud backup project with Interkey runs
-
Assessment.
Systems in scope, current backups and their last restore, volumes, and an RPO and RTO for each.
-
Design.
Method and frequency per type of data, the location your classification allows, the immutable copy and retention.
-
Build.
Backup storage and policies defined as code, with alerts on failed jobs.
-
Migration and first restore.
Existing archives moved where needed, then a restore test of each system, with results recorded.
-
Operation.
Job monitoring, restore tests and retention reviews, by your team or by Interkey under a written scope.
What drives the cost of cloud backup
There is no list price, because the cost follows the design. Storage is the visible part: how much data, how many copies, how long each is kept and whether it is locked. Restore tests, data moved out during a restore and the people who watch the jobs make up the rest. The timeline depends on the number of systems, the archives to move and how much of the estate is defined as code. We give both as a range after the assessment, with the reasons.
Read more
Backup as a service means a provider runs backups and restore tests for you. With Interkey that is managed services: scope, test schedule and monthly report agreed in writing first, by a team in Riyadh. It is the wrong fit if your team already restores its backups on a schedule.
Interkey is a partner of Google Cloud and of AWS; the cloud services practice covers the landing zone and operation that backup depends on.
Questions buyers ask about cloud backup
Can our cloud backups be kept inside Saudi Arabia?
Yes. Copies can sit in an in-Kingdom cloud region such as Google Cloud's Dammam region, or at a second site of your own. Your classification policy decides which locations are allowed for each class of data.
How often should each of our systems be backed up?
As often as its RPO requires. A system that may lose at most an hour of data needs copies more often than hourly; a reporting system may need only a daily one.
Do we need an immutable backup if we already have cloud backups?
If ransomware or a stolen administrator account is a risk you plan for, yes. Anyone with production rights can delete an ordinary backup; an immutable copy stays until its retention ends.
What does cloud backup cost a Saudi organisation each month?
It depends on the data volume, the number of copies, how long each is kept, the restore test schedule and who operates it. We quote a range after the assessment.
How can we tell whether our current backups would actually restore?
Only by restoring them. We restore a sample of systems to an isolated environment and give you a written result.
Who watches our backup jobs after go-live, and is support local?
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 cloud backup for your systems
Tell us what you back up today, where the copies are kept, when a restore was last tested and whether the data must stay in Saudi Arabia. We will reply with a first step.
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