Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a neutralized database backup #2866

Open
AfroMonkey opened this issue Feb 28, 2024 · 6 comments
Open

Create a neutralized database backup #2866

AfroMonkey opened this issue Feb 28, 2024 · 6 comments

Comments

@AfroMonkey
Copy link

Currently, it is possible to create a DB backup and restore it by checking the 'neutralize' option.

image

However, this can't be done during the backup creation.

image

In some cases, it will be beneficial for the backup itself to be 'neutralized' to prevent misconfiguration during the restoration process in test environments.

@AfroMonkey
Copy link
Author

I can work on a solution to extend the default /web/database/backup controller

@AfroMonkey
Copy link
Author

I'm not sure if is best to first create the backup and then neutralize offline or to create a neutralized copy of the current DB and backup that.

@amh-mw
Copy link

amh-mw commented Feb 29, 2024

I haven't needed this feature yet in Odoo, so I've quickly read up on https://www.odoo.com/documentation/17.0/administration/odoo_sh/getting_started/branches.html#staging

I'm not sure if is best to first create the backup and then neutralize offline or to create a neutralized copy of the current DB and backup that.

Neutralizing on import is what I have done in the past for the non-Odoo CRM that I support. It doesn't interfere with existing production database backups, which are automated and rock solid.

In some cases, it will be beneficial for the backup itself to be 'neutralized' to prevent misconfiguration during the restoration process in test environments.

Could you describe these cases?

@AfroMonkey
Copy link
Author

Sure, I'm thinking in the scenarios when you need to send your DB to another person, generally someone in training, and want to be sure that he wont uses a "production" environment, similar as what odoo.sh does.

image

Is more a "safety net"

@amh-mw
Copy link

amh-mw commented Feb 29, 2024

Sure, I'm thinking in the scenarios when you need to send your DB to another person, generally someone in training, and want to be sure that he wont uses a "production" environment, similar as what odoo.sh does.

We have a configuration-managed process that does pretty much what Odoo.sh does; our employees can generate a staging server with neutralized data, without ever having had access to production data. That said, I'm trying to move away from neutralized data, intending to fully utilize odoo populate 1 for developer and tester environments.

Footnotes

  1. https://www.odoo.com/documentation/17.0/developer/reference/cli.html#reference-cmdline-populate

@AfroMonkey
Copy link
Author

AfroMonkey commented Feb 29, 2024

Yea, I have the same opinion, but, in some cases is useful to have the "almost same" production environment for test.

For example, in latin american accountability, the invoices are sent to external systems. Is necessary to "neutralize" this to prevent sending that information. But, a "demo" DB will not work, in this same example, the "bug" trying ti resolve may be difficult to reproduce, maybe is something with the tax config, or the prices, or the EDI generation, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants