How to Restore an Odoo Database: Step-by-Step Guide

A successful Odoo restore requires two things:

1. A complete backup
You need both the PostgreSQL dump file (.sql or .dump) and the filestore directory (usually a .tar.gz or .zip). If you only have one, the restore is incomplete — either data without attachments or attachments without data.

2. A working Odoo installation
You must have Odoo installed on the target server with the correct version. Restoring an Odoo 16 database to an Odoo 17 installation will fail. The Python dependencies, Odoo source code, and configuration file must all be present before restoring the database.

Before making any changes to the database, stop the Odoo service to prevent writes during the restore:

sudo systemctl stop odoo

Verify it is stopped:

sudo systemctl status odoo

You should see "inactive (dead)". If Odoo is still running, it may lock database objects and cause the restore to fail or produce inconsistent data.

If you are restoring over an existing database (for example, reverting production to yesterday's backup), you must drop the old database first:

sudo -u postgres psql
DROP DATABASE odoo_production;
CREATE DATABASE odoo_production OWNER odoo;
\q

Replace "odoo_production" with your actual database name. If you are restoring to a new database (e.g., testing a backup), skip the DROP step and create a new database with a different name:

CREATE DATABASE odoo_test OWNER odoo;

Use pg_restore (for .dump files) or psql (for .sql files) to load the backup into PostgreSQL.

For .dump files (custom format, created with pg_dump -Fc):

sudo -u postgres pg_restore -d odoo_production -j 4 /path/to/backup.dump

The -j 4 flag uses 4 parallel jobs to speed up large restores. Adjust based on your CPU cores.

For .sql files (plain text SQL):

sudo -u postgres psql odoo_production < /path/to/backup.sql

Common errors:

• "database does not exist": you forgot to create the target database in step 2
• "role does not exist": the backup references a PostgreSQL user that does not exist on the target server. Create it with: CREATE ROLE odoo LOGIN;
• "permission denied": ensure the postgres user has read access to the backup file

The filestore contains all Odoo attachments: uploaded documents, PDFs, product images. It must be restored to match the database.

Location
The default filestore path is /opt/odoo/data/filestore/DATABASE_NAME/, where DATABASE_NAME matches your database name (e.g., odoo_production).

Extract the filestore backup:

sudo rm -rf /opt/odoo/data/filestore/odoo_production
sudo mkdir -p /opt/odoo/data/filestore/odoo_production
sudo tar -xzf /path/to/filestore.tar.gz -C /opt/odoo/data/filestore/odoo_production
sudo chown -R odoo:odoo /opt/odoo/data/filestore/odoo_production

The chown command is critical — Odoo runs as the "odoo" user and must have write permission to the filestore. If permissions are wrong, attachments will fail to open.

If you are restoring to a new server or a different database name, update /etc/odoo/odoo.conf:

db_name = odoo_production
data_dir = /opt/odoo/data

If the old backup references a different database name or path, Odoo will not find the filestore and all attachments will be broken.

Start the Odoo service:

sudo systemctl start odoo

Check the log for errors:

sudo journalctl -u odoo -f

If Odoo starts without errors, open the web interface and verify:

• You can log in with a known user
• Recent data (an invoice, a sale order) is present
• Attachments open correctly (click on a PDF in a sales order or an invoice)

If attachments are missing:
The filestore was not restored, or the path in odoo.conf is wrong. Check /opt/odoo/data/filestore/odoo_production/ — it should contain subdirectories like "00", "01", "02" with files inside.

If the database is empty or very old:
You restored the wrong backup file, or the backup itself was incomplete. Check the backup timestamp and size before retrying.

ServerChest makes restore a one-click operation:

1. Go to the server's Backups tab
2. Find the backup you want to restore in the history table
3. Click Restore and confirm
4. ServerChest stops Odoo, drops the database, restores the .dump file, extracts the filestore, sets permissions, and restarts Odoo — all automatically
5. You get a success notification when the restore completes (typically 2-5 minutes)

The entire process is logged in the audit trail, so you can see exactly what was restored and when.