Hibou Roost - Odoo: Odoo Database Management: Database Copy

This document covers two methods you can use to create a copy of your Odoo database.

Odoo typically includes two pieces:

1. The Postgres database
   

2. The 'filestore' (typically a directory with ~250 additional directories in it (to spread out the files across 2 characters of the hash of the file content, the files themselves are stored without file extension and hashed by content).
   

Copying a database is a very common operation and should have predictable performance and minimal resource usage.

For example, say you have a database you use as a production environment and need to make a copy to try out a new application or setting choice. You would want the fastest copy that takes up the least amount of space! You would probably also want that new database to NOT receive email preventing your production environment from receiving it.

Processes

Odoo Database Manager

Odoo has a database manager that may be accessed via the route /web/database/manager

To use it, you will need the so called 'master password' of the installation. You can use the database manager with a regular browser, and has a built in way to copy a database.

The major limitation is that you must have the route open, and it is tied to the timeouts of a regular web worker process (i.e. it is possible for it to not complete and leave you with a 1/2 way working database).

A duplication event here will essentially be the same as --pg_strategy fast_copy_template --filestore_strategy copy when using Hibou Flow.

Hibou Flow Copy

Hibou Flow is built into our Suite containers, and containers built from Suite (customer images). There are numerous command line flags, but only a couple are typically needed to achieve desired results.  

While Flow has its own entrypoint (/flow/entrypoint.sh), using Suite's is generally better as it will provide database connection details out of the Odoo RC file (/etc/odoo/odoo.conf).

The simplest possible scenario would be if you have a source databased named prod and you either want to restore into a database in your /etc/odoo/odoo.conf file (the db_name key) or will use the -d desired_db_name (used below)

The above command will result in the --pg_strategy fast_copy_template (the minimum amount of time and new postgres data) and --filestore_strategy symlink (the minimum amount of time and file system data).

Additional --pg_strategy options:

• "skip" will do nothing with postgres.
  

• "fast_copy_template" requires the same postgres host for both sides and will require no current users accessing the source database.
  

• "fast_copy_template" will kill all connections to the database to make the attempt. Generally this is bad for long running workloads that cannot easily be restarted (e.g. something that is communicating with a financial institution and has already committed in the remote but not in Odoo).
  

• "fast_copy" also requries the same postgres host on both sides. This will perform an efficient copy.
  

• "fast_copy" will fail back to custom_dump_copy, as it is the fastest when the dbhost known to be compatible.
  

• "stream_copy" will essentially \'pipe\' the output from a regular dump to a psql on the receiving host.
  

• "custom_dump_copy" will use postgres's major version limited custom dump.  It will also use more than one CPU core to achieve the result. (control with `--core_count 2`)

Additional --filestore_strategy  options:

• "symlink" will recursively make a symlink to every file. This is good for staging or test copies of a database to save space and time. It is not particularly durable in that the filestore objects (e.g. sale order PDF) could be deleted 
  (e.g. as a retention policy clean up), but it is more efficient than a true copy and takes up much less space. 
  

• "copy" uses the most efficient way to copy the files on disk.
  

• "copy" is durable, but will double the amount of storage required. 
  

• "move" will essentially 'rename' the database portion of the filesystem.
  

• "move" is very dangerous and is only appropriate in an extreme time like when doing an upgrade on a VERY large database's filestore.