Odoo 开源系统数据库备份和上传文件备份实战教程（项目/客户/待办模块完整方案）

一、Odoo 备份的 2 个核心对象 —— 数据库与文件

先讲一个真实场景：某制造企业上了 Odoo 16 做 ERP，跑了 1 年多，存了几十万条订单数据、产品 BOM、客户合同、上传的合同附件等文件。突然服务器硬盘故障，运维工程师在恢复时发现：只备份了数据库，没备份文件——所有上传的合同 PDF、产品图纸、客户签字扫描件全部丢失。客户索赔 80 万，CEO 被董事会问责。

Odoo 数据丢失的悲剧 90% 不是技术问题，是”只想到一半”。Odoo 实际上由两部分数据组成：

数据类型	存储位置	典型内容	丢失影响
PostgreSQL 数据库	PostgreSQL 数据目录（默认 /var/lib/postgresql/）	订单、客户、产品、BOM、发票、合同字段、自定义模块数据	★★★★★ 致命
Odoo 文件存储（filestore）	~/.local/share/Odoo/filestore/<database>/ 或 /opt/odoo/.local/share/Odoo/filestore/	上传的合同 PDF、产品图纸、客户签字扫描件、附件、图片	★★★★ 高
addons 自定义模块	/opt/odoo/custom_addons/	企业定制开发的 Python 模块	★★★ 中
配置文件	/etc/odoo/odoo.conf	数据库连接、addons 路径、SMTP、备份路径等	★★ 低（容易重建）

本文重点讲前两类（数据库 + filestore）的备份方案。两类数据必须分别备份，且恢复时必须匹配同一时间点的快照——否则数据库里有订单记录指向文件 ID，但文件本身丢了，会变成”幽灵订单”。

二、Odoo 内置的备份工具 —— /web/database/manager

Odoo 自带一个 Web 端备份管理界面（数据库管理器），适合中小企业低频手动备份。

2.1 启用数据库管理器

数据库管理器默认在生产环境是关闭的，需要在 Odoo 配置文件开启：

/etc/odoo/odoo.conf

[options]
list_db = True
admin_passwd = YOUR_STRONG_MASTER_PASSWORD

list_db = True 是关键参数，开启后访问 https://your-odoo-domain.com/web/database/manager 会出现备份管理界面。

⚠️ 安全警告：数据库管理器权限极大（能删除整个数据库），必须：

• 用强密码作 admin_passwd（建议 16 位以上含大小写数字符号）
• 限制 IP 访问（Nginx 配置 allow 规则，只允许运维 VPN IP 段访问）
• 或完全禁用改用命令行备份（生产环境推荐）

2.2 使用 Web 界面备份

1. 访问 https://your-odoo-domain.com/web/database/manager
2. 输入 master 密码（admin_passwd 配置值）
3. 点击”备份”按钮 → 选择要备份的数据库
4. 设置备份格式（推荐 ZIP，包含数据库 + filestore）
5. 下载备份文件到本地

ZIP 备份的关键优势：Odoo 会把数据库 dump 和 filestore 打包成同一个 ZIP，恢复时一个文件就能完整恢复——不会出现”数据库和文件不匹配”的问题。

2.3 Web 界面备份的局限性

• 无法自动化（每次需要人工触发）
• 大型数据库（10GB+）通过 Web 上传/下载容易超时
• 没有版本管理（备份文件容易覆盖）
• 没有异地容灾（备份还在同一台服务器）

所以生产环境必须用命令行自动化备份。

三、命令行备份 —— PostgreSQL + Filestore 完整方案

3.1 数据库备份（pg_dump）

PostgreSQL 自带 pg_dump 工具，是备份数据库的标准方式：

# 备份单个数据库为 SQL 文件
sudo -u postgres pg_dump -Fc -d odoo_production -f /backup/db/odoo_$(date +%Y%m%d_%H%M%S).dump

参数说明：

• -Fc：自定义压缩格式（比纯 SQL 文件小 80%，恢复更快）
• -d odoo_production：指定数据库名
• -f：输出文件路径

恢复命令：

sudo -u postgres pg_restore -d odoo_production_restored /backup/db/odoo_20260727.dump

3.2 Odoo 一键备份（推荐）

Odoo 提供官方命令行备份接口，可以同时备份数据库 + filestore + 配置：

