Design backup and restore around the whole Odoo database

A backup is more than SQL

An Odoo database contains business records, but attachments and other binary content live in the filestore. A SQL dump without the matching filestore can restore rows while leaving documents, images, and generated assets missing. A filestore without its matching database is equally incomplete.

Tnion.SH uses Odoo’s database export path to create a ZIP archive containing the SQL dump, filestore, and manifest together. After the archive is written, the provisioner reads its size and SHA-256 checksum. Empty or truncated output is rejected rather than recorded as a successful backup.

Where artifacts live

Backup archives are written to the instance’s backup directory on the registered server. The control-plane record stores the remote path, size, checksum, kind, status, timestamps, and initiating user. The archive itself remains on the infrastructure hosting the environment.

This is consistent with BYOS, but it creates an important responsibility: a backup on the same server protects against an application or database mistake, not against losing the server or provider account. Add an off-host copy process that matches your recovery requirements. Tnion.SH exposes backup downloads so an authorized workspace member can move a completed artifact into that wider retention plan.

Scheduled backup support runs on a configured UTC hour and applies a retention count to remote archives. Manual backups use the same underlying artifact path. Check the product’s configured schedule and retention rather than assuming that a database has been covered simply because it is provisioned.

Restore with a safety boundary

A restore replaces the target database and filestore. Before that replacement, Tnion.SH takes a pre-restore safety backup of the current target. It then stops Odoo, ensures PostgreSQL is available, restores the selected full archive through Odoo’s restore path, and starts Odoo again.

The selected archive must still exist on the server and must use the current full-backup format. Older SQL-only archives are not presented as automatically restorable because they cannot reconstruct the complete Odoo state.

For a restore, verify these facts before confirming:

Target environment:  the instance that will be replaced
Backup timestamp:    the recovery point you intend
Archive status:      succeeded and still available
Safety backup:       expected before replacement
Post-restore checks: login, attachments, jobs, integrations

Operational checks that matter

Backups become trustworthy through restoration practice. Build a small recurring exercise around a non-production target:

1. Select a known successful full backup.
2. Restore or clone it into an appropriate target.
3. Confirm representative database records and attachments.
4. Review the application log for module or migration errors.
5. Confirm that neutralization and outbound integrations behave as intended.
6. Record the observed recovery time in your own runbook.

The checksum proves that the stored artifact has not changed since creation. A successful test proves that the artifact, target capacity, Odoo version, and operating procedure work together. You need both kinds of evidence.