织梦网站误删文档恢复方法

从回收站到 binlog 回放，按梯队逐级挽救被误删的织梦文档

误删场景与影响范围

织梦后台误删文档通常发生在批量操作时：勾选“删除”而非“移入回收站”、SQL 直接 DELETE FROM dede_archives、清理垃圾文档时连带删除了正常文章、或被恶意脚本批量清空。误删后不仅文档主表 dede_archives 数据丢失，附加表 dede_addonarticle、栏目静态页、搜索引擎收录 URL 也会受影响。需要按“先止损、再恢复、后清理”的顺序处理。

第一梯队：回收站恢复

织梦后台默认开启回收站，误删的文章会进入 dede_archives 中 arcrank=-2 状态。这是最快捷的恢复方式。

操作步骤

  1. 登录后台 → 核心 → 所有档案列表 → 顶部“回收站”。
  2. 勾选要恢复的文章，下拉选择“还原”。
  3. 确认后文章状态回到原栏目，arcrank 恢复正常。
  4. 进入对应栏目重新生成静态页。

若回收站为空，可能是直接物理删除，需进入下一梯队。

回收站功能在 系统 → 系统基本参数 → 核心设置 中开启，关闭后误删不可逆，强烈建议保持开启。

第二梯队：数据库备份还原

若有定期备份，可在测试库还原后导出缺失文档，再导入生产库。这种方式安全、不影响现网其他数据。

步骤

  1. 在测试机创建空库：CREATE DATABASE dede_restore DEFAULT CHARSET=utf8;
  2. 导入最近一次备份：zcat dedecms_20240728.sql.gz | mysql -u root -p dede_restore
  3. 查询缺失文档的 ID 范围：SELECT id,title FROM dede_restore.dede_archives WHERE id BETWEEN 1000 AND 1050;
  4. 导出主表与附加表对应行：
mysqldump -u root -p dede_restore dede_archives dede_addonarticle \
  --where="id BETWEEN 1000 AND 1050" \
  --no-create-info --skip-add-drop-table > restore_rows.sql
  1. 导入生产库前先备份当前库：mysqldump dedecms > before_restore.sql
  2. 导入：mysql -u root -p dedecms < restore_rows.sql
  3. 更新栏目文档数、重新生成静态。

第三梯队：binlog 逆向回放

若无完整备份但开启了 binlog，可用 mysqlbinlog 解析删除前后的位置点，把误删的 INSERT 操作重新执行。这是最后也是最强的恢复手段。

定位删除时间点

-- 查询 binlog 文件列表
SHOW BINARY LOGS;
-- 查看指定文件的删除事件
mysqlbinlog --base64-output=DECODE-ROWS -v \
  --start-datetime="2024-07-29 10:00:00" \
  --stop-datetime="2024-07-29 11:00:00" \
  mysql-bin.000123 | grep -A2 "DELETE FROM"

把删除前的 INSERT 重新执行

# 定位到删除前的 position，导出该区间
mysqlbinlog --start-position=123456 --stop-position=124000 \
  mysql-bin.000123 | mysql -u root -p dedecms
binlog 恢复对位置精度要求高，建议先在测试库演练，确认无误再上生产。Row 模式 binlog 能精确还原单行，比 Statement 模式更安全。

恢复后的清理动作

  • 执行“更新系统缓存” → “一键更新网站”，刷新栏目统计。
  • 检查 dede_arctiny 微表与主表 ID 是否一致，避免发布异常。
  • 提交 sitemap 给百度，加速被删 URL 重新收录。
  • 检查自定义字段附加表 dede_addon* 是否同步恢复。
  • 核对点击数、评论数等扩展表，缺失部分用 0 兜底。

预防措施

  • 后台关闭“直接物理删除”，全部走回收站，保留期不少于 7 天。
  • 开启 MySQL binlog，保留至少 7 天，为误删兜底。
  • 每日定时备份并异地存放，恢复演练每月一次。
  • 批量删除前先导出 ID 列表存档，便于回溯。
  • 给后台账号分配最小权限，禁止普通编辑删除。

行动指引

误删发生后第一件事不是慌乱操作，而是立即停止后台批量任务、冻结写入、记录删除时间点，再按“回收站 → 备份还原 → binlog 回放”的梯队逐步尝试。把恢复耗时与最终方案写进运维手册，下次同样事故即可从容应对；同时把本次暴露的短板（如回收站关闭、binlog 未开）逐项补齐，让织梦文档恢复能力进入可持续状态。