彭大帅的企业信息化实战用 Odoo 18 管好一家公司——第 8 篇 数据基线与运维：系统上线后的日常

目  录

一、为什么需要「数据基线」这份文档

1.1 当前基线快照（2026-10 权威版）

1.2 勘误表：5 处过期信息的处理

二、备份体系：从三个路径到一条 cron

2.1 备份四件套与脚本要点

2.2 恢复三场景

2.3 备份健康检查（每周）

三、一键巡检脚本：把第 5 篇的验收标准变成日常

3.1 巡检节拍建议

四、知识库文档体系：按场景找文档

4.1 基线快照的复现原则

五、系列收官：九篇走过的一条路

一、为什么需要「数据基线」这份文档

系统上线后最大的坑不是故障，而是「文档说的和系统实际不一样」：旧文档写着 65 MB / 77 个模块，实际已是 68 MB / 78 个；旧文档说「数据为空」，实际已有 20 张销售单、43 张凭证。拿着过期数字做判断（比如估算磁盘、评估迁移工作量），错得莫名其妙。

解法是「双文档管理法」：方法论文档（怎么部署、怎么配置、怎么操作）和现状快照文档（现在是什么样）分开维护。方法论长期有效、很少改；现状快照定期更新、以它为唯一权威。旧文档不删不改——里面的配置方法、源码链路分析依然准确——只在快照里挂勘误表修正数据认知。

1.1 当前基线快照（2026-10 权威版）

1.2 勘误表：5 处过期信息的处理

勘误表是快照文档的灵魂。5 处过期信息里最典型的一条：配置文档曾写「库存预警定时任务不存在」，基于当时的源码分析是对的，但后来补建了自定义 cron（id=27「库存：批次保质期到期预警」，每日执行）——原结论按现状失效，勘误表必须记一笔，否则后人排查预警问题时会被误导。

处理原则：旧文档不删不改，方法依然有效；数字以快照为准。这样既不丢内容，又不误导读者。

二、备份体系：从三个路径到一条 cron

改造前的状态很典型：三份文档写了三个不同的备份路径，且从未落地成定时任务——数据库里已有真实业务数据，一旦出事只能靠手工 dump。改造后收敛为一张表：

2.1 备份四件套与脚本要点

四件套：db_odoo.dump（pg_dump -Fc 全量）、filestore_odoo.tar.gz（附件图片）、odoo.conf、脚本自身。脚本五个环节各有校验，节选关键判断：

# 1. 数据库：pg_dump -Fc，文件 <100KB 视为异常（防止空 dump 冒充成功）

if [ "$SZ" -lt 102400 ]; then log "ERROR: 备份文件异常小"; exit 1; fi

# 4. 完整性校验（备份不校验 = 没备份）

pg_restore –list "

DB.dump" > /dev/null 2>>"$LOG" \\

  && log "数据库备份校验通过" || { log "ERROR: 校验失败"; exit 1; }

gzip -t "

DB.tar.gz" && log "filestore 校验通过"

# 5. 清理 7 天前备份（find -mtime +7）

⚠️ 三个部署注意点：/etc/cron.d/ 下的文件必须 644 且属主 root，否则 cron 静默忽略（不报错，最难排查）；filestore 必须备（22 MB 原始压缩后 4.8 MB），只备库丢了附件图片；数据库文件小于 100 KB 视为失败，防止空 dump 冒充成功。

2.2 恢复三场景

• 场景 A 查历史数据：pg_restore 恢复到临时库 odoo_restore_test，查完 dropdb，全程不动生产库。
• 场景 B 整库回滚（需停机）：stop odoo → 先把当前的坏数据 dump 保住（别直接覆盖）→ dropdb → createdb → pg_restore → 恢复 filestore 并 chown odoo → start odoo。
• 场景 C 只恢复误删附件：解包 filestore 到 /tmp，cp -n 单个文件回 filestore 对应子目录，chown 后重启。

2.3 备份健康检查（每周）

ls -lht /opt/odoo/backup/auto/ | head -5     # 最近 3 次备份

tail -20 /var/log/odoo-backup.log            # 最近执行日志

find /opt/odoo/backup/auto -maxdepth 1 -type d -name "2*" | wc -l   # 应 = 7

LATEST=$(ls -d /opt/odoo/backup/auto/2*/ | tail -1)

pg_restore –list "$LATEST/db_odoo.dump" > /dev/null && echo "最新备份可读"

⚠️ 备份不等于能恢复。建议每季度做一次场景 A 演练，确认备份真的能用——这是唯一被验证过的备份。

三、一键巡检脚本：把第 5 篇的验收标准变成日常

第 5 篇初始化时的四类验收（数据量、单据状态、试算平衡、临期扫描），就是上线后的巡检标准。把检查固化成 /usr/local/bin/odoo-check.sh，随时跑、五段输出：

# 一、服务状态：odoo / postgresql / nginx 是否 active

# 二、资源：内存、根分区使用率

# 三、备份新鲜度：最新备份 <30 小时为新鲜，否则检查 cron

# 四、业务数据：五类单据计数 + 试算平衡 + 临期批次扫描

# 五、定时任务：备份 cron 规则数 + Odoo 活跃 cron 数

其中「业务数据」段直接复用第 5 篇的核查脚本（五类计数、借贷平衡、60 天内临期批次扫描，临期行格式：批次号 / 产品 / 库存量 / 剩余天数）。巡检原则：脚本退出即给结论，不靠人记判断标准；任何一段出现 ❌ 都要有对应的处置动作（服务挂了重启、备份过期查 cron、不平衡查未过账单据）。

3.1 巡检节拍建议

四、知识库文档体系：按场景找文档

本系列对应的知识库共 9 份文档，按「我要做什么」组织索引：

按角色推荐：系统管理员读 基线 → 部署 → 权限 → 本篇；会计读 基线 1.4 节 → SOP 会计章 → 财务配置；销售 / 仓管 / 客服只看 SOP 对应章节；实施顾问按 部署 → 配置 → 数据 → 财务 → 权限 全序读。

4.1 基线快照的复现原则

快照里每个数字都必须可用一段脚本复现（odoo shell 一段查全：十类数据计数、库大小 pg_database_size、模块数、试算平衡、库存总值）。这一条是双文档管理法能运转的前提：数字可复现，快照更新才是机械劳动而不是重新排查；怀疑快照过期时，跑一遍脚本就知道。

五、系列收官：九篇走过的一条路

从第 0 篇的选型判断，到本篇的日常运维，这条线走完了：

回看全程，三条经验贯穿始终：其一，系统不难装，难的是「配置文档的准确性」——本系列踩的最大的坑都是文档坑（假 URL、不存在的菜单、过期的数字），所以坚持每篇只写实测通过的内容；其二，业务规则先于技术配置（先到期先出 → FIFO → 批次纪律 → 临期处理流程），技术只是规则的执行者；其三，上线不是终点——基线快照、自动备份、季度演练才是系统能长期活下去的保障。

后续可选的延伸方向：备份恢复的完整演练实录（把场景 A/B 真跑一遍）、多公司 / 多仓库扩展、以及与 AI 运维工具联动的值守告警——有需要再成篇。