Backup targets
A target is somewhere backups are written. An instance can have several, and every configured target receives a copy of each backup.
Configuring
In the console, the instance's Backup page. On the command line:
pelmo$ ohm instance backup-config show --instance fanespelmo$ ohm instance backup-config set --instance fanesTargets are keyed by name, so setting one that already exists updates it rather than adding a duplicate.
On the page, each kind has an Add ... provider button, and every provider a Remove provider button; both take effect when you save. A new provider is named when it is added, and keeps that name once saved. What happens to the backups a removed provider wrote is asked when you save: see Removing a policy or a target.
A managed target says who manages it, and its account, container and credential are greyed out in the editor:
- Managed by: Backup storage - this server's own Backup storage section made and bound it. The link goes to Backup storage > Containers, where you unbind it; that also removes it from the instance.
- Managed by: Odoo Management Plane - the Odoo Management Plane that manages this server bound it. It is changed and removed on the plane.
A new instance starts with no providers and its backups Disabled: add a provider here and set the Mode, as Schedule nightly backups describes.
A provider with no key stored reads not configured, and Test connection and Backup now wait until one is saved - there is nothing yet for them to connect with.
Removing a policy or a target
Every target has one or more backup policies: how often it is written to and how many copies are kept. Each policy writes one backup set on the target, named by the policy's set id, and its recovery points are the copies in that set.
When a save removes a policy (Remove policy) or a whole target (Remove provider), the console asks an administrator, for each removed policy, what happens to the recovery points it wrote. The question shows how many recovery points the set holds, how much they take, and what retention still holds of them:
| Choice | What happens |
|---|---|
| Keep | The default. The recovery points stay on the target, and nothing removes them later. |
| Delete | Everything no retention holds is deleted. |
| Delete, lifting the retention | Offered when an Unlocked (Azure Blob) or Governance (S3) retention holds copies: that retention is lifted on those copies and they are deleted too. |
A Locked (Azure Blob) or Compliance (S3) retention, and a legal hold, cannot be lifted by anybody: the copies it holds stay until the date the question shows, and when it holds every copy, Keep is the only choice. The container's or bucket's own retention, on a container managed by Backup storage, is never lifted for one policy, because lifting it would lift it for every policy in the container: the copies it still holds stay until their date.
The deletion starts once the change is saved, one job per policy, and never while a backup of the instance runs. Its result on the Jobs page says how many recovery points it deleted and how much, and what retention kept with the date it is released. Another role than Administrator is not asked: the recovery points stay.
The policies of a managed target are changed, and their data deleted, on Backup storage >
Containers, which also lists the backup sets no policy writes any more. On the command line,
give the set id, and add --delete-data to delete the recovery points as well:
pelmo$ ohm instance backup-config set --instance fanes --remove-policy 3f2b6c1e-8d4a-4c7e-9a51-2e6f0b9d7c44 --delete-data--lift-retention beside --delete-data also deletes what an Unlocked or Governance retention
holds. A policy's set id is shown as Set id under the policy on the Backup page.
The four kinds
Local filesystem
A directory on the server. The fastest option and the least useful in a disaster: a local backup does not survive the machine.
Put it on separate storage from the instance root if you can. The defaults keep everything under
/var/lib/odoo, which means one failed disk takes both.
FTP
An FTP or FTPS server. Available on Community, Professional and Provider, which makes it the off-site option for Community installations. The Developer edition does not carry it, and an unregistered server takes no backups at all.
Encryption is the connection's, and a new target starts on Explicit TLS (recommended):
| Encryption | What travels |
|---|---|
| Explicit TLS | Everything encrypted, after the server is asked to switch to TLS. What almost every FTPS server offers. |
| Implicit TLS (FTPS) | Everything encrypted from the first byte, usually on port 990. |
| Auto - can fall back to unencrypted | TLS when the server offers it, and plain FTP without a word when it does not: the archive and the password then cross the network readable. A target made before Explicit TLS became the default may still be on it; the instance's health check flags it. |
| None - unencrypted | Plain FTP, chosen deliberately: saving needs Send unencrypted ticked. Only for a server on a network you trust and that has no TLS. |
The connection's encryption is not the archive's. To have the archive itself locked, whatever the target, switch on backup encryption.
Amazon S3 and S3-compatible
Any S3-compatible endpoint works, not only AWS: the configuration takes an explicit service URL, region, bucket and prefix.
Azure Blob Storage
Configured with a storage account, an access key and a container.
Credentials
Target credentials are write-only through the API. You can set them and you can replace them; nothing reads them back. A read tells you only whether one is set. They are never included in a configuration export, a job payload, a job result or a log: a submitted secret travels as an opaque reference that the handler redeems once.
Three fields are treated as secrets: the FTP password, the S3 secret key, and the Azure storage account key. An S3 access key is not one - it is an identifier, like a username - so it is stored plainly and read back.
At rest the three are encrypted under the management API's key ring.
The key ring lives in the Docker volume ohm-api-keys. Lose it and every stored credential on the
server - these, the SMTP password, the GeoIP key - becomes unreadable, and a master-database backup
alone will not bring them back. Export the master database with a passphrase so the key ring goes
with it, as Backing up the server itself describes.
Prefer credentials scoped to exactly the bucket or container they need, so a leak costs you one prefix rather than an account.
Credentials that travel with the archive
Because those ciphers are readable only on the server that wrote them, an instance restored somewhere else arrives with no provider passwords in them.
The instance's Backup page has a switch for this: portable credentials. With it on, the archive manifest is written in a transport form - the credentials beside the ciphers - so the archive restores with working credentials on any server, and they are re-protected under the target's own key ring on import.
The instance's Odoo master password - the one Odoo's database manager asks for - follows the same switch. An archive written without portable credentials does not carry it, and the instance restored from it gets a new one. With portable credentials on, the archive carries it, and an instance moved to another server under its own identity keeps it. A copy restored beside its source always gets a master password of its own. Archives written by earlier releases carry the master password in plain text whatever the switch said; delete them when you no longer need them, or keep them as secrets.
Anyone who obtains it can read those passwords, and therefore reach the storage they unlock - including the backups already there. The switch is off by default and the page states the trade-off where you flip it.
Leave it off for archives that never leave the server, and turn it on for the ones you intend to restore elsewhere.
With it off, nothing is lost silently: uploading an archive here names the credentials this server could not read, so you know what to re-enter before the instance runs. See Restoring.
The instance certificate's private key follows the same switch, and encryption too: it is in the archive readably only when every copy of the archive is encrypted, or when it is written with portable credentials. Otherwise it is enciphered for this server, so a restore elsewhere requests a new certificate rather than serving this one.
When a target fails
A backup does not stop at the first failed target. It attempts every one and records a per-target result, so a broken S3 credential does not cost you the local copy.
The license case is different: a target the license does not carry is not left to fail. It is switched off, keeping its settings and credentials, and switched on again by itself when a license carries it. See When the license changes.