An Odoo backup you have never restored is not a plan - it's a hope with a filename. Almost everyone has backups. Far fewer have ever restored one, which means far fewer actually know whether their backups work. You find out on the worst possible day, in the middle of an outage, that the archive is corrupt or the filestore was never included. This is how to set up backups, monitoring and a recovery you've genuinely rehearsed - so "the server died" becomes an inconvenience, not a catastrophe.
The backup nobody tests
The uncomfortable statistic that circulates among people who do this for a living is that a large share of backup attempts fail at recovery time - the archive is unreadable, the filestore is missing, or the process was never actually tested end to end. An Odoo backup is especially easy to get half-right, because Odoo stores data in two places: the PostgreSQL database and a separate filestore of attachments and documents. Dump the database and forget the filestore, and your restore comes back with every invoice PDF and uploaded document gone. The backup looked fine. It just wasn't complete, and nobody checked.
Back up both halves, on a schedule
A real Odoo backup captures both halves and does it automatically. Manual backups get forgotten; a scheduled job doesn't. The mechanics are well-understood: pg_dump for the database, an archive of the filestore directory, combined into a single dated bundle so a restore has everything it needs in one place. Schedule it to run on its own, and verify that the job actually produced a file - a cron job that silently failed three weeks ago is its own kind of trap.
Get the copies off the box
A backup that lives on the same server as the thing it's protecting isn't disaster recovery - it's version history. If the server dies, is compromised, or is deleted by accident, the local backup dies with it. So the copies have to be pulled off the box, ideally to different infrastructure in a different location. That's what protects you against the failures that actually take companies down: hardware loss, a compromised host, a fat-fingered rm. Off-site is the difference between a bad afternoon and a bad quarter.
When an agent provisions a system, this is something it can set up on day one rather than "later" - scheduled backups, pulled off the box automatically, as part of the same install that stood up the instance. It's the run layer of what the agent can do, and treating it as part of provisioning is how it stops being the task everyone means to get to and never does.
Rehearse the recovery
Here's the step that turns backups from theatre into a real plan: the restore drill. You stand the backup up somewhere clean - a throwaway environment - and confirm it actually comes back: the database loads, the filestore is intact, the data is correct, the app runs. A successful archive check only proves the file is readable. Only a full restore proves that Odoo can load the database and filestore together. Those are different claims, and the gap between them is where disasters live.
We reboot-tested and restore-tested our own recovery for exactly this reason - a runbook you have never run is fiction. The recommended cadence is modest: a periodic restore of a recent backup to a test database, verify the data, tear it down. Half an hour of proving it works beats an hour of discovering it doesn't while customers wait. And because it's a clean throwaway environment, the drill itself is safe - the same care that governs a migration applies here.
Monitoring closes the loop
Backups tell you that you can recover; monitoring tells you when you need to. Uptime and health checks watch the instance so you hear about trouble before your customers do - a service that's down, a disk filling up, a backup job that didn't run. Together, off-site backups, a tested restore and active monitoring turn the failure of any single component into something routine and recoverable. None of it is exciting, which is exactly the point.
Boring on purpose
Good operational hygiene is deliberately dull. Monitoring you don't think about, backups pulled somewhere safe, and a recovery you've actually rehearsed are what convert "the server died" from a company-ending event into a line in the incident log. That's the whole ambition - not heroics during a crisis, but a crisis that never becomes one because the boring work was done first. If you'd like an agent to set this up on day one, it's part of Zoxron MCP.
FAQ
How do I back up Odoo properly?
Capture both the PostgreSQL database and the filestore - an Odoo backup that skips the filestore loses every attachment. Automate it on a schedule with pg_dump plus a filestore archive, bundle them together, and pull the copies off the server to separate infrastructure so a host failure can't take them with it.
How often should I test my backups?
Regularly, and on a real restore - not just an archive check. Restoring a recent backup to a throwaway database and verifying the data takes about half an hour and is the only thing that actually proves recovery works. A monthly drill is a reasonable baseline; the exact cadence matters less than doing it before you need it.
What's a good Odoo disaster recovery plan?
Three parts: automated backups of the database and filestore, copies stored off-site on separate infrastructure, and a rehearsed restore drill that proves the backup comes back cleanly. Add monitoring so you learn about failures early. A recovery you've actually run is a plan; one you've only written down is a hope.