odoo-bin -d odoo_production
    --backup=/backup/odoo/
    --backup-format=zip
    --stop-after-init
    -c /etc/odoo/odoo.conf

参数说明：

• --backup=/backup/odoo/：备份输出目录
• --backup-format=zip：ZIP 格式（自动打包数据库 + filestore）
• --stop-after-init：备份完自动停止进程（适合 cron 场景）

输出文件名格式：odoo_production_2026-07-27_03-00-00.zip，包含完整 dump。

3.3 Filestore 单独备份

如果只想单独备份 filestore（适合文件单独加密归档场景）：

# Linux 标准方式：用 tar 打包
tar -czf /backup/filestore/filestore_$(date +%Y%m%d_%H%M%S).tar.gz
    -C /opt/odoo/.local/share/Odoo/filestore/ odoo_production

恢复时反向解包：

tar -xzf /backup/filestore/filestore_20260727.tar.gz
    -C /opt/odoo/.local/share/Odoo/filestore/

3.4 自定义模块备份

如果企业在 /opt/odoo/custom_addons/ 部署了定制模块，单独打包：

tar -czf /backup/addons/custom_addons_$(date +%Y%m%d).tar.gz /opt/odoo/custom_addons/

四、自动化备份方案 —— Crontab + 保留策略

写一个综合备份脚本，每天凌晨 3 点自动备份 + 保留 7 天 + 同步到异地。

4.1 综合备份脚本

#!/bin/bash
# /opt/odoo/scripts/odoo_backup.sh
# Odoo 综合备份脚本（数据库 + filestore + 自定义模块）

set -e
# ===== 配置区 =====
ODOO_DB="odoo_production"
ODOO_USER="odoo"
ODOO_HOME="/opt/odoo"
FILESTORE_DIR="/opt/odoo/.local/share/Odoo/filestore/${ODOO_DB}"
CUSTOM_ADDONS_DIR="/opt/odoo/custom_addons"
BACKUP_ROOT="/backup/odoo"
REMOTE_BACKUP_DIR="/mnt/nas/odoo_backup" # NAS 或异地挂载点
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)

# ===== 创建备份目录 =====
mkdir -p ${BACKUP_ROOT}/db ${BACKUP_ROOT}/filestore ${BACKUP_ROOT}/addons
mkdir -p ${REMOTE_BACKUP_DIR}

# ===== 1. 数据库备份 =====
echo "[$(date)] 开始备份数据库..."
sudo -u postgres pg_dump -Fc -d ${ODOO_DB}
    -f ${BACKUP_ROOT}/db/${ODOO_DB}_${DATE}.dump
DB_FILE="${BACKUP_ROOT}/db/${ODOO_DB}_${DATE}.dump"
DB_SIZE=$(du -sh ${DB_FILE} | awk '{print $1}')
echo "[$(date)] 数据库备份完成：${DB_FILE} (${DB_SIZE})"

# ===== 2. Filestore 备份 =====
echo "[$(date)] 开始备份 filestore..."
if [ -d "${FILESTORE_DIR}" ]; then
    tar -czf ${BACKUP_ROOT}/filestore/filestore_${DATE}.tar.gz
        -C $(dirname ${FILESTORE_DIR}) $(basename ${FILESTORE_DIR})
    FS_FILE="${BACKUP_ROOT}/filestore/filestore_${DATE}.tar.gz"
    FS_SIZE=$(du -sh ${FS_FILE} | awk '{print $1}')
    echo "[$(date)] Filestore 备份完成：${FS_FILE} (${FS_SIZE})"
else
    echo "[$(date)] 警告：filestore 目录不存在 ${FILESTORE_DIR}"
fi

# ===== 3. 自定义模块备份 =====
echo "[$(date)] 开始备份自定义模块..."
if [ -d "${CUSTOM_ADDONS_DIR}" ]; then
    tar -czf ${BACKUP_ROOT}/addons/custom_addons_${DATE}.tar.gz
        -C $(dirname ${CUSTOM_ADDONS_DIR}) $(basename ${CUSTOM_ADDONS_DIR})
    ADDONS_FILE="${BACKUP_ROOT}/addons/custom_addons_${DATE}.tar.gz"
    ADDONS_SIZE=$(du -sh ${ADDONS_FILE} | awk '{print $1}')
    echo "[$(date)] 自定义模块备份完成：${ADDONS_FILE} (${ADDONS_SIZE})"
