Backup and Disaster Recovery
Planning for UAE Businesses

RPO and RTO - What They Actually Mean for Your Business

Every discussion of backup and disaster recovery starts with two acronyms that are often defined but rarely applied. RPO and RTO need to be set by each organisation based on what data loss and downtime actually cost - not by IT teams working in isolation.

RPO (Recovery Point Objective) is the maximum acceptable data loss, measured as time. If a disaster occurs right now and you can only restore to last night's backup, your RPO is up to 24 hours - you may lose up to 24 hours of data. Whether that is acceptable depends entirely on your business.

A practical UAE example: a medical clinic running an EMR system loses its server on a Wednesday afternoon. If the last backup ran at 2am Wednesday morning, they lose approximately 14 hours of patient records - appointment notes, prescriptions, test results. For a busy clinic seeing 80 patients a day, reconstructing that data manually from memory and paper is a significant operational problem, and potentially a patient safety concern. That clinic should set an RPO of 1 to 4 hours and configure hourly or continuous backups accordingly.

Contrast with a trading company whose critical data is the daily transaction file exported to their ERP at end of business. A 24-hour RPO is entirely acceptable - if they lose the day's work, they can re-enter it from the physical delivery notes and invoices. Their backup priority is ensuring that end-of-day export runs reliably, not continuous replication.

RTO (Recovery Time Objective) is how long the business can tolerate being offline. This is often dramatically underestimated. Business owners say "we cannot afford any downtime" but what they mean is "downtime is expensive." Every business has some tolerance - the question is what it actually is.

System Type	Typical UAE Business	Realistic RTO Target
EMR / Patient records	DHA-licensed clinic	2–4 hours
Live order management	Wholesale trading company	4–8 hours
Finance & accounting ERP	SME with monthly reporting	4–24 hours
Email & collaboration	Most businesses	2–4 hours (Microsoft 365 has built-in redundancy)
CCTV recording archive	Retail / security-conscious businesses	24–48 hours
Staff file server	Most office businesses	4–24 hours

The 3-2-1 Backup Rule - and Why It Is Still the Baseline

The 3-2-1 rule has been the industry-standard backup framework for over twenty years. The numbers mean: 3 copies of your data, on 2 different storage media types, with 1 copy offsite. It remains valid because it protects against the three most common data loss scenarios: hardware failure (covered by multiple copies), media-specific failure (covered by different media types), and site-level events like fire, flooding, or theft (covered by the offsite copy).

What Each Component Looks Like in Practice

The primary copy is your live data - the database, file server, or application data in active use. This is not a "backup" copy; it is the working data. It counts as copy one.

The local backup copy is typically on a NAS device within the same premises - fast to restore from, physically accessible, good for recovering individual files or a single server quickly. This is copy two, on a different medium (NAS vs server storage). Many UAE businesses stop here, which is the gap that matters.

The offsite copy is the one that protects against building-level events. In the UAE context, this means either Azure Blob storage (which keeps data in-country at UAE North or UAE Central), a physical tape shipped to a separate location, or a secondary site - perhaps a Sharjah office or a data centre colocation facility. The offsite copy is what saves you when the on-premise NAS burns with the server room.

Backup Testing: The Part Nobody Does

A backup that has never been tested is a belief system, not a protection mechanism. This is not a provocation - it is a documented reality. When IT teams report "we have backups running," they typically mean backup jobs are running. Whether those jobs complete successfully, whether the data they capture is actually restorable, and whether the restore process works within the required time window are three separate questions that require testing to answer.

We have audited UAE business backup environments where backup jobs were failing silently for four to six months - the NAS was full, new backup jobs were completing with errors, and the monitoring alerts were going to an email address no one checked. The last successful backup was from before the last financial quarter. The business believed they were protected.

What a Proper Backup Test Covers

• Full restore test: Restore the entire VM or server to isolated infrastructure and verify it boots and functions. Do this quarterly for critical systems.
• File-level restore test: Restore a sample of individual files and verify they open correctly. Do this monthly.
• Application-level restore: For SQL Server, restore a database backup to a test instance and run validation queries. For Exchange, verify that individual mailboxes restore and that email is accessible. Do this monthly for critical applications.
• Point-in-time restore: Verify you can restore to a specific point - not just the most recent backup. This is critical for ransomware recovery, where the most recent backup may already contain encrypted files.
• DR failover test: Annually, bring your standby infrastructure live and operate from it for a defined test period. This reveals dependencies, configuration gaps, and process issues that desktop exercises never expose.

Document the outcome of every test: date, what was restored, time taken, issues found, and resolution. This documentation serves two purposes - it proves your backup programme works (useful for audits and insurance purposes), and it identifies degradation in restore performance over time.

Healthcare: DHA Compliance and EMR Backup Requirements

