Your Odoo has a backup, but has it ever been restored

Ask an Indian SME running Odoo one question - "when did you last restore your backup into a clean server and log in to check it?" - and the room goes quiet. There is a backup. It runs nightly. Nobody has ever restored it. That is not a safety net, it is a folder of files you are hoping will work on the worst day of the year. And on that day - a disk failure, a bad migration, a ransomware note, an accidental "delete all" on a production model - you find out whether the hope was justified. This runbook is how you stop hoping and start knowing.

The two halves of an Odoo backup (miss one and the restore is broken)

An Odoo instance is not one thing to back up. It is two, and they must be captured together or the restore is worthless:

• The Postgres database. Every record - customers, orders, invoices, journal entries, stock moves, users, and settings - lives here. This is what most people mean when they say "the backup".
• The filestore. The actual files - PDF invoices, product images, uploaded attachments, email logos - are not in the database. They sit on disk under ~/.local/share/Odoo/filestore/<dbname> (or the path your data_dir points to). The database only stores a checksum that points to each file.

Here is the trap. If you back up only the database and restore it, Odoo boots, the data looks perfect - and every attachment is a broken link, because the files the checksums point to are gone. A GST invoice that will not open is not a small problem when an auditor asks for it. A backup that skips the filestore is not half a backup; it is a broken one.

Decide two numbers first: RPO and RTO

Before you pick a single tool, write down two numbers in plain business terms. They drive every other decision.

• RPO - recovery point objective. How much data can you afford to lose? If your last good backup is from midnight and the server dies at 4pm, you have lost a day of orders, invoices, and stock moves. If that is unacceptable, a nightly backup is not enough - you need more frequent database backups or continuous archiving.
• RTO - recovery time objective. How long can you be down? Restoring a 40 GB database and syncing a filestore onto a fresh server can take hours. If you cannot be offline that long during month-end billing, you need a warm standby, not just a file in cloud storage.

For a typical Indian SME running billing, inventory, and accounting on Odoo, a common honest answer is "lose at most one hour, be back within four". That single sentence tells you to run hourly database backups, keep the filestore synced continuously, and pre-provision a target server - not to rely on a nightly dump you copy by hand.

The backup methods, from smallest to real

1. The built-in database manager (small instances only)

Odoo ships with a backup at /web/database/manager that produces a single zip containing the database dump and the filestore together. It is genuinely useful for a small, single-company database. Its limit is size: past a few GB of filestore the request times out or runs the server out of memory, and it is a manual click, not a schedule. Treat it as a convenience for small setups and manual pre-migration snapshots, not as your production strategy.

2. pg_dump plus a filestore sync (the working default)

Once you outgrow the manager, split the two halves and script them. Use pg_dump for the database (custom or directory format, compressed) and a file sync - rsync or your cloud provider's tool - for the filestore. Run both on a schedule with cron, tag each with a timestamp, and immediately push them off the server to object storage in a different location. A backup that lives on the same disk as the database dies with it. If you already fight Odoo performance, run the dump against a read replica or in a low-traffic window so it does not add load - the same discipline we cover in why your Odoo is slow.

3. Continuous archiving and a warm standby (tight RPO/RTO)

When "lose at most a few minutes" and "be back in under an hour" are real requirements, move to Postgres continuous archiving (WAL archiving / point-in-time recovery) and keep a standby database replicating live. This lets you restore to any point in time and fail over fast. It costs more to run and maintain, which is exactly why you set the RPO/RTO numbers first - you buy this tier only when the business genuinely needs it.

The restore drill: the only test that counts

A backup is a theory. A restore is the proof. Put a quarterly restore drill on the calendar and run it like the real thing:

1. Spin up a clean server or container that matches your production Odoo and Postgres versions - a mismatch here is where real restores fail.
2. Restore the database dump, then drop the filestore back into the matching data_dir path so the checksums resolve.
3. Boot Odoo, log in, and check real things: open a recent GST invoice PDF, confirm stock levels for a fast-moving product, run a report that touches accounting.
4. Time it. The clock from "server is dead" to "team can work" is your true RTO - not the number you wrote down, the one you just measured.

Teams are regularly shocked here: the nightly job had been silently failing for weeks, or the filestore was never in scope, or the restore takes six hours when the business assumed one. Far better to learn that in a Tuesday drill than during a live outage. If you run Odoo on a cloud VM, fold this into how you manage the whole environment - our managed cloud services and AWS consulting teams treat the restore drill as part of running the box, not an afterthought.

Automate the schedule, and watch it

A backup nobody watches is a backup that fails in silence. Two habits fix that. First, run the jobs on a reliable schedule and alert on failure - if the nightly dump does not complete, a human should hear about it that morning, not discover it during an outage. Odoo's own scheduling has sharp edges worth knowing before you lean on it, which we cover in Odoo scheduled actions, cron, and automation rules. Second, protect access to the backups themselves - dumps contain every customer record and invoice in your business, so they need the same access discipline as production, in the spirit of Odoo access rights and record rules.

Disaster recovery is more than files, too. If your business would grind to a halt without Odoo, the plan should name who does what during an outage and how you communicate - the operational side we discuss in manufacturing disaster recovery for Odoo. This runbook is the technical spine of that plan.

Frequently asked questions

Is Odoo.sh or Odoo Online's automatic backup enough on its own?

It is a strong starting point - Odoo.sh keeps rolling daily backups and Odoo Online backs up for you - but "someone else has a backup" is not a recovery plan. You still need to know your RPO and RTO, keep an independent copy you control (so a single-account problem cannot take both), and have actually restored one so you know the moving parts. Managed backups reduce the work; they do not remove the responsibility to test.

How often should we back up?

Your RPO answers this. If losing a day is fine, nightly is enough. If losing an hour of billing is not, you need hourly database backups or continuous archiving. Do not pick a frequency from habit - derive it from how much data the business can actually afford to lose.

Can we just take a snapshot of the whole VM instead?

VM snapshots are a useful extra layer, but on their own they are a blunt instrument: they are heavy, hard to restore a single database from, and a snapshot taken while Postgres is mid-write can be inconsistent. Use them as a coarse safety net alongside proper database dumps and filestore syncs, not as a replacement for them.

Where should backups be stored?

Off the server, in at least one other location, and ideally with one immutable copy that ransomware or a bad script cannot overwrite. Object storage in a different region is a sensible default. The rule of thumb worth keeping: a backup on the same machine as the database is not a backup, it is a second copy waiting to die with the first.

The short version: an Odoo backup has two halves, a real backup is one you have restored, and the design falls out of two honest numbers - how much data you can lose and how long you can be down. Get those right, drill the restore every quarter, and the worst day of the year becomes a four-hour inconvenience instead of an existential one. If you want a second set of eyes on your setup, our Odoo support and implementation teams do exactly this.