备份该不该把上传文件和数据库放在一起算

备份该不该把上传文件和数据库放在一起算？该放在一次范围里算。内容系统的状态天然是两半：数据库存的是结构化事实，文章正文、分类、标签、用户与站点配置；上传目录存的是静态文件，图片、附件、生成的静态产物。只做其中一半的备份，恢复时必然缺东西，所以「放在一起算」不是省事的写法，而是能真正恢复的前提。

两类数据的丢失代价不对称

数据库丢失是批量丢失：一次误操作或注入事故，可能把几年的文章结构一起带走，而且很难从别处还原。静态文件丢失是逐页劣化：文章还在，但图片裂开、附件失效，前台看起来像被搬过家。两者的修复成本完全不同，前者靠备份还原，后者在没有备份时只能重传内容，人工量按站点规模线性增长。

站内还有第三种常被漏掉的状态：内容生命周期里的中间态。文档分为正式文档、草稿、待发布与回收站，删除正式文档是移入回收站而不是物理删除，草稿带 preview 参数可预览。回收站与草稿的存在意味着「误删可恢复」只在站内成立；一旦需要整站重建或迁移，这些未发布的内容同样应该进入备份范围，否则恢复出来的是一半的历史。

备份范围包含什么

AnQiCMS 的备份与恢复支持数据（含静态文件）备份和恢复，把结构化数据与上传文件收在同一次操作里，避免「备了库、丢了图」的常见错配。判断自己的备份是否完整，可以用一份清单去对照：文章与其字段、分类与标签、用户上传的媒体、站点配置、模板与静态产物。清单里任何一项无法从其他位置重建，就应该在备份范围内。

要提醒的是，备份与内容层的保护不是同一件事。全站替换、导航调整这类批量操作改的是数据库里的内容，出问题同样需要回退点，所以执行这类批量动作之前先做一次备份，是成本很低的保险。

恢复演练怎么判断备份可用

只验证「备份文件生成了」没有意义，要验证「能在新环境里跑起来」。可行的演练分三步：把备份复制到一台干净机器上恢复，检查文章数量与前台路由是否与源站一致；随机抽几篇带图片与附件的旧文，确认静态文件能正常访问；检查登录与后台权限是否恢复到可操作状态。演练要留时间记录，恢复耗时决定了事故当天的实际损失。

多站点场景的演练还要多验一项：站点之间的内容、配置与权限是否互相隔离，恢复单个站点时会不会覆盖其他站点的数据。多站点管理本身就是为多个独立站点准备的形态，备份粒度要能对上这个结构。

把备份当成受控操作

备份会带走整站数据，因此它的风险等同一份可移动的敏感资产。合理的做法是把备份列为受控操作：谁能触发、在哪些环境能触发、产物放在哪里。AnQiCMS 的 MCP 接口按意图域设置暴露范围，备份、升级、多站点这类全站级高危操作默认关闭，需要显式开启，正是把「不是谁都能拉起整站数据」做成了机制。存放侧则要限制访问面，不要把备份产物放在可被公网直接抓取的位置。

常见问题

只备数据库、图片靠对象存储单独同步，可行吗？ 可行，但要满足两个条件：对象存储的同步有版本与回收能力，且恢复流程能把两边的数据对齐到同时间点。否则很容易出现文章指向已不存在的图片。

备份频率怎么定？ 按内容变更频率定，而不是按时间定。每天多次批量发布或采集的站点，应该缩短间隔；以静态页面为主的站点，低频加上「重大操作前手动备份」更实际。

怎么确认备份真的能救回来？ 定期做恢复演练：在隔离环境恢复一次，核对文章数量、图片附件可用性与后台登录，并记录恢复耗时。没有演练过的备份，不应视为可用。