Odoo backup strategy: what to back up, how often, and where

What a complete Odoo backup contains

Every Odoo database has two parts, and you need both to restore it:

• The PostgreSQL database. Customers, products, orders, invoices, journal entries, settings and the list of installed modules.
• The filestore. Attachments, product images, PDFs of invoices, documents and other binary files. Odoo stores these on disk, in a folder named after the database inside its data directory (filestore/<database>).

This is the most common backup mistake we see. A nightly pg_dump looks fine until the day you restore it and every attachment and image is missing. The records still point to files that no longer exist.

Odoo's own database manager (/web/database/manager) avoids this with its zip format. The archive contains dump.sql (a plain SQL dump), filestore/ and a manifest.json listing the Odoo version, PostgreSQL version and installed modules. Its other option, the pg_dump custom format, leaves the filestore out.

What else is worth keeping

The database and filestore are the data. To rebuild a working server quickly you also need:

• Custom and third-party modules. Keep them in Git, not only on the server. A database that expects a module you no longer have will not load cleanly. See our Odoo.sh migration guide for how modules, versions and databases fit together.
• Configuration. The Odoo config file (workers, memory limits, add-ons path), reverse proxy settings and DNS records. Write these down or keep them in version control.
• Secrets. Database passwords, mail server credentials and API keys, kept in a password manager rather than in the backup itself.

How often to back up

Start from one question: how much work can you afford to lose? This is your recovery point objective. If the server dies at 4 pm and the last backup ran at 2 am, everything entered since then is gone and must be re-keyed.

• Daily is the minimum for any production database. Schedule it outside working hours.
• Every few hours during working time suits businesses with a steady flow of orders, point-of-sale sessions or warehouse moves.
• Before every risky change: a version upgrade, installing or updating modules, a large import or a data clean-up script. Take a manual backup and note what it is for. See how to upgrade Odoo 18 to 19 safely.

File-level backups like these cannot give you a recovery point of minutes. For that, PostgreSQL offers continuous archiving of its write-ahead log (WAL) with point-in-time recovery. It is powerful but takes real effort to set up and monitor, and it still does not cover the filestore. Most small and mid-sized Odoo databases are well served by frequent full backups instead.

How long to keep backups

Not every problem is noticed straight away. A wrong import or a bad automated action can corrupt records for weeks before anyone spots it. If you only keep the last three days of backups, every copy you have contains the damage.

A layered retention plan covers both cases:

These are starting points, not rules. Accounting and tax law in many countries requires businesses to keep records for years. Your backups are not necessarily the right place for that archive, but check your obligations before you set short retention on the only copies you have. Under GDPR, also remember that backups contain personal data and should not be kept longer than you need.

For comparison, Odoo's cloud SLA says Odoo.sh keeps 14 full backups of a production database for at least three months: one a day for 7 days, one a week for 4 weeks and one a month for 3 months, replicated across data centers (as of October 2026). That is a sensible benchmark for a self-hosted setup too.

Where to store backups

A backup that lives only on the Odoo server is lost with the server. A disk failure, a deleted VM, ransomware or a compromised account takes production and its backups at the same time.

The classic guideline is the 3-2-1 rule: three copies of your data, on two different kinds of storage, with one copy off-site. For Odoo on a cloud server, a practical version is:

1. The live database and filestore on the server.
2. Recent backups in object storage in the same cloud, for fast restores (for example Amazon S3 if the server runs on AWS).
3. Longer-term backups with a different provider or account, such as an S3-compatible bucket elsewhere, Azure Blob Storage, Google Cloud Storage or an SFTP server you control.

The third copy matters most. If one cloud account is locked, suspended or compromised, you can still rebuild elsewhere. Use credentials for the backup target that can write new files but cannot delete old ones where your storage supports it, and turn on versioning or object lock for the bucket if available.

Protect the backups themselves

• Backups contain everything in your ERP: customer data, prices, salaries. Keep the storage private and restrict who can download from it.
• If you use Odoo's database manager, protect it with a strong master password, or disable it on production servers once you have another way to back up and restore.
• Watch for failures. A backup job that has silently failed for a month is worse than none, because everyone believes it works.

Test your restores

The only proof that a backup works is a successful restore. Schedule one at least once a quarter, and after any change to how backups are taken:

1. Restore the latest backup to a separate instance, never over production.
2. Make sure the restored copy cannot send emails to customers or run scheduled actions against real services before you start clicking around.
3. Log in and check recent records, a few attachments and a printed report. Missing images or PDFs mean the filestore did not come back.
4. Time the whole process. That number is your real recovery time, and it is the one to share with management.

A staging environment is a natural place for this. Refreshing staging from production regularly exercises the same path you would use in an emergency.

For the full recovery process beyond the restore itself, see our Odoo disaster recovery plan.

How CloudPilot handles Odoo backups

CloudPilot runs this strategy from the dashboard, on servers that stay in your own cloud account:

• Complete backups. Each backup is a zip in Odoo's database-manager format, with the SQL dump, the filestore and a manifest. You can download it at any time and restore it through Odoo's own database manager, so you are never locked in.
• Schedules with retention. Add several cron-style schedules per instance, each with its own retention in days and storage destination, for example hourly on weekdays kept for 2 days and nightly kept for 14.
• Offsite storage. Send backups to CloudPilot storage or to your own Amazon S3 or S3-compatible bucket, Azure Blob Storage, Google Cloud Storage or an SFTP server.
• Manual backups and notes. Take a backup before a risky change and add a note so you know what it was for.
• Restores. Restore to the same instance or create a brand-new instance from a backup to test it.
• Failure alerts. A failed backup raises a critical notification, so it does not fail silently.

Manual and daily automated backups are included on Starter, and custom schedules with offsite storage on Pro and Business. See pricing for the full comparison.

If you would rather not run any of this yourself, Odoo.sh handles backups for you with the retention described above, and it is a good fit for teams that want Odoo S.A. to run the infrastructure. Our CloudPilot vs Odoo.sh comparison covers the trade-offs.

A simple checklist

• Every backup includes the database and the filestore.
• Production is backed up at least daily, plus before every upgrade.
• Short-term and long-term copies, with retention you have checked.
• At least one copy off the server, ideally with a different provider.
• Backup storage is private and alerts fire when a backup fails.
• Custom modules and configuration are in Git.
• A restore has been tested in the last three months, and timed.

On CloudPilot, daily and offsite backups are part of managed Odoo hosting on every plan. Under the hood, Odoo database backups rely on PostgreSQL pg_dump.

Frequently asked questions