Skip to main content

Duplicating and importing instances

Duplicating

Duplicating an instance is exactly what it sounds like, and mechanically it is a backup followed by a restore into a new instance. That is a deliberate design: it reuses the two code paths you already trust, rather than adding a third one that copies things.

It is an administrator-only operation.

The normal uses are making a staging copy of production, and giving a developer a real dataset to work against.

A duplicate is not a test of your backups

It is close, but it restores through a path you control end to end on one machine. A real drill restores onto a different server from the backup that actually left the building. See the drill in Restoring.

The production preset is refused

You cannot duplicate an instance into the Production preset. The new instance would collide with the original on identifiers that are supposed to be unique, and two instances believing they are the same production instance is a worse outcome than a refused operation.

Duplicate into a staging or development preset and promote it deliberately if that is what you want.

The working directory

The duplicate needs a working directory, and it must be a sibling of the per-instance backup directories rather than inside one of them. A working directory nested inside a backup directory ends up inside the next backup, which grows without bound.

Importing

Importing brings an instance that already exists on the host under Antelao's management, rather than creating one from scratch.

Remote or localagainst prod-1
# odoocli instance import

This is the path for adopting an instance built before Antelao, or recovering management of one whose configuration was lost.

Importing a configuration is a different thing

Do not confuse instance import with instance config import. The second one replaces an existing instance's configuration, and carries a serious hazard:

An imported configuration brings the source's active database name with it

Import a configuration exported from another instance and the target now believes it owns the source's database. Removing the target then attempts to drop the source's live database.

An ownership check is the only thing standing in the way. Use configuration import to build a new instance, never to edit one that holds live data.