Duplicate production to test

Reproducing a bug on real data should not be a project. A backup of production restores into a fresh environment in a few clicks, and the original does not move.

The one thing to understand before clicking is that there are two restores, and they do very different things.

What a backup holds

A backup takes the environment's PostgreSQL database and its filestore — the attachments, images and documents. Both, together: a database restored without its filestore gives you an Odoo that opens and in which every attachment is broken.

It is stored separately from the environment, not on its disk — which is what lets a backup outlive a broken environment. It does not outlive a deleted one: deleting an environment purges every backup of it, archives included. Download what you want to keep before you delete.

Every backup carries a size, a date and an expiry. The expiry comes from the retention policy, not from you: a backup can disappear on its own, and that is the setting to check before relying on an old copy.

Taking a backup

The environment's Backups tab. The button starts one immediately; it appears in the list with its status while it runs.

Beside it, Automatic backups defines a policy: a frequency and a retention in days. Daily at 02:00 UTC is the usual setting.

Manual backups and the policy are not alternatives. Before anything risky — a version bump, a module import — take one by hand: the newest scheduled backup may be several hours old.

Two ways to restore

This is where the distinction matters, and both actions sit side by side on the backup's row. They do not look alike, though: Restore is a labelled button, while the clone is the copy icon next to it — its tooltip reads "Create a new environment from this backup". The heading "Clone to a new environment" only appears once the dialog is open.

Restore puts that backup back into the current environment. It overwrites what is there. Two things happen before you have time to hesitate: a safety copy is taken automatically, and the environment restarts. So you lose everything written since the backup you chose — and the safety copy is not the undo button it sounds like: it is kept by the platform, it does not appear in this list, and you cannot restore it from here. If you want a copy of the current state that you control, take a backup before you restore. The backups guide covers this in full.

Clone to a new environment creates a fresh environment from that backup. The source is not touched at all. This is the one to choose nine times out of ten: to reproduce a bug, run an acceptance test, or show something to a client, there is no reason to put production at risk.

The clone asks for three things: an environment key (the lowercase identifier, unique within the instance), a display name, and a Git branch. All three are pre-filled from the source — the name followed by "(copy)", the key suffixed with "-copy", the same branch — and all three remain required.

What the clone carries over, and what it does not

It carries over the repository and the resource template of the source environment: the new environment therefore builds the same code, on the same machine size.

Two things it does not carry:

• Auto-deploy is off. A clone exists to freeze a state, not to follow the branch. If it redeployed on the first push, the state you wanted to examine would disappear while you were examining it.
• Billing starts as pending. A clone is a full environment: it consumes resources and is billed as one once active. It is not a free copy, and the best habit is to delete it once the question that created it has been answered.

Importing an existing dump

You can also restore a database that did not come from here. The import happens in two steps: the browser uploads the file straight to object storage, then the platform registers it as a backup of this environment. It then appears in the list and restores like any other.

The upload goes from the browser to storage, without passing through the platform. That is what makes a multi-gigabyte file possible — and it is also why a failure at that step says little: the error comes from storage, not from the application. An import that fails immediately is almost always the file size or a dropped connection, not the backup itself.

Following a restore

The tab keeps a restore history: the ones you start from this screen, in place or from a backup. Each one exposes its logs.

Restores that ran during the creation of an environment are somewhere else — under "provisioning restore logs", on the same tab. That is the distinction that matters when a clone will not start: the restore that failed is not in the history, it is in the provisioning logs.

A restore takes as long as the database takes. A large one runs for tens of minutes, and an environment that stays in "creating" is not necessarily stuck.

Testing a restore before you need it

A backup you have never restored is a belief, not a guarantee. The only way to know it contains what you think is to restore one — and the clone makes that test free of risk.

A useful test is four steps:

1. Clone the most recent backup into a throwaway environment.
2. Open Odoo and sign in.
3. Check an attachment, not only a record: the filestore is what is missing when something is missing.
4. Delete the clone.

Do it once after going live, then after every plan or version change. The day you restore for real, you will already know how long it takes and what the result looks like.