fi

# ===== 4. 验证备份完整性 =====
echo "[$(date)] 验证备份完整性..."
# 验证数据库备份文件能正常读取
if ! pg_restore -l ${DB_FILE} >/dev/null 2>&1; then
    echo "[$(date)] ❌ 错误：数据库备份文件损坏！"
    exit 1
fi
# 验证 tar 文件能正常解压
for tar_file in ${FS_FILE:-} ${ADDONS_FILE:-}; do
    if [ -n "${tar_file}" ] && ! tar -tzf ${tar_file} &>/dev/null; then
        echo "[$(date)] ❌ 错误：备份文件 ${tar_file} 损坏！"
        exit 1
    fi
done
echo "[$(date)] ✅ 所有备份文件验证通过"

# ===== 5. 同步到异地（NAS/S3） =====
echo "[$(date)] 同步备份到异地..."
rsync -az ${BACKUP_ROOT}/ ${REMOTE_BACKUP_DIR}/
    --include='*/' --include='*.dump' --include='*.tar.gz' --exclude='*'
echo "[$(date)] 异地同步完成"

# ===== 6. 清理过期备份 =====
echo "[$(date)] 清理 ${RETENTION_DAYS} 天前的备份..."
find ${BACKUP_ROOT}/db -name "*.dump" -mtime +${RETENTION_DAYS} -delete
find ${BACKUP_ROOT}/filestore -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete
find ${BACKUP_ROOT}/addons -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete
echo "[$(date)] 清理完成"

# ===== 7. 备份结果通知 =====
TOTAL_SIZE=$(du -sh ${BACKUP_ROOT} | awk '{print $1}')
echo "[$(date)] ✅ 备份全部完成，本地总大小：${TOTAL_SIZE}"

4.2 加入 Crontab

# 编辑 crontab
crontab -e -u odoo

添加（每天凌晨 3 点执行）：

0 3 * * * /opt/odoo/scripts/odoo_backup.sh >> /var/log/odoo_backup.log 2>&1

4.3 备份保留策略（3-2-1 法则）

3-2-1 备份法则是行业标准：

• 3 份副本：本地一份 + 异地一份 + 云端一份
• 2 种介质：磁盘 + 磁带/S3 Glacier
• 1 份离线：至少一份备份完全离线（防勒索病毒）

具体到 Odoo：

副本	存储位置	保留时长	用途
本地每日备份	/backup/odoo/（服务器本地硬盘）	7 天	快速恢复（误删数据当天找回）
异地每周备份	NAS / 异地机房	30 天	服务器整体故障时切换
云端月度备份	S3 / 阿里云 OSS / 腾讯云 COS	1 年	合规归档、灾难场景最后兜底

五、已安装模块的特殊备份考虑

峰哥这台 Odoo 已经装了项目、客户管理、待办等模块。这些模块在备份时要额外注意：

5.1 项目模块（project）

项目模块可能存了项目附件、子任务评论、文档附件：

• 项目附件全部走 filestore，所以备份 filestore 必须包含
• 项目甘特图数据在数据库 project_task、project_project 表，数据库备份必须包含
• 项目时间追踪（timesheet）数据在 account_analytic_line 表，数据库备份必须包含

5.2 客户管理模块（CRM / sale / contacts）

客户数据涉及字段：

• 客户主数据 → res_partner 表
• 销售订单 → sale_order、sale_order_line 表
• 报价单、合同条款 → 数据库 + filestore 双备份
• 客户附件（合同 PDF、报价单扫描件）→ 必须备份 filestore

5.3 待办模块（todo / task）

待办模块数据较简单：

• 任务数据 → 数据库表（如 project_task 或 mail_activity）
• 待办附件 → filestore
• 讨论记录 → 数据库表 mail_message

这些数据跟项目模块数据强耦合——通常 project + todo 在同一模块家族。备份策略相同。

5.4 必装模块对应的备份扩展建议

如果企业用了以下模块，备份时需要考虑扩展：

模块	备份要点	典型场景
documents (odoo 17+)	大量文件在 documents/workspace	企业文档中心
website / website_slides	网站附件 + 富文本	企业官网
hr / hr_payroll	员工合同附件	HR 系统
account (会计)	凭证附件 + 报表	财务系统
stock / mrp	产品图纸 + BOM	生产制造

