Restoring

Restoring an instance

Remote or localagainst prod-1

# odoocli instance restore --instance acme

Requires the Community edition

Taking and restoring instance and database backups. Listing and downloading backups that already exist is never restricted, so an unregistered server can always reach its own data.

Available on Community, Developer, Professional, Provider. Below that the operation is refused and nothing is changed.

Restore configuration, like backup configuration, is per instance:

Remote or localagainst prod-1

# odoocli instance restore-config show --instance acme

Remote or localagainst prod-1

# odoocli instance restore-config set --instance acme

Restoring a database

Remote or localagainst prod-1

# odoocli instance database restore --instance acme

The safe pattern for production is to restore alongside rather than over: restore into a new database name, check it, then switch the instance's active database to it.

Remote or localagainst prod-1

# odoocli instance database activate --instance acme

That way the previous database is still there if the restored one turns out to be wrong.

Restore sources

You can restore from any target that is configured for the instance, and from a file you supply.

Reduced without the Professional edition

Below Professional this is not refused. It runs and does less:

• The backup still runs and still writes its local and FTP copies. Each configured cloud target is skipped and recorded as a failed result for that target, so a licence lapse never means no backup at all.
• Backups held at a cloud provider are omitted from the listing.
• Cloud sources are not offered as restore sources; local and FTP sources still are.

Without a Professional licence, cloud sources are simply not offered. Local and FTP sources still are, and a backup file you hand over directly always works. If your only copy is in S3 and your licence has lapsed, fetch the file with your own S3 client and restore it as a local file.

A disaster-recovery drill

A backup you have never restored is a hypothesis. Once a quarter is enough to turn it into a fact.

1. Take a fresh instance backup and note the job id.
2. Create a new instance on the same server, or a scratch server, with the same Odoo version and edition.
3. Restore the backup into it.
4. Initialise nothing. If the restore worked, the database is already there.
5. Sign in to Odoo and check the data you would actually miss: recent invoices, recent attachments, the filestore.
6. Remove the scratch instance.

Two things this catches that nothing else does: a backup that has been silently skipping its cloud target for months, and a filestore that is not in the backup you assumed covered it.

Rolling back a version upgrade

The master database schema upgrade is forward-only. An older binary refuses to start against a newer schema.

That means rolling Antelao itself back is not just reinstalling the old package: you must also restore the master database from before the upgrade. Plan the backup of the master database as part of the upgrade, not as part of the rollback.

Related

• Backup and restore
• Targets
• Schedules