Back up and restore an Odoo instance

What a backup contains

An Odoo recovery artifact must keep the PostgreSQL database and filestore together. Tnion.SH creates a full Odoo ZIP archive containing the SQL dump, filestore, and manifest. It records the remote path, size, SHA-256 checksum, status, timestamps, and initiating user.

An empty or truncated output is rejected instead of being recorded as a successful backup.

Create a manual backup

Open a provisioned instance, find Backups, and start a manual backup. Wait until the artifact reaches a successful status before relying on it.

Review the timestamp, size, and checksum. A surprisingly small artifact or repeated failure should be investigated before continuing with a risky change.

Scheduled backups use the same artifact model. The schedule and retention count are platform configuration, so check the values shown by your deployment rather than assuming a universal schedule.

Keep an off-host copy

Backup archives are stored on the registered server. This protects against some application and database mistakes, but not against losing the server, provider account, disk, or region.

Authorized workspace managers can download a completed archive. Move important recovery points to storage with separate credentials, retention, and failure boundaries.

Restore an instance

A restore replaces the target database and filestore. The target must already be provisioned, and the selected backup must be a successful restorable full archive for that instance.

Before replacement, Tnion.SH creates a safety backup of the current target. It stops Odoo, restores the selected archive, and starts the application again. Follow the deployment log until the restore completes.

Confirm the target environment and recovery timestamp before submitting the action. Do not use Production as a first restore test.

Test recovery

Practice on an appropriate non-production environment:

1. Choose a known successful full backup.
2. Restore it to the intended test target.
3. Confirm representative records and attachments.
4. Review application and deployment logs.
5. Confirm neutralization and outbound integrations.
6. Record the observed recovery time in your own runbook.

The checksum shows that an artifact has not changed. A successful restore test shows that the artifact and operating procedure work together.