¶ How to duplicate a production DB and use it to test
Some time you need to test something on a DB with production data. Generally, our setup already creates two DBs, one for production and one for test. With this guide you’ll be able to duplicate the production DB and use it for test purposes.
Keep in mind that with our setup you have two different sub-domains, one for each DB (e.g. odoo
and odoo-test
).
- Ensure you have administrative access to both the production and test domain Database Managers.
-
Access the Test Database Manager:
- Open a web browser and navigate to the test domain’s Database Manager (e.g.,
https://odoo-test.mydomain.coop/web/database/manager
).
- This is where you’ll manage the test database.
-
Delete the Existing Test Database:
- In the test Database Manager, locate the existing test database.
- Carefully delete this database. This action is irreversible, so ensure that you have a backup if needed.
- You may encounter a confirmation prompt or an “Internal Server Error” message post-deletion, which is normal as the database the test domain was connected to no longer exists.
-
Navigate to the Production Database Manager:
- Switch to the production domain by visiting its Database Manager (e.g.,
https://odoo.mydomain.coop/web/database/manager
).
- This step is crucial as it’s where you’ll initiate the duplication process.
-
Duplicate the Production Database:
- Within the production Database Manager, find the option to duplicate the database.
- When duplicating, specify the name of the test subdomain (e.g.,
odoo-test
) for the new database. This ensures the duplicated database is correctly named for test purposes.
- Follow the UI prompts to complete the duplication process.
After duplicating the database, you must deactivate (archive) both inbound and outbound email servers.
See Deactivate Mail Servers And Cron Jobs
-
If there is some particular cron job for this instance, deactivate it.
-
You should also delete ribbon.name
(set to False) from System Parameters.
In order to execute the following steps, you’ll need:
- production DB master password
It should be stored in Bitwarden. If it’s not there… please ask a sysadmin to add it.
In case of timeout, you can avoid changing NGINX directives using curl
as described here
- Go to the production subdomain and visit the Database Manager (e.g.
https://odoo.mydomain.coop/web/database/manager
)
- Download a backup of the production DB
- [In case of a timeout error] Go to the server and in the config file
/etc/odoo/odoo.conf
increase the following parameters’ values limit_time_cpu, limit_time_real
. Restart the server for the change to apply. Don’t forget to restore the value once you finish!
- Go to the test subdomain and visit the Database Manager (e.g.
https://odoo-test.mydomain.coop/web/database/manager
)
- Make sure you’re in the test subdomain and NOT in the production subdomain…
- Make a copy if necessary and delete the existing DB
- You’ll get an “Internal Server Error”, don’t worry… it’s normal. That Odoo process doesn’t have a DB to run with anymore.
- Visit the test Database Manager (e.g.
https://odoo-test.mydomain.coop/web/database/manager
)
- At the end of the form, choose to restore a database
- Fill in the test DB master password, browse and select the zip file generated by point 2, use the test DB name (e.g.
odoo-test
) and select “This database is a copy” option. Make sure that the DB name you choose is the same as the DB deleted in point 5.
- [In case of a large DB file error] Increase the value of
client_max_body_size
in the provision playbook according to your DB’s size and provision the server. Don’t forget to restore the value once you finish!
- Provision the server, this will place everything in order in the test environment
After duplicating the database, you must deactivate (archive) both inbound and outbound email servers.
See Deactivate Mail Servers And Cron Jobs
-
If there is some particular cron job for this instance, deactivate it.
-
You should also delete ribbon.name
(set to False) from System Parameters.
¶ When adding a test DB implies renaming prod domain
- Download a backup of the prod DB before doing anything.
https://odoo.mydomain.coop/web/database/manager
- Run provisioning with the new prod and test subdomains.
- The DB’s of the new domains will be empty
- Go to the new prod subdomain and visit the Database Manager (e.g.
https://odoo-new-prod.mydomain.coop/web/database/manager
)
- Delete the existing DB
- You’ll get an “Internal Server Error”, don’t worry… it’s normal. That Odoo process doesn’t have a DB to run with anymore.
- Visit the new prod subdomain Database Manager (e.g.
https://odoo-new-prod.mydomain.coop/web/database/manager
)
- At the end of the form, choose to restore a database
- Fill in the DB master password, browse and select the zip file with the old prod DB of the first point, use the new prod DB name (e.g.
odoo-new-prod
) and select “This database is a copy” option. Make sure that the DB name you choose is the same as the DB deleted in point 5.
- Repeat the previous steps for the new test subdomain and new test DB name using again old prod DB backup of first step.
- Disable cron jobs and ingoing and outgoing mail servers for test DB. (
UPDATE ir_cron SET active='f'
DELETE FROM ir_mail_server
DELETE FROM fetchmail_server
in psql [[*new test DB name**]]
- Run provisioning again to install unaccent psql extension and enable ribbon in test (ensure that
web_environment_ribbon
Odoo module is in inventory.
- Edit /etc/odoo/odoo.conf and comment the line with
dbfilter
- Restart Odoo
- Go to
https://odoo.mydomain.coop/web/database/manager
and you will see the new empty DB’s and also the old prod DB
. Here you can get the backup to follow the previous steps.
- Uncomment the line with
dbfilter
- Restart Odoo
- Continue with previous step 4.