Moving an instance to another server

A move takes an instance off one server and runs it on another as the same instance: the same id, the same names, the same configuration and the same databases. That is different from a copy (a duplicate, or a restore with any preset other than Production), which gets an identity of its own and runs beside its source.

There are two ways to move an instance, and both end the same way: the instance runs on the new server, and the old one still holds a stopped instance until you remove it.

Way	When to use it
Move an instance here	Both servers are running, and the new one has the old one registered as an environment. One action does the stop, the backup, the download and the restore
A backup restored on the new server	The servers cannot reach each other, the old server is gone, or you want to move an archive you already hold

Requires the Professional edition

Restore a complete instance from a backup, duplicate it in one click, move it from another server, or refresh a staging instance from production with a single action.

Available on Developer, Professional, Provider. Elsewhere the operation is refused and nothing is changed.

A move is an outage of that instance

The instance is stopped on the old server before its archive is made, so nothing is written to it after the copy that travels. It is unreachable until it runs on the new server and its names point there. Plan it for a time when the instance may be down for as long as the backup, the transfer and the restore take: the archive travels at the speed of the slower of the two servers' disks and the connection between them.

Before you start

1. Take a backup of the instance on the old server and keep it where you can reach it - a target off the server, or a download to your own computer. Should the move go wrong, this archive and the stopped instance on the old server are your way back.

   Remote or localagainst pelmo

   $ ohm instance backup --instance fanes

2. Check the new server can take it. It needs a license that carries restoring an instance, the same Odoo version and edition on offer, and room on its disks for the archive and what it unpacks to. Its PostgreSQL must be the same major version as the old server's or newer: a database moves forward and never back, and Move an instance here refuses an older one before anything is stopped.

3. If the instance's backups are encrypted, create a backup key on the new server first (Backup storage > Encryption). With Move an instance here the old server then locks the archive for the new server's key too. For a move with a backup, import the old server's key file on the new server instead. An instance that arrives on a server without a key arrives with its encryption switched off.

4. Lower the TTL of the instance's DNS records a day ahead if you can, so the change of address at the end takes effect quickly.

Move an instance here

On the new server's Instances page, the button Move an instance here from another server opens Move an instance here. It is there for an administrator when the console has at least one other server registered and reachable as an environment; a developer workstation is never offered.

1. Choose From server and then the Instance. Only instances this server does not already hold are listed: an instance moves under its own identity, so a server that already holds one with the same id refuses the move.
2. Press Stop it there and move it here.

The move is a job on the new server, followed by a second one:

• the old server stops the instance and makes a backup of it with its credentials portable, so the new server can read them;
• the new server checks there is room, downloads the archive, checks it arrived whole, and queues the import of it as a move: same id, same names, same configuration, same databases.

Follow both on the Jobs page. If anything fails before the import, nothing has changed on the new server and the instance is stopped on the old one but otherwise untouched: start it there again, or run the move again.

Move it with a backup

1. On the old server, switch Portable credentials on on the instance's Backup tab, then take an instance backup. Without it, the storage passwords, the database password, the git provider tokens, the DNS provider's token and the Odoo master password in the archive can be read only by the server that wrote them, and the certificate's private key too unless the archive is encrypted (see Credentials that travel with the archive). Switch it off again afterwards: an archive with portable credentials is a key to your storage.

2. Stop the instance on the old server, so nothing is written to it after the archive:

   Remote or localagainst pelmo

   $ ohm instance container stop --instance fanes

3. Download the archive from the instance's Backup tab, or take it from the target it was written to.

4. On the new server, restore it as a new instance with the Production preset: Restore from backup on the Instances page, or from the command line:

   Remote or localagainst tissi

   $ ohm instance import --archive instance-backup-fanes.zip --preset prod

   Production keeps the instance's id and its database identity. In the wizard, keep the backup's database GUID, since the restore replaces the source, and switch on I understand the consequences of restoring with the Production preset; the command keeps the GUID. See Restoring.

ohm instance restore --from-instance with --from-server is not a move: it copies another server's instance into an instance that already exists here, which keeps its own identity.

After the instance runs on the new server

1. Point the instance's names at the new server in DNS.
2. Check its credentials. They travel with the instance in an archive with portable credentials, which is what Move an instance here makes: the git provider tokens and the DNS provider's token included. The instance's Health tab names every stored credential this server cannot read, and where to enter it again: the git provider tokens on the Modules tab and the DNS provider's token on the Certificate tab.
3. Check the certificate. A certificate the archive carried is served again while it is valid for the instance's names (see The certificate comes back with it). Once the names point here, the next renewal obtains a Let's Encrypt certificate of this server's own; Request certificate on the Certificate tab does it at once.
4. Check the instance: sign in to Odoo, open recent records and attachments, and run Check now on the Health tab.
5. Set its backups up on the new server. Backup targets typed by hand travel with the instance; a container that Backup storage bound on the old server does not. Give it a container of its own with Make and bind, and check its schedule (see Scheduled backups).
6. Remove the instance on the old server once you are satisfied, as Running and removing instances describes. The move never removes it there.

The way back

Until you remove it, the instance is still on the old server, stopped. To go back, remove the instance on the new server, start it again on the old one and point its names back:

Remote or localagainst pelmo

$ ohm instance container start --instance fanes

Anything written on the new server in the meantime is not on the old one. Take a backup on the new server first if you may need it.

Related

• Managing several servers
• Duplicating and importing instances
• Restoring
• Backup encryption