UAE healthcare businesses operating under DHA (Dubai Health Authority) or DOH (Department of Health, Abu Dhabi) licences face specific data retention and security requirements that go beyond what most businesses need to consider.

DHA regulations require patient medical records to be retained for a minimum of 10 years from the date of last treatment, or until the patient turns 21 - whichever is later. For paediatric records, this can mean retention periods of 18 years or more. A backup system that retains data for 30 or 90 days and then purges does not meet this requirement for archived patient data.

Practical Compliance Architecture for UAE Clinics

The approach we recommend for DHA-licensed clinics separates operational backup (fast recovery, shorter retention) from compliance archival (long retention, tamper-evident storage):

• Operational backups: hourly snapshots, 30-day retention on NAS, plus 90-day retention on Azure Blob. Used for disaster recovery and accidental-deletion recovery.
• Compliance archive: monthly full backups retained for 10+ years on Azure Archive (cold tier - low cost per GB). Immutable storage with legal hold capability.
• Access logs: all access to patient data systems logged and retained separately - required for DHA audit trails.

EMR backup must also be application-consistent - not just a file-level copy of the database directory, but a proper SQL backup taken while the database engine is in a consistent state. A file-level copy of an active SQL database file is often not restorable. Veeam and Azure Backup both support VSS-aware application-consistent backups for common EMR databases.

Common Backup Failures We See in UAE Businesses

These are patterns observed across 10+ Years of IT support in the UAE - not hypothetical risks but documented recurring failures:

NAS with No Offsite Copy

The most common configuration we encounter: a server backed up to a local NAS. The NAS provides good recovery for hardware failures and accidental deletion, but a fire in the server room, water ingress from an air conditioning unit failure (more common in UAE buildings than one might expect), or theft takes out both the server and the NAS simultaneously. We fix this by adding Azure Blob as an offsite replication target - typically adding AED 200–500/month in cloud storage costs depending on data volume.

Backup Jobs That Fail Silently for Months

Monitoring of backup job completion is not the same as backup monitoring. A backup job can "complete" with errors - a specific database excluded, a VSS writer failure for one application, or a network timeout that results in a partial backup. Without application-level monitoring that checks for specific error codes in the backup log, these partial completions look like successes. We configure backup monitoring as part of our managed IT service, with alerts on any non-success backup result - not just on job failure.

Exchange Backups That Exclude Attachments

Exchange backups configured without proper attention to the mailbox database structure sometimes result in backups that capture the email message bodies but not the attachments, or that capture the mailbox data but not the public folders. This is discovered at restore time - which is the worst possible time to find out. Verify your Exchange backup by restoring a mailbox to a test environment and checking that attachments are intact.

Backup Target Full - New Jobs Failing

A NAS or backup target that runs out of capacity does not magically create more space. Most backup software will mark jobs as failed when the target is full, but some older systems or misconfigurations result in partial backups or silent failures. Monitor remaining capacity on all backup targets as part of your regular IT maintenance, and set alert thresholds at 70% and 85% - not at 100%.

DR Plan Components Every UAE Business Needs

A disaster recovery plan is not the same as a backup policy. The backup policy covers how data is protected. The DR plan covers how the business resumes operations when something goes badly wrong. These are complementary documents, not the same one.

A workable DR plan covers:

• System tiers with RTO per tier - which systems must be restored first, in what order, and by what deadline. The EMR comes before the staff file server. The order matters when resources are limited.
• Communication tree - who calls whom, in what order, when an incident is declared. Include mobile numbers because email and internal chat may be down. Include the IT provider's emergency contact. Include the business owner or COO if IT leadership cannot be reached.
• Failover procedure documentation - step-by-step instructions for restoring each critical system. Written in enough detail that a competent engineer unfamiliar with your environment can execute them. Procedures that live in one person's head are a single point of failure.
• Vendor and supplier contacts - internet provider escalation contacts, hardware vendor support numbers, software licence keys, cloud service account credentials stored securely offline.
• Recovery testing schedule - the DR plan is tested annually at minimum. The test date, outcome, and any gaps identified are documented. The plan is updated after each test.

Veeam, Acronis, and Azure Backup: A Comparison for UAE SMEs

Next Steps

If you are unsure whether your current backup setup meets the 3-2-1 standard, or if you have backups but cannot remember the last time a restore test was done, a backup audit is a straightforward starting point. Kaizen Star conducts backup and DR assessments for UAE businesses - reviewing your current configuration, testing restore capability, and producing a gap report with prioritised recommendations.

For businesses that need a managed backup service - where an external team monitors your backup jobs daily, investigates failures, and conducts regular restore tests - this is part of our backup and disaster recovery services. It is also included in our managed IT services contracts at appropriate tiers.

Related reading: Cloud Solutions UAE, Server Solutions Dubai, IT Solutions for Healthcare UAE.

Frequently Asked Questions