六、备份验证与恢复演练

“没演练过的备份等于没备份”——这是运维行业铁律。每年都有企业”备份齐全但恢复失败”的案例，原因 90% 是没做过恢复演练。

6.1 每月必做的 3 项演练

演练 1：恢复最近一次备份到测试环境

• 准备一台独立的 Odoo 服务器（生产环境之外）
• 把昨天/今天的备份恢复到测试服务器
• 登录测试环境，验证关键模块（项目/CRM/待办）能正常打开
• 抽查几条记录（如上周刚下的订单）确认数据一致

演练 2：恢复 30 天前的备份

• 验证异地备份（NAS/云端）能正常恢复
• 确认备份文件没被损坏（30 天前的数据恢复后能完整查询）

演练 3：模拟生产环境整体故障

• 关停生产 Odoo
• 从异地 NAS 拉取备份
• 在新服务器上完整恢复
• 验证业务能正常运转（RTO 测试）

6.2 RTO 和 RPO 指标

指标	含义	中小企 Odoo 推荐值
RTO（恢复时间目标）	从故障到恢复业务的时长	≤ 4 小时
RPO（恢复点目标）	最多丢失多少时间的数据	≤ 24 小时（每日 1 次备份）

如果企业要求 RPO ≤ 1 小时，需要升级到实时流复制或WAL 归档方案（PostgreSQL 高级特性）。

6.3 备份监控告警

备份失败但没人知道，是最糟的场景。必须配置告警：

• 备份脚本 exit code 不为 0 → 触发告警
• 备份文件大小突然变小（< 50% 历史均值）→ 告警（可能备份不完整）
• 备份文件时间戳超过 26 小时没更新 → 告警（可能 cron 没跑）
• 异地备份目录空间满 → 告警

告警方式推荐：

• Zabbix/Prometheus + Alertmanager（标准方案）
• 脚本里嵌入企业微信/钉钉 webhook（轻量方案）
• Zabbix 监控 /backup/odoo 目录的最新文件 mtime

七、实战避坑指南 · 7 个常见踩坑点

坑 1：备份时没停 Odoo，导致备份损坏

症状：恢复时报错 “invalid page header” 或部分数据丢失。

原因：备份过程中数据库仍在写入，pg_dump 抓到的文件不完整。

修法：

• 方案 A（推荐）：Odoo 命令 --db_stop 参数，自动停止数据库连接后备份（PostgreSQL 9.6+ 支持）
• 方案 B：备份前 systemctl stop odoo，备份完 systemctl start odoo
• 方案 C：用 PostgreSQL 流复制 + WAL 归档，实现热备份

坑 2：filestore 备份不完整，数据库里有”幽灵文件”

症状：恢复后部分附件打不开，显示”文件不存在”。

原因：数据库有附件记录，但 filestore 备份时漏了该目录。

修法：

• 用 --backup-format=zip 一次性打包数据库 + filestore（推荐）
• 单独备份 filestore 时确保路径正确（find /opt/odoo/.local/share/Odoo/filestore/ -type f | wc -l 验证文件数量）

坑 3：备份文件没加密，落入坏人手中

症状：备份文件被竞争对手获取，含客户名单、合同、定价等敏感数据。

修法：

• 备份文件用 gpg 加密：gpg --symmetric --cipher-algo AES256 backup.dump
• 或用 7-Zip + 密码加密
• 异地传输用 rsync over SSH（自带加密）

坑 4：备份脚本用 root 跑，权限混乱

症状：恢复时提示 “permission denied”，需要重新 chown。

原因：备份用 root，文件属主是 root，恢复时 Odoo 用户无法读取。

修法：

• 用 odoo 用户跑备份：crontab -e -u odoo
• 或用 sudo -u odoo 在脚本里切换用户
• 备份目录 chown odoo:odoo /backup/odoo/

坑 5：备份和 Odoo 在同一台服务器，服务器挂备份也没了

症状：服务器硬件故障，备份文件跟生产数据一起丢失。

修法（必须做）：

• 异地 NAS 同步（rsync）
• 云端 S3/OSS/COS 同步（推荐用 rclone 或 s3cmd）
• 至少保证备份目录在另一块物理硬盘（/backup/odoo 与 /var/lib/postgresql 不在同一块盘）

