Your Odoo instance holds the operational heart of your business — invoices, inventory positions, customer records, payroll. The single most-skipped element of UAE Odoo implementations is a proper backup and disaster recovery (DR) strategy. This article shows you exactly what to set up.
The Three Layers of Backup
Layer 1: Database Backups
The PostgreSQL database powering Odoo is the most critical asset. Daily automated database dumps stored off-server are non-negotiable. Standard schedule: every 24 hours, retained 30 days locally, with weekly snapshots retained 12 months.
Layer 2: Filestore Backups
Odoo stores attachments (PDFs, images, documents) in a filestore separate from the database. Filestore backups must run alongside database backups — having one without the other leads to broken document links on recovery. Same daily cadence as database backups.
Layer 3: Configuration Backups
Server configuration files, custom modules, integration credentials. Version-controlled in Git ideally. At minimum, snapshot-backed weekly.
Where to Store Backups
- Off-server primary location — never store the only backup on the same machine as the database
- UAE-local cloud (e.g., AWS Bahrain, Azure UAE, local provider) — for data sovereignty and fast recovery
- Secondary geographic location — for catastrophic regional failure scenarios
- Encrypted at rest — non-negotiable for backups containing customer and employee data
Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
Two metrics that define your DR posture:
- RPO: How much data are you willing to lose? Daily backups = 24-hour RPO. Hourly snapshots = 1-hour RPO.
- RTO: How fast must you be back online? Hours? A day? Multiple days?
For UAE SMEs, typical targets are 24-hour RPO and 4–8 hour RTO. For larger operations or e-commerce, 1-hour RPO and 1-hour RTO are realistic.
The DR Plan Document
A documented DR plan should specify:
- Backup schedule and location
- Who has access to the backup storage
- Step-by-step recovery procedure
- Decision tree for partial vs full recovery
- Communication plan during a DR event
- Frequency of DR drill (test restore)
The Test Restore
An untested backup is not a backup. At least quarterly, perform a test restore to a separate environment and verify the data is intact and the system is functional. The first time you discover your backups are corrupted should not be during a real outage.
Hosting Model Implications
| Hosting | Backups Handled By | Your Responsibility |
|---|---|---|
| Odoo Online (Odoo SA managed) | Odoo SA | Verify retention; export periodic full backups |
| Odoo SH (Odoo’s PaaS) | Odoo SA | Verify retention; export periodic full backups |
| Self-hosted / partner-hosted | You / your partner | Full responsibility — set up, monitor, test |
Common Mistakes
- Trusting that “the server has RAID” — RAID protects against disk failure, not corruption, deletion, or ransomware
- Storing backups on the same network as the production server
- Encrypting backups but storing the encryption key on the same server
- Never performing a test restore
- Skipping filestore backup and only backing up the database
- Backups failing silently — no monitoring alert when a backup job fails
Free 30-minute resilience assessment.