Back Up and Restore Odoo Database and Filestore

Odoo Backup Strategy treats the PostgreSQL database and filestore as a single recovery set. The filestore contains attachments and images, so a database-only backup leaves important application content behind. The workflow covers manual backups, shell-script automation, scheduled execution, offsite copies, and the restore sequence needed to verify an Odoo instance can be recovered.

Consistency is central: quiesce Odoo and all writers for the full dump-and-archive interval or use a storage and database snapshot procedure proven consistent. A database dump paired with a live filestore archive from a different state may not form a usable recovery point. The setup should also confirm available space and alert on job failure.

Use it when establishing production backups, automating daily jobs, recovering from server failure or corruption, or diagnosing an unsuccessful backup or restore. Back up immediately before an Odoo upgrade to preserve a rollback point. Monthly restore tests in staging provide stronger evidence than an archive that has never been opened by the application.

The script assumes one database; multi-database installations require handling every database. Odoo.sh built-in backups use their own dashboard workflow. Verify the actual filestore location because Docker volumes and bare-metal installations can differ. Large filestores may need incremental approaches such as rsync or restic rather than full compressed archives.

Inputs include the database identity, verified filestore path, protected backup directory, service account, and installation details. Outputs include a PostgreSQL custom-format dump and matching filestore archive, with optional scheduled and offsite workflows. A database dump command from the example is:

pg_dump -U "$DB_USER" -Fc "$DB_NAME" > "$BACKUP_DIR/db_$DATE.dump"

Restore into a new isolated database and filestore first. Inspect archive entries for absolute paths or traversal, set service ownership, and start a matching isolated Odoo instance with the required data directory and addons. Disable outbound email, cron, payments, and external integrations, then check login, recent records, and attachments. Plan production cutover only after these checks succeed and downtime and rollback are approved.

Cron schedules the example job, and AWS CLI copies archives to S3. Apply retention only after upload verification and a successful restore test, preserving the last known recoverable backup. Follow the three-copy, two-media, one-offsite principle. Encrypt offsite archives and restrict access. Retain configuration, custom addons, dependency versions, and encryption keys securely with the recovery plan. A successful archive listing checks structure; full isolated restoration and application checks establish recoverability.