每个 Odoo 数据库最终都会成为企业唯一可信的数据来源：发票、库存水平、薪资数据、客户历史和已签署的文件都存放在其中。一旦丢失，或恢复的是不完整的副本，业务可能会停摆数日。然而，许多企业直到真正需要备份的那一天，才发现自己备份方案中的漏洞。
本文介绍 Odoo 19 Enterprise 数据库管理、备份和灾难恢复的要点，并说明自托管 Community 安装的不同之处。本文面向企业主、财务经理和 IT 负责人，帮助他们无需阅读每一页技术文档即可获得清晰的全貌。
关于资料来源：本指南依据 Odoo 19 版官方文档编写。托管平台及其选项在不断演进，因此在生产环境中依赖之前，请在测试数据库中并对照最新的官方文档确认每一步。
完整的 Odoo 备份包含哪些内容
Odoo 数据库不仅仅是一个 PostgreSQL 数据库。上传的文档、图片和其他二进制内容等附件以文件形式存储在 Odoo 所称的文件存储中，并由 Odoo 控制对它们的访问。仅包含数据库转储的备份可以恢复您的记录，但附件会缺失。
Odoo.sh 文档将其备份描述为包括数据库转储、文件存储（附件和二进制字段）、日志和会话。这为任何托管方式下完整备份应有的内容提供了有用的参考。
- 数据库转储：所有记录、配置、用户、会计分录和设置。
- 文件存储：附件和二进制字段，例如扫描的账单、产品图片和已签署的 PDF。
- 自定义代码：在 Odoo.sh 和本地部署中，您的自定义模块存放在代码仓库里，代码仓库本身也需要保护。
- 配置：在本地部署中，Odoo 配置文件和服务器设置同样应形成文档并妥善保管。
检查备份时，请务必确认数据库转储和文件存储都在其中。文件存储缺失是最常见的原因之一：恢复后的数据库起初看起来正常，随后却出现图片损坏和文档缺失。
按托管方式划分的备份
备份的责任取决于您的数据库运行在哪里。Odoo Online 和 Odoo.sh 由 Odoo 托管并包含自动备份，而本地服务器则由您自己的团队承担全部责任。Community 版本通常采用自托管，因此下文所述的本地部署责任同样适用于它。
Odoo Online：数据库管理器
对于 Odoo Online，官方文档说明，数据库按照 Odoo Cloud Hosting SLA 每天备份。平台备份无需您进行任何安排即可自动进行。
以数据库管理员身份登录即可进入数据库管理器，其中的“管理”选项提供了备份和测试工作所需的主要操作。
- “下载备份”会生成数据库的 ZIP 文件，您可以将其保存在自己的档案中。
- 如果“下载备份”不可用，说明数据库过大，超出了管理器的处理能力，应联系 Odoo 支持团队获取其他下载方式。
- “复制”会创建数据库的副本；“用于测试目的”选项默认启用，会禁用电子邮件、付款和发货单等外部操作。
- “删除”会立即为所有用户移除数据库且无法撤销，因此请先下载备份。
根据文档，Odoo Online 上的复制数据库在 15 天后过期，每个数据库最多可以有五个副本。请将副本视为短期测试环境，而不是备份策略。
Odoo.sh：自动备份与手动备份
在 Odoo.sh 上，生产数据库每天自动备份。文档说明会保留七份每日备份、四份每周备份和三份每月备份，每月副本存放在专用备份服务器上。恢复或下载这些每月备份需要联系 Odoo 支持团队。
预发布和开发分支不会自动备份。可以对生产和预发布环境进行手动备份，以捕获特定快照，例如在进行有风险的配置更改之前。手动备份保留三天，文档提到每天最多可进行五次手动备份。开发数据库无法手动备份。
当合并的提交更改了模块版本或关联的 Python 依赖项时，Odoo.sh 还会创建一份标记为“更新备份”的自动备份。如果合并未更改这些内容，就不会触发备份，因此在进行重大的生产变更之前，请先进行手动备份。
- 使用生产分支的“备份”选项卡查看、下载或恢复备份。
- 当您希望使用真实数据进行测试时，将生产备份恢复到预发布分支。
- 使用“导入数据库”功能导入来自标准数据库管理器、Odoo Online 数据库管理器、“备份”选项卡或构建的“下载数据库转储”选项的归档文件。
本地部署：一切由您的团队负责
在您自己的服务器上，除非您进行设置，否则不会有任何备份。官方部署指南说得很直接：为数据库和文件存储数据设置每日备份，并将其复制到一台无法从该服务器本身访问的远程归档服务器上。
同一指南还提醒，基于 Web 的数据库管理器是一种开发和演示工具，并非为生产用途而设计。强烈建议在任何面向互联网的系统上禁用它，而自动备份等生产操作应由系统管理员负责处理。
- 使用在配置文件中设置的、随机生成的强主密码来保护数据库管理界面，切勿使用默认值。
- 在面向互联网的服务器上禁用数据库列表，并使用数据库过滤器，使每个主机名对应正确的数据库。
- 按照部署文档的要求，使用不具备超级用户权限的 Odoo PostgreSQL 用户运行。
- 将数据库和文件存储一起备份，使两者彼此保持一致。
在从 Community 切换到 Enterprise 等重大变更之前，官方文档将备份 Community 数据库列为第一步。在任何升级、模块安装或数据导入之前，也请养成同样的习惯。
安全地复制数据库：中和处理
在生产副本上测试是尝试新工作流程、导入或升级最安全的方式，但草率制作的副本可能会向客户发送真实邮件或触发真实付款。Odoo 通过中和数据库来处理这一问题，文档将其定义为停用了若干参数的非生产数据库。
测试数据库始终会经过中和处理，包括备份副本、复制的数据库以及 Odoo.sh 的预发布和开发数据库。文档明确说明其列出的停用项目并不详尽，其中包括以下内容。
- 计划的动作，例如自动订阅开票和群发邮件。
- 外发邮件，在 Odoo.sh 预发布环境中会被邮件捕获器拦截，而不会真正发送。
- 银行同步、支付服务商和交付方式。
- IAP 令牌，以及网站对搜索引擎的可见性。
屏幕顶部的红色横幅标示出中和数据库，让用户一眼就能看出自己不在生产环境中。请培训您的团队在录入任何内容之前先确认是否有这条横幅，除非完全了解后果，否则切勿解除副本的中和状态。
保留期、异地副本、RPO 与 RTO
平台备份是一张牢固的安全网，但完善的策略还应保留由您自己掌控的独立副本。对于托管数据库，请定期下载完整备份，并存放在单独的、受访问控制的位置。对于本地服务器，异地副本是必不可少的，而不是可有可无的。
有两个简单的指标可以帮助您确定所需的保护程度。恢复点目标（RPO）是指您能够承受丢失多少最近的数据；每日备份意味着您可能丢失最多一天的工作。恢复时间目标（RTO）是指在系统恢复期间，企业能够在没有该系统的情况下运营多长时间。
请与管理层商定这些目标，然后检查您当前的设置能否达到。如果丢失一整天的销售订单是不可接受的，那么仅靠每日备份是不够的，您应与托管服务商或 IT 团队讨论更频繁的快照或其他措施。
恢复测试与实用检查清单
备份只有在成功恢复之后才算得到验证。请定期安排恢复测试，将备份恢复到经过中和处理的测试环境中，并确认用户可以登录、最近的记录都在、附件可以正常打开。为整个过程计时，以了解您真实的 RTO。
- 确认您使用的托管方式，以及由谁负责备份。
- 核实备份同时包含数据库转储和文件存储。
- 在单独且安全的位置保留一份独立下载的副本。
- 在升级、大批量导入或重大配置更改之前进行手动备份。
- 所有测试均使用经过中和处理的副本或预发布分支。
- 定期将备份恢复到测试环境，并记录结果。
- 记录您的 RPO 和 RTO 目标，并每年进行审查。
- 在本地部署中，禁用公开的数据库管理器并保护好主密码。
1CBMS 如何为您提供帮助
1CBMS 为埃及和伊拉克的 Odoo 19 项目设计和审查备份与恢复流程，覆盖 Odoo Online、Odoo.sh 和本地服务器。我们可以审计您当前的设置，与您的管理层共同制定切实可行的 RPO 和 RTO 目标，搭建经过中和处理的测试环境，并与您的团队一起进行有记录的恢复测试，让恢复成为一项演练有素的程序，而不是一场紧急事件。