An Odoo backup is PostgreSQL plus the matching filestore—or it is incomplete.

The direct answer: schedule consistent backups of the Odoo PostgreSQL database and its corresponding filestore, preserve required custom addon source and configuration, encrypt the backup, and transfer a copy to remote storage whose credentials and retention cannot be controlled by a compromised app server.

Then restore a selected recovery point into an isolated environment and run business checks. A green “backup completed” notification confirms that a job ran. It does not confirm that every component was captured, the archive decrypts, the data is coherent, or your team can recover within the required time.

Database and filestore form one logical backup

Odoo stores relational data in PostgreSQL. Depending on configuration and content, attachments are stored in the filestore associated with the database. Restoring only PostgreSQL can leave records pointing to missing documents; restoring an unmatched filestore can produce missing or incorrect binaries. Capture a coordinated pair and label both with the database identity and recovery timestamp.

Also preserve the exact custom addon source, dependency information, Odoo release/build information, configuration needed to locate the filestore, and any required secrets through a separate secure secret-management process. A database restored onto incompatible application code may fail to initialize even when its bytes are sound.

Choose tools that fit database size and recovery objectives

For many small and medium installations, a PostgreSQL logical dump plus filestore archive is understandable and portable. Browser downloads are useful for an occasional operator-controlled copy but weak as the sole automation strategy: sessions time out and a human must move and protect the file.

Scheduled PostgreSQL and filesystem-aware jobs offer better automation. Larger environments may require physical backups, write-ahead-log archiving, or managed PostgreSQL features. A filesystem snapshot alone is not necessarily database-consistent; coordinate it with PostgreSQL and the matching filestore.

Odoo’s deployment documentation identifies PostgreSQL as a core part of an on-premise installation and discusses security controls around database access and database management. Follow PostgreSQL’s own documentation for the backup mode you choose; Odoo’s database manager is not a substitute for a full infrastructure recovery design.

Keep a copy inaccessible from the application server

A second directory on the same virtual machine is not a remote backup. Neither is storage mounted read/write with credentials that the app server can use to delete every generation. Hardware failure, accidental deletion, ransomware, cloud-account compromise, or a bad cleanup script can take out production and its convenient local copies together.

Push or replicate completed backups to a separate account, project, tenant, or backup service with object versioning or immutable retention where appropriate. Prefer a design in which production can create new backup objects but cannot rewrite or delete retained generations. Separate backup administration from routine Odoo administration and protect both with multifactor authentication.

Encryption needs two layers: transport encryption while moving the backup and encryption at rest. Control and rotate keys, restrict decryption rights, and make sure key recovery is documented. An encrypted archive whose only key was stored on the failed server is not recoverable.

One current copy cannot answer every failure

Silent corruption or unwanted edits may be discovered weeks later. Keep multiple generations based on tolerance for data loss, legal duties, cost, and detection time. Frequent short-term copies plus daily, weekly, and monthly generations are common, but no schedule fits everyone.

• Recovery point objective: how much recent work can the business afford to lose?
• Recovery time objective: how long can the service and dependent processes remain unavailable?
• Retention: how far back must clean data remain available, and when must personal or regulated data be deleted?
• Capacity: include database growth, filestore growth, transfer time, restore space, and temporary working space.

Monitor age, size, completion, transfer, retention enforcement, and restore-test results. Alert a person with authority to act. A job that creates a zero-byte file every night can look perfectly punctual.

Test recovery without endangering production

1. Select a recovery point according to the runbook, not always the newest archive.
2. Provision an isolated environment with compatible PostgreSQL, Odoo code, dependencies, and sufficient free space.
3. Verify archive integrity and retrieve the decryption key through the documented approval path.
4. Restore PostgreSQL and place the matching filestore under the restored database’s expected identity.
5. Install the exact custom addons and configuration required to start the database.
6. Disable or redirect outgoing email, payment, shipping, webhooks, scheduled actions, and external integrations so the test copy cannot affect real operations.
7. Open representative attachments and test login, permissions, sales, purchasing, accounting reports, inventory, background jobs, and custom workflows.
8. Record elapsed time, data timestamp, failures, manual steps, and corrections to the runbook; securely destroy test data afterward.

A checksum detects certain transfer or storage damage, but it cannot prove semantic correctness. Only an actual restore plus application-level checks answers whether the backup is usable. Test at a frequency proportional to change and business risk, and after changing backup tooling or infrastructure.

Create a verified recovery point before updates and upgrades

Take and verify a fresh backup before operating-system maintenance, Odoo same-major updates, module installation or removal, configuration changes, bulk imports, custom addon deployment, PostgreSQL work, and especially a major-version upgrade. Confirm that the remote copy completed before making the change.

Odoo’s update documentation explicitly instructs administrators to make a copy of the database before updating and warns that downgrading an updated database is not possible. Its upgrade documentation likewise treats testing and data safety as central. Your practical rollback is restoration of the preserved pre-change database, filestore, application code, and configuration—not wishful reversal of schema changes.

For major-version planning, follow our Odoo Community upgrade guide. If previous customizations failed after a migration, see why Odoo upgrades break customizations.

Make the recovery process auditable

• Name the owner, deputy, alert recipient, and person authorized to declare a recovery.
• Inventory databases, filestores, addon repositories, external storage, keys, and dependencies.
• Document backup frequency, consistency method, retention, encryption, remote-copy controls, and deletion policy.
• Keep the runbook available when Odoo and its server are unavailable.
• Record every restore drill and resolve gaps with dates and accountable owners.
• Review provider claims: “daily backup” says nothing about components, isolation, retention, or restoration.

Official documentation

• Odoo on-premise deployment and database security
• Update an on-premise Odoo installation
• Odoo upgrade documentation
• PostgreSQL backup and restore