Key takeaways
- Decide two numbers first: how much data you can afford to lose (RPO) and how long you can be without Odoo (RTO).
- Plan for several kinds of disaster, not just a broken server: a lost account, ransomware, a bad deploy and human error.
- Keep at least one backup copy outside the server's account and provider, and know how to rebuild everything else from code.
- A recovery plan that has never been tested is a guess. Rehearse it at least once a year.
Disaster recovery vs backups
A backup is a copy of your data. Disaster recovery is the whole process of getting the business running again after something goes badly wrong: finding a working backup, getting a server, restoring Odoo with the right version and modules, pointing users at it and checking that it works. Many companies have good backups and still lose days, because nobody has done the rest before.
If you have not set up backups yet, start with our Odoo backup strategy guide. This article builds on it.
Set your Odoo RPO and RTO
Recovery point objective (RPO)
The RPO is how much recent data you can afford to lose, measured in time. With daily backups at midnight, a failure at 5 p.m. loses a day's work, so your RPO is up to 24 hours. If losing a day of orders and invoices is unacceptable, you need more frequent backups.
Recovery time objective (RTO)
The RTO is how long Odoo can be down before the business suffers badly. A shop that takes orders all day may need hours; an office that can work on paper for a day may accept longer. The RTO decides how much preparation you need: a server you can create in minutes, documented steps, and people who know them.
For a reference point, Odoo's own cloud SLA lists disaster recovery targets in hours (check the current page for the figures). Write your own numbers down, and agree them with whoever runs the business.
Odoo disaster scenarios to plan for
The server fails
A disk dies, the virtual machine is lost or the server will not boot. You need a new server and your latest backup. This is the scenario most plans cover.
The provider or region is unavailable
A whole data centre or region goes down. Backups stored in the same region may be unreachable too. A copy in another region or with another provider lets you recover elsewhere.
The account is compromised or ransomware strikes
An attacker with access to your cloud account can delete servers and the backups next to them. Ransomware on the server can encrypt local copies. Protect against this with a backup copy in a separate account or with a separate provider, ideally with versioning or deletion protection, and with credentials that are not stored on the server.
Bad data or a bad deploy
A faulty module update, a wrong import or a mistaken mass edit damages data without any server failing. You need older backups, not just the latest one, and a way to restore to a separate instance so you can compare and copy back only what was lost.
Human error
Someone deletes records, archives the wrong partner or drops a database. The fix is the same as for bad data: keep enough history and know how to restore a copy.
Write an Odoo recovery runbook
A runbook is a short document anyone on the team can follow under pressure. Keep it outside Odoo and outside the server, for example in your password manager or a shared drive. It should include:
- Who decides to start a recovery, and who does each step.
- Where the backups are, how to reach them, and which credentials are needed.
- The exact Odoo version and edition, and where the custom and third-party modules live in Git, with the branch production runs.
- How to create a new server of the right size, in which provider and region.
- How to restore the database and filestore, deploy the modules and check the result.
- How to switch users over: DNS records, their TTL, and the integrations that need the new address.
- How to tell people: staff, customers and partners, and what to say.
Make Odoo easy to rebuild
- Code in Git. Every custom and OCA module should come from a Git repository, so a new server gets exactly the same code. See deploying Odoo custom modules from Git.
- Configuration written down. Workers, limits, email settings and anything else you changed in the Odoo configuration.
- Complete backups. The database and the filestore together, in a format you can restore anywhere.
- Low DNS TTL during an incident. A short TTL on your Odoo domain makes the switch to a new server take effect quickly.
Test your Odoo disaster recovery plan
At least once a year, and after any big change, rehearse a recovery. Pick a recent backup, restore it to a new instance on a different server, deploy the modules, log in and check key figures such as open invoices and stock levels. Time each step. The total is your real RTO, and the age of the backup you used is your real RPO.
Every drill finds something: a missing credential, an undocumented module, a step that only one person knew. Fix it in the runbook, and the next real incident will be shorter.
Odoo disaster recovery with CloudPilot
CloudPilot covers the backup and restore parts of the plan:
- Backups in Odoo's standard format, with the database and filestore, on schedules with retention you set per instance.
- Offsite copies to storage you control on Pro and Business: any S3-compatible bucket, Azure Blob Storage, Google Cloud Storage or an SFTP server.
- Restore to the same instance or another one, so you can recover into a fresh instance and compare before replacing production.
- Create an instance from a backup on any server you have added, including a new one in another region or provider.
- Git-based modules and failed-backup alerts, so the code comes back with the data and a broken backup does not go unnoticed.
See Backups, offsite storage and restores for the steps, managed Odoo hosting for what CloudPilot looks after, and pricing for each plan.
Odoo disaster recovery: questions
What is the difference between RPO and RTO?
The RPO is how much recent data you can afford to lose, set by how often you back up. The RTO is how long Odoo can be down, set by how quickly you can get a server, restore and switch users over.
How often should I test Odoo disaster recovery?
At least once a year, and after any big change such as a major upgrade or a move to a new provider. Restore a real backup to a new instance and time every step.
Where should Odoo disaster recovery backups be stored?
Keep at least one copy outside the server's cloud account and provider, so a lost account, a region outage or ransomware cannot remove every copy at once.