Introduction
An Odoo disaster recovery plan is not simply a backup schedule.
A backup answers one question:
Can we recover data?
A disaster recovery strategy must answer several more:
- How much data can the business afford to lose?
- How quickly must Odoo become available again?
- Which data and files must be restored?
- Who is responsible for recovery?
- What happens to integrations while Odoo is unavailable?
- How will users operate manually during an outage?
- How will the business prove that recovery actually works?
These questions become particularly important when Odoo supports sales, accounting, inventory, manufacturing, purchasing, customer service and other business-critical operations.
Odoo's hosting and security commitments provide important recovery capabilities, but businesses still need to translate those capabilities into their own RPO, RTO, continuity and governance requirements.
Odoo's current security documentation states that, for its Odoo Cloud platform, it retains 14 full database backups for at least three months, with daily, weekly and monthly retention, and replicates backups across at least three data centers. Odoo also states a disaster-recovery objective of 24-hour RPO and 24-hour RTO for paid subscriptions in the documented complete-data-center-disaster scenario.
The important question is whether those recovery objectives match the business's own expectations.
What Is an Odoo Disaster Recovery Plan?
An Odoo disaster recovery plan defines how an organization restores Odoo services, data and dependent business processes after a major outage or destructive event.
It should cover more than database restoration.
A practical plan can include:
Incident → Assessment → Decision → Recovery → Validation → Business Resumption → Reconciliation
The plan should identify:
- Critical Odoo processes
- Recovery priorities
- RPO
- RTO
- Backup ownership
- Hosting responsibilities
- Database recovery
- Filestore recovery
- Integration recovery
- User communication
- Manual workarounds
- Data reconciliation
- Recovery testing
- Post-incident review
The objective is to move from an uncertain emergency response to a controlled recovery process.
RPO and RTO: The Two Numbers Management Must Define
Two terms are central to disaster recovery.
What Is RPO?
Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss measured in time.
For example:
An RPO of four hours means the business accepts losing up to four hours of recoverable transactions in the worst-case scenario.
If the business requires an RPO of 15 minutes but the available recovery mechanism only provides a daily recovery point, there is a significant expectation gap.
Odoo's current security documentation states an RPO of 24 hours for the complete-data-center-disaster scenario where the latest daily backup must be restored.
That does not mean every Odoo outage results in 24 hours of data loss. Odoo describes this as its worst-case disaster-recovery objective when a complete data-center failure prevents local failover.
What Is RTO?
Recovery Time Objective (RTO) defines how quickly the service needs to be restored after a disruption.
For example:
An RTO of four hours means the business expects the service to become operational within four hours of a qualifying disaster.
Odoo currently documents an RTO of 24 hours for paid subscriptions and 48 hours for free trials, education offers, freemium users and similar categories in its complete-data-center-disaster scenario.
Businesses should compare these documented objectives with their own operational requirements rather than assuming that the hosting platform's recovery target automatically equals the company's business continuity target.
Odoo's Current Backup and Disaster Recovery Commitments
Businesses should distinguish between what the hosting provider commits to and what the customer must manage.
According to Odoo's current security documentation, Odoo Cloud maintains:
- 14 full backups for each database for at least three months
- 1 daily backup for seven days
- 1 weekly backup for four weeks
- 1 monthly backup for three months
- Backup replication across at least three different data centers
- Manual backup downloads through the control panel
- Support-assisted restoration of available backups
Odoo also states that hardware failover can use local hot-standby replication for applicable bare-metal services, while its complete-disaster plan relies on replicated daily backups and automated provisioning in another hosting location.
These are important platform-level controls, but organizations should still document their own recovery responsibilities, especially for integrations, custom processes, external systems and operational procedures.
Backup Is Not the Same as Disaster Recovery
A backup is a recovery asset.
Disaster recovery is the complete process used to restore business operations.
For example:
Backup
Database backup exists.
Disaster Recovery
Backup is available → restore environment → verify database → restore files → validate integrations → test critical workflows → authorize users → reconcile transactions → resume operations.
A backup can therefore exist while the organization still has an ineffective disaster recovery capability.
The business should document both.
Database and Filestore Must Be Considered Together
Odoo data is not limited to database records.
Business-critical information can also exist in the filestore, including attachments and binary fields.
Odoo.sh documentation states that its production backups include the database dump, filestore, logs and sessions.
This matters because restoring only the database without the corresponding files can leave an apparently functional system with missing attachments or documents.
Examples include:
- Customer documents
- Vendor attachments
- Product files
- Signed documents
- Invoice attachments
- Images
- Manufacturing documentation
- Other binary fields
A recovery test should therefore validate both transactional data and associated files.
Odoo.sh and Odoo Cloud Should Not Be Treated as Identical
Hosting architecture matters when defining responsibilities.
Odoo's documentation describes different hosting options, including Odoo Online, Odoo.sh and on-premise deployments.
For Odoo.sh, current documentation states that production databases are automatically backed up daily, with seven daily, four weekly and three monthly backups retained. It also states that each backup includes the database dump, filestore, logs and sessions. Staging and development databases are not automatically backed up.
Odoo.sh also provides manual backup functionality for production and staging, with current documentation stating that manual backups remain available for three days and are subject to a daily limit.
This creates an important governance question:
Which environment actually requires independent recovery protection?
Production should normally receive the highest recovery priority, while staging and development may have different requirements.
On-Premise Odoo Requires a Different Responsibility Model
When Odoo is hosted on infrastructure controlled by the organization or its infrastructure provider, the business has additional responsibilities.
These can include:
- Database backups
- Filestore backups
- Backup storage
- Backup encryption
- Off-site replication
- Backup retention
- Monitoring
- Restore procedures
- Server recovery
- Operating system recovery
- PostgreSQL recovery
- Network recovery
- DNS changes
- SSL certificates
- Application deployment
- Custom modules
Odoo's documentation provides mechanisms for creating database backups on on-premise installations, including a ZIP format that includes the filestore.
The important distinction is:
Hosted platform recovery responsibility ≠ on-premise recovery responsibility.
An organization operating its own infrastructure needs to own or explicitly contract the full recovery chain.
Define Business-Critical Odoo Processes
Not every Odoo process has the same recovery priority.
A manufacturing company might prioritize:
- Sales order processing
- Inventory operations
- Manufacturing
- Purchasing
- Accounting
- Reporting
Another business may prioritize accounting and customer communication first.
Create a business impact assessment.
| Business Process | Impact of Outage | Recovery Priority |
|---|---|---|
| Sales Orders | Orders cannot be processed | Critical |
| Inventory | Stock movements delayed | Critical |
| Manufacturing | Production disruption | Critical |
| Accounting | Billing/payment delays | High |
| Purchasing | Supplier operations delayed | High |
| CRM | Customer follow-up affected | Medium |
| Historical Reporting | Decision-making affected | Medium |
| Non-critical Dashboards | Limited operational impact | Low |
The exact classification should be approved by business owners.
Set RPO Based on Business Loss, Not Technology
Avoid choosing RPO simply because a backup schedule already exists.
Instead ask:
How much business data could we realistically recreate manually?
For example:
RPO: 24 Hours
Potentially acceptable for a low-volume system where transactions can be reconstructed.
RPO: 4 Hours
More appropriate where losing a full business day would create significant operational work.
RPO: 15 Minutes
Relevant to highly transaction-sensitive businesses where even a short data gap is material.
The recovery architecture should then be evaluated against that requirement.
If the business requires an RPO lower than the platform's documented disaster-recovery objective, additional controls or a different architecture may be required.
Set RTO Based on Operational Impact
RTO should also be business-driven.
Ask:
How long can the business operate without Odoo before the financial or operational impact becomes unacceptable?
For example:
| Business Type | Example Recovery Expectation |
|---|---|
| Internal administrative use | Longer outage may be tolerable |
| Retail operation | Short outage may be critical |
| Manufacturing plant | Production interruption may quickly become expensive |
| E-commerce operation | Customer-facing disruption may require rapid recovery |
| Finance-heavy operation | Billing and payment delays can become critical |
These are examples, not universal RTO standards.
The business should determine its own acceptable downtime.
Create Manual Workarounds for an Odoo Outage
Disaster recovery should not begin with:
“Wait until Odoo comes back.”
Critical business processes should have temporary procedures.
For example:
Sales
Use controlled offline order capture.
Warehouse
Record critical stock movements using approved temporary documents.
Manufacturing
Continue essential production using controlled work instructions.
Purchasing
Record urgent supplier requirements outside Odoo.
Finance
Maintain controlled transaction logs for activities that cannot wait.
Customer Service
Record critical customer commitments and follow-ups.
The objective is not to recreate Odoo manually.
It is to maintain essential business operations until the system is restored.
Plan for Data Reconciliation After Recovery
Manual work creates another risk.
When Odoo becomes available again, transactions recorded during the outage must be reconciled.
A practical sequence is:
Manual Transaction Log → Odoo Entry → Validation → Duplicate Check → Reconciliation → Business Approval
For example:
| Temporary Record | Odoo Record | Status |
|---|---|---|
| Sales Order 001 | SO/2026/1001 | Recreated |
| Payment 002 | BNK/2026/045 | Reconciled |
| Stock Move 003 | WH/OUT/2026/022 | Pending |
| Purchase Request 004 | PO/2026/018 | Validated |
Without reconciliation, a recovery can restore the system but leave the business with duplicate or missing transactions.
Don't Forget External Integrations
An Odoo recovery plan can fail even when the Odoo database is successfully restored.
Consider integrations with:
- Payment gateways
- E-commerce platforms
- Shipping providers
- Banks
- Marketplaces
- CRM systems
- Payroll platforms
- BI/data warehouses
- Email services
- Customer portals
- Manufacturing equipment
- Third-party APIs
After restoration, the organization must determine:
- Which transactions were sent before the outage?
- Which were received?
- Which failed?
- Which need replay?
- Could replay create duplicates?
- Which external system is authoritative?
- How should mismatches be reconciled?
This makes integration recovery part of the Odoo disaster recovery plan.
Consider Integration Idempotency
Suppose Odoo successfully sends an order to an external system.
The response never reaches Odoo.
After recovery, the integration retries the order.
If the external system does not recognize the original transaction identifier, it may create a duplicate.
Therefore, recovery procedures should consider:
- External transaction IDs
- Idempotency keys
- Duplicate detection
- Event status
- Retry queues
- Reconciliation reports
A recovery test should deliberately simulate interrupted transactions.
Protect Customizations and Configuration
A database backup alone may not represent the complete recoverable application.
Businesses using Odoo.sh or on-premise deployments may also depend on:
- Custom modules
- Custom configuration
- Git repositories
- Python dependencies
- External services
- Server configuration
- Scheduled jobs
- Integration credentials
- DNS configuration
- SSL certificates
Odoo.sh manages application code through its development workflow, but the organization should still document which repositories, dependencies and external systems are required to reproduce the production environment.
For on-premise deployments, these responsibilities become even more important.
Test Restoration, Not Just Backup Creation
One of the most important disaster recovery controls is a restore test.
A backup marked successful does not prove that the business can recover from it.
A restore test should verify:
- Backup can be retrieved.
- Database can be restored.
- Filestore is available.
- Users can authenticate.
- Critical records exist.
- Attachments open correctly.
- Custom modules work.
- Scheduled activities behave correctly.
- Integrations are controlled.
- Critical workflows can be completed.
- Data reconciliation succeeds.
- Recovery time meets the defined RTO.
Odoo states that it routinely uses its daily backups and provisioning scripts in daily operations, which also exercises parts of its recovery mechanisms.
Customers should nevertheless test their own business-level recovery procedures and acceptance criteria.
Use Staging for Recovery Validation Where Appropriate
A recovery copy can be useful for testing.
For example:
Production Backup → Staging Restore → Technical Validation → Functional Validation → Recovery Evidence
Odoo.sh documentation explicitly notes that production backups can be restored to staging branches for testing purposes or to recover accidentally deleted production data.
This provides a useful environment for validating:
- Database integrity
- Custom modules
- Attachments
- Reports
- Workflows
- User access
- Integration behaviour
Care must be taken to prevent a restored test environment from sending real emails, API calls or transactions to external systems.
Define Recovery Roles and Responsibilities
During an incident, unclear ownership can delay recovery.
Define responsibilities before a disaster occurs.
| Role | Responsibility |
|---|---|
| Executive Sponsor | Business recovery decision |
| IT/Infrastructure Lead | Hosting and infrastructure recovery |
| Odoo Administrator | Application validation |
| Database Owner | Data restoration and integrity |
| Integration Owner | External system recovery |
| Finance Owner | Financial reconciliation |
| Operations Owner | Sales/inventory/manufacturing validation |
| Security Lead | Security incident assessment |
| Communications Owner | User and stakeholder communication |
One person may hold several roles in a smaller organization.
The important point is that every critical responsibility has an owner.
Create a Recovery Decision Matrix
Not every incident requires full disaster recovery.
Classify incidents.
| Incident | Example Response |
|---|---|
| User-level mistake | Record-level recovery |
| Deleted document | Backup/data recovery |
| Module issue | Rollback or technical remediation |
| Server failure | Infrastructure failover/recovery |
| Database corruption | Backup restoration |
| Integration outage | Integration-specific recovery |
| Security incident | Containment + security investigation |
| Complete data-center outage | Disaster recovery procedure |
This prevents unnecessary full-system recovery for small operational incidents.
Include Security Incidents in Disaster Recovery
Disaster recovery and cybersecurity are closely related.
A security incident may require recovery from a known-good state rather than simply restoring the latest backup.
Examples include:
- Compromised administrator account
- Malicious data modification
- Unauthorized access
- Malware affecting infrastructure
- Credential compromise
- Destructive integration activity
The recovery process should therefore establish:
Contain → Investigate → Identify Clean Recovery Point → Restore → Validate → Re-secure → Resume
Do not restore potentially compromised data without understanding the incident.
Define Backup Retention Based on Business Needs
A three-month retention period may be sufficient for some businesses and inadequate for others.
Consider:
- Regulatory requirements
- Financial reporting
- Audit periods
- Contract requirements
- Legal retention
- Customer commitments
- Historical reporting
- Recovery from delayed discovery
For example, a problem discovered six months after an incorrect data change cannot necessarily be recovered using a retention policy that only preserves three months of historical backups.
Retention should therefore be reviewed with finance, legal, compliance and IT stakeholders where applicable.
Protect Backups From the Same Disaster
A backup stored in the same failure domain as production provides limited protection.
Odoo states that its Odoo Cloud backups are replicated across at least three different data centers.
Organizations managing their own backups should consider:
- Geographic separation
- Access control
- Encryption
- Backup immutability where appropriate
- Separate credentials
- Monitoring
- Retention
- Restore testing
The goal is to ensure that a production incident does not simultaneously destroy the recovery copies.
Measure Recovery Evidence
A mature disaster recovery process should produce evidence.
Record:
- Backup date
- Backup identifier
- Restore environment
- Restore start time
- Restore completion time
- Data validation results
- Filestore validation
- Application validation
- Integration validation
- Reconciliation results
- Issues discovered
- Corrective actions
This creates a historical record showing whether the organization can actually meet its recovery expectations.
Common Odoo Disaster Recovery Mistakes
1. Assuming Odoo Backups Solve Everything
Hosting backups protect important data, but business continuity also requires processes, integrations, responsibilities and testing.
2. Confusing RPO With RTO
RPO concerns data loss.
RTO concerns downtime/recovery time.
They measure different things.
3. Ignoring the Filestore
A database restoration without required files can result in incomplete business records.
4. Forgetting Integrations
Restoring Odoo does not automatically reconcile every external system.
5. Never Testing a Restore
A backup that has never been restored provides less evidence than a tested recovery procedure.
6. Having No Manual Workaround
Critical business activities may continue even when Odoo is unavailable.
7. No Recovery Ownership
During an incident, uncertainty over who makes decisions can increase downtime.
8. Treating All Outages as Disasters
A minor application issue and a complete data-center failure require different response procedures.
9. Ignoring Custom Modules
Custom applications and dependencies can affect whether a restored environment actually works.
10. Not Reconciling Post-Recovery Transactions
Manual transactions created during downtime can create duplicates or omissions after recovery.
Odoo Disaster Recovery Governance Checklist
Before approving an Odoo disaster recovery strategy, confirm:
- Business-critical Odoo processes are identified.
- RPO requirements are approved by business owners.
- RTO requirements are approved by business owners.
- Hosting responsibilities are documented.
- Backup responsibilities are documented.
- Database and filestore recovery are both addressed.
- Backup retention matches business requirements.
- Backup copies are appropriately protected.
- Custom modules are included in recovery planning.
- External integrations have recovery procedures.
- Manual operating procedures are documented.
- Post-recovery reconciliation is defined.
- Recovery roles are assigned.
- Security incidents have a separate recovery path.
- Restore testing is performed periodically.
- Recovery results are documented.
- RPO and RTO results are compared with business expectations.
- Changes to the Odoo environment trigger appropriate recovery review.
- Stakeholders know how and when to declare a disaster.
- The recovery plan is reviewed periodically.
A Practical Odoo Disaster Recovery Model
A simple governance model can be organized into seven stages:
1. Identify
Determine critical systems, processes, data and dependencies.
2. Define
Set business-approved RPO and RTO requirements.
3. Protect
Maintain appropriate backups, retention and access controls.
4. Prepare
Document recovery procedures, owners and manual workarounds.
5. Test
Perform restore and business validation exercises.
6. Recover
Restore the platform, validate data and reconnect dependent services.
7. Reconcile
Capture missing transactions, verify integrations and formally resume operations.
This turns disaster recovery from a technical document into an operational capability.
How Business Expectations Can Differ From Hosting Commitments
This is one of the most important governance questions.
Suppose the business says:
“We cannot lose more than 15 minutes of transactions and Odoo must be available again within one hour.”
But the documented platform disaster-recovery objective is:
RPO: 24 hours
RTO: 24 hours for paid subscriptions
There is an obvious expectation gap in the worst-case disaster scenario. Odoo's current security documentation explicitly describes these RPO/RTO values for the complete-data-center-disaster case.
The correct response is not to assume that the hosting provider will meet the business requirement.
Instead, the organization should evaluate whether it needs:
- Additional replication
- Independent backups
- More frequent recovery points
- Alternative hosting architecture
- Business continuity procedures
- Offline operational processes
- Additional infrastructure
- Contractual recovery commitments
- A different application architecture
This is why disaster recovery is a business architecture decision, not only a backup decision.
Frequently Asked Questions
1. What is an Odoo disaster recovery plan?
An Odoo disaster recovery plan defines how an organization restores Odoo services, data and dependent business processes after a major outage, data loss, infrastructure failure or security incident. It includes recovery objectives, backups, responsibilities, testing, integrations and post-recovery reconciliation.
2. What is RPO in Odoo disaster recovery?
Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss measured in time. Odoo currently documents an RPO of 24 hours for its Odoo Cloud complete-data-center-disaster scenario where the latest daily backup must be restored.
3. What is RTO in Odoo disaster recovery?
Recovery Time Objective (RTO) defines how quickly the service should be restored after a disaster. Odoo currently documents an RTO of 24 hours for paid subscriptions and 48 hours for certain free or non-paid categories in its complete-data-center-disaster scenario.
4. How often does Odoo back up customer databases?
Odoo's current security documentation states that Odoo Cloud maintains 14 full backups for each database for at least three months: one daily for seven days, one weekly for four weeks and one monthly for three months.
5. Does an Odoo backup include the filestore?
For Odoo.sh, current documentation states that production backups include the database dump, filestore, logs and sessions. The filestore contains attachments and binary fields, making it important to validate files during recovery testing.
6. Does Odoo replicate backups across different locations?
Odoo's current security documentation states that Odoo Cloud backups are replicated across at least three different data centers.
7. Is an Odoo backup enough for disaster recovery?
No. A backup is one component of disaster recovery. A complete strategy should also address RPO, RTO, restoration, integrations, custom modules, manual workarounds, user validation, security, reconciliation and recovery testing.
8. How should Odoo integrations be handled during disaster recovery?
Integrations should have their own recovery procedures covering pending transactions, failed messages, duplicate prevention, replay, authentication and reconciliation. Restoring Odoo does not automatically guarantee that connected systems are synchronized.
9. How often should an Odoo disaster recovery plan be tested?
The appropriate frequency depends on business risk and regulatory requirements. Critical environments should establish a documented recovery-testing schedule and perform restore exercises often enough to demonstrate that the agreed RPO, RTO and business validation requirements remain achievable.
10. What should businesses do if their required RPO or RTO is lower than Odoo's documented objective?
They should identify the gap and evaluate additional technical, hosting or business continuity controls. This may include independent backups, additional replication, alternative infrastructure or manual operating procedures. The objective should be agreed with business and technical owners rather than assumed from the hosting platform.
11. Should Odoo disaster recovery include manual business procedures?
Yes. Critical operations should have controlled temporary procedures for activities that cannot wait for system restoration. Transactions captured during downtime should then be entered and reconciled after Odoo becomes available.
12. Who should own an Odoo disaster recovery plan?
The plan should have an accountable business owner, with responsibilities distributed across IT, Odoo administration, infrastructure, integrations, finance, operations and security. The exact ownership model depends on the organization's structure and hosting arrangement.
Conclusion
An effective Odoo disaster recovery plan begins with business expectations rather than backup technology.
Define how much data the business can afford to lose through RPO, how quickly Odoo must become operational through RTO, and which processes must be restored first. Then connect those requirements to backups, filestore recovery, hosting responsibilities, integrations, custom modules, manual procedures and reconciliation.
Odoo's current platform documentation provides significant backup and disaster-recovery capabilities, including geographically separated backup replication and documented recovery objectives for its Odoo Cloud platform. But businesses should still compare those commitments with their own continuity requirements and test the complete recovery process.
The strongest recovery strategy is one that can answer five questions clearly:
What can we lose? How quickly must we recover? Who is responsible? How do we continue operating? How do we prove that recovery worked?
When those answers are documented, tested and governed, disaster recovery becomes an operational capability rather than a document that is only opened during an emergency.
For organizations evaluating Odoo hosting risks, recovery objectives, backup controls or performance dependencies, an Odoo risk and performance review can help identify recovery gaps and align technical architecture with business expectations.
