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.