Restoring a backup
Restoring a backup: what is in the archive, how to put it back, and how to rehearse it before you need it.
This module deliberately does not restore. Restoring overwrites a database, which is the single most destructive thing anyone does to an Odoo installation. A button that does it can be clicked by accident, clicked on the wrong environment, or clicked by someone who has not read what it says. So restoring stays where it belongs: at a command line, taken deliberately.
Here are the commands.
Before you start
- Know which database you are overwriting. Say it out loud.
- Take a fresh backup of the database you are about to replace, even the broken one. It may hold the only copy of something.
- Stop Odoo. Restoring under a running server produces a database in a state neither of them agrees with.
sudo systemctl stop odooRestoring a ZIP backup (database + filestore)
A ZIP made by this module contains dump.sql, a manifest.json and a filestore/ folder. This is Odoo's own format, so Odoo's own tooling reads it.
Through the web interface
- Go to https://your-server/web/database/manager.
- Choose Restore Database, upload the ZIP, give the new database a name, and enter your master password (the admin_passwd in your Odoo configuration file).
- Decide about This database is a copy. Say yes for a test or staging restore — it clears the enterprise subscription code so the copy does not fight with production over it. Say no only when this restore is the production database.
This is the simplest route, and it is limited by your web server's upload size. On a large database use the command line instead.
From the command line
# 1. Unpack
mkdir /tmp/restore && cd /tmp/restore
unzip /var/backups/odoo/mydb_2026-08-29_02-00-00.zip
# 2. Create an empty database owned by the Odoo user
sudo -u postgres createdb -O odoo mydb_restored
# 3. Load the dump
sudo -u postgres psql -d mydb_restored -f dump.sql
# 4. Put the filestore where Odoo expects it
# (adjust the data dir to your own; ~/.local/share/Odoo is the default)
sudo rm -rf /var/lib/odoo/.local/share/Odoo/filestore/mydb_restored
sudo cp -r filestore /var/lib/odoo/.local/share/Odoo/filestore/mydb_restored
sudo chown -R odoo:odoo /var/lib/odoo/.local/share/Odoo/filestore/mydb_restored
# 5. Start Odoo
sudo systemctl start odooStep 4 is the one people skip. Without it the database restores perfectly and every attachment, logo and product image is gone.
Restoring an SQL-only backup
An SQL dump has no filestore. Attachments will be missing and there is no way to get them back from this file — that is the trade you accepted when you chose the format.
sudo -u postgres createdb -O odoo mydb_restored
sudo -u postgres psql -d mydb_restored -f mydb_2026-08-29_02-00-00.sqlAfter restoring a copy for testing
If this is a test or staging copy rather than production, neutralise it before anyone touches it, or it will email your real customers:
sudo -u postgres psql -d mydb_restored -c \
"UPDATE ir_mail_server SET active = false;"
sudo -u postgres psql -d mydb_restored -c \
"UPDATE ir_cron SET active = false;"Also check any outgoing webhook, payment provider and delivery-carrier credentials. A staging copy with live payment keys is a production system wearing a disguise.
Testing that your backups actually restore
A backup nobody has ever restored is a hope, not a backup.
This module verifies that each archive is readable and contains a dump, which catches truncated and corrupt files. It cannot tell you the database inside will come up. Only a restore tells you that.
Do it once a quarter:
- Restore the most recent backup to a scratch database.
- Start Odoo against it.
- Log in and open one invoice, one product and one attachment.
- Drop the scratch database.
Half an hour, four times a year, and you will know rather than assume.
If the restore fails
- "role odoo does not exist" — the dump refers to a database owner that does not exist on this server. Create it, or restore with --no-owner --role=your_role.
- A version mismatch — a dump from a newer PostgreSQL will not load into an older one. Check both with psql --version.
- Odoo starts but every page errors — usually a missing custom module. The restored database expects the modules that were installed when it was dumped; put them back on the addons path and restart.
- Attachments missing — step 4 above.