坑 6：异地备份是单向的，生产篡改后异地也改

症状：员工恶意删除订单后，异地备份也被覆盖（因为某些同步工具是双向）。

修法：

• 异地备份用追加写而不是同步覆盖：rsync -a --append /backup/odoo/ /mnt/nas/odoo_backup/
• 或用 rclone copy（单向 copy）而不是 rclone sync
• 云端备份开对象锁（Object Lock）功能（S3/OSS 都支持），防止删除

坑 7：备份恢复后 Odoo 启动失败

症状：systemctl start odoo 后立即退出，日志报 “database connection failed”。

原因：备份恢复后 PostgreSQL 没起、或 odoo.conf 里数据库连接信息不对。

修法：

• 恢复后先 systemctl status postgresql 确认数据库在跑
• sudo -u postgres psql -c "l" 看新数据库是否成功创建
• /etc/odoo/odoo.conf 里 db_name 是否指向新恢复的库

八、备份方案速查清单

不同企业规模的备份方案推荐：

企业规模	备份频率	保留时长	异地副本
10-50 人	每日 1 次	本地 7 天 + 异地 30 天	NAS / OSS
50-200 人	每日 1 次 + 每周 1 次全量	本地 30 天 + 异地 90 天	NAS + 异地 OSS
200-1000 人	每日 1 次 + 每周全量 + WAL 归档	本地 90 天 + 异地 1 年	异地机房 + OSS + 磁带
1000+ 人	实时流复制 + 多副本	永久保留	双活机房 + 异地灾备

九、发布前必读的官方 URL 清单

本文涉及 PostgreSQL、Odoo、Linux 命令行等多个工具的 API 和文档，参数/版本会随时间变化。发布前请实时打开以下 URL 核对最新状态：

• Odoo 官方文档 · 数据库管理：odoo.com/documentation/16.0/administration/install/deploy.html
• Odoo 官方文档 · 备份与恢复：odoo.com/documentation/16.0/administration/backup.html
• Odoo 官方文档 · Odoo 命令行参数：odoo.com/documentation/16.0/developer/cli.html
• PostgreSQL 官方文档 · pg_dump：postgresql.org/docs/current/app-pgdump.html
• PostgreSQL 官方文档 · pg_restore：postgresql.org/docs/current/app-pgrestore.html
• PostgreSQL 官方文档 · 连续归档与点时间恢复（PITR）：postgresql.org/docs/current/continuous-archiving.html
• Linux Crontab 官方文档：man7.org/linux/man-pages/man5/crontab.5.html
• rsync 官方文档：rsync.samba.org/documentation.html
• 阿里云 OSS 备份方案：help.aliyun.com/zh/oss
• 腾讯云 COS 备份方案：cloud.tencent.com/document/product/436

本教程涉及的版本：Odoo 16.0 + PostgreSQL 14+ + Ubuntu 22.04 / CentOS 7+。其他版本（Odoo 15.0/17.0）流程类似但配置路径和模块名可能不同，请以官方实时文档为准。

十、结语 · 备份是运维的底线工程

最后说一句心里话：备份不是锦上添花，是底线工程。很多企业上 Odoo 时重视功能、忽视备份，结果出故障时追悔莫及。真正负责的运维，会把备份当成 Odoo 上线的”前置条件”——没备份方案的项目，不允许上线。

具体来说，企业做 Odoo 备份前要先回答 3 个问题：

• 我们能容忍最多丢失多少时间的数据（RPO）？——决定备份频率
• 从故障到恢复业务最多能等多久（RTO）？——决定备份策略 + 异地副本
• 哪些数据最关键、丢了不可恢复？——决定备份优先级（数据库 vs filestore）

把这 3 个问题想清楚，再选具体的备份工具和策略落地，技术只是把管理制度固化的手段。本文的核心命令、自动化脚本、保留策略、避坑指南都是经验沉淀，希望能帮正在做 Odoo 备份的企业少走弯路。

如果对 Odoo 数据库备份、文件备份、灾难恢复有任何疑问，或者需要专业的 Odoo 运维方案咨询，IT 峰哥团队提供从 Odoo 部署 → 备份方案设计 → 自动化脚本开发 → 异地容灾实施的全流程服务，微信 17712677007 随时可联系。