正文

帝国CMS备份恢复血泪史，三年踩坑总结，别再走我的弯路

站长手记
站长手记 V管理员 /824阅读/3评论
0719
文章最后更新时间2026年07月19日，若文章内容或图片失效，请留言反馈！

当初接手第一个帝国CMS站的时候,觉得备份不就是点几下鼠标的事儿吗？结果赔了整整两周的数据，还差点被甲方追着骂，这些年踩过的坑，今天全抖出来，能帮一个是一个。

第一个坑：后台“数据备份”按钮，看着省心实则要命

帝国CMS后台自带的数据备份功能,默认直接导出整个数据库，站刚建的时候数据小，还挺顺利，可当文章到了两万篇、附件几十个G的时候，点击执行——页面直接白屏，刷新一看，只生成了几个KB的.sql文件，表结构都没导全，更惨的是，后来我天真地拿这个“残废”备份去恢复，结果前台报错“Table doesn't exist”，后台登录进去一片空白。

帝国CMS备份恢复血泪史，三年踩坑总结，别再走我的弯路

帝国CMS备份恢复血泪史，三年踩坑总结，别再走我的弯路

真相： 帝国CMS自带的备份依赖PHP执行时间，数据量大就会超时中断，而且不报错，你以为备份成功了，实际只跑了前几十个表。

解决方案：

  • 小站（数据<100MB）：老老实实用帝国后台的“分卷备份”功能，每个卷设置10MB左右，分批导出，手动下载合并。
  • 大站（数据>100MB）：直接SSH进服务器跑mysqldump命令，稳定且快，我现在的脚本是这样写的：
    #!/bin/bash
mysqldump -u用户名 -p密码 --default-character-set=utf8 数据库名 > /backup/$(date +%Y%m%d%H%M)_empirecms.sql
cd /backup && tar -czf $(date +%Y%m%d%H%M)_empirecms.tar.gz *.sql

    然后配合crontab每天凌晨执行,压缩后不到原文件三分之一，省空间又可靠。

第二个坑：编码问题——你以为是乱码，其实是祖宗传下来的

帝国CMS有GBK版和UTF-8版，很多老站是GBK编码，有一次我从一个UTF-8版备份文件恢复到一个新装GBK版帝国上，结果所有中文标题变成了“？？？”，文章内容也是乱码，查了一下午，才发现是字符集不一致，但更坑的是帝国后台恢复时根本不会检测编码，直接往里塞。

真实经历： 有一次帮朋友恢复一个五年前的老站，他给的是帝国CMS 6.6 GBK版本的备份，我用最新版7.5 UTF-8去恢复，先改了数据库配置文件里的字符集，再导入，结果依然乱码，后来发现帝国CMS的表里还有phome_ecms_news_data_1这类表的newstext字段存的是二进制数据，恢复时如果没指定--default-character-set=gbk，数据直接损坏。

正确做法：

  1. 永远记住源站的编码,如果不知道，看e/config/config.php里的EC_DEFAULT_CHARTSET。
  2. 备份时明确指定编码：mysqldump --default-character-set=gbk。
  3. 恢复前在SQL文件开头加上SET NAMES gbk;或SET NAMES utf8;，然后再执行。
  4. 最保险的方法：用帝国后台自带的“数据备份→恢复”功能，但前提是你备份时用的是同一个版本的帝国CMS，版本不同就别偷懒，手动作SQL预处理。

第三个坑：文件权限——恢复时提示无法写入，其实是ntfs或目录捣鬼

有一次迁移服务器,我把整站打包传到新服务器，解压后访问前台，显示“无法打开文件”，查了半天，发现e/data目录的权限是644，而帝国CMS需要写入fdid、html等文件夹，更离谱的是，附件目录d/file下所有文件权限全乱了，导致图片打不开。

根源： 很多人在Windows上做备份，或者用FTP拖拽文件，导致Linux文件权限变成默认值，帝国CMS的data、d、e等目录必须设为755，文件666，否则读写报错。

经验总结：

  • 打包备份时,用tar -czf保持文件权限，如果用FTP下载，上传后用命令批量修改：
    find /网站路径 -type d -exec chmod 755 {} \;
find /网站路径 -type f -exec chmod 644 {} \;
  • 宝塔面板用户：直接勾选“保持权限”再打包，恢复时同理。

推荐配置与插件：别再手动备份了，懒人才是高手

  1. 自带工具别用，用专属插件：帝国CMS官方有个“帝国备份王”（Ebak），独立于CMS运行，可以跨版本、跨编码备份还原，支持分卷、压缩、远程存储，虽然界面丑，但靠谱，下载地址自己去官方找，免费版够用。
  2. 服务器级方案：在宝塔面板里设置计划任务，每天自动执行mysqldump并上传到阿里云OSS或腾讯云COS，成本几乎为零，但误删服务器时能救命，我写过一行脚本：
    mysqldump -u用户 -p密码 库名 | gzip > /backup/$(date +%Y%m%d).sql.gz && ossutil cp /backup/$(date +%Y%m%d).sql.gz oss://你的bucket/帝国备份/
  3. 推荐插件：如果不想折腾命令，装一个“WordPress Database Backup”类插件？不对，帝国CMS的第三方插件少，有一个叫“帝国CMS自动备份插件（by 小K）”的，支持定时备份到邮箱或本地，不过我更推荐自己写计划任务，因为插件跑在PHP里依然会超时。

长期维护建议：别等出事了再哭

  • 备份频率：日更站每天一次，月更站每周一次，重要更新（如换模板、升级版本）前后必须手动再备份一次。
  • 验证备份：备份后别只看文件大小，要尝试恢复到一个测试环境，我见过不少人备份了半年，真正恢复时发现SQL文件是0KB。
  • 异地备份：服务器租来的，不知道什么时候就跑路，我用的是阿里云OSS + 自建NAS双保险，成本每个月几块钱，但数据值几十万。
  • 帝国CMS版本升级的坑：升级前一定先备份数据库和文件，且要备份两份（一份原版，一份升级后的），因为帝国CMS升级脚本有时会改表结构，后悔都没药。
  • 日志记录：在计划任务脚本里加一行echo “$(date) 备份完成” >> /var/log/backup.log，方便排查。

最后说一句：备份不是技术活，是习惯，我刚开始也嫌麻烦，直到丢过一次数据，那几天吃不下睡不着的，现在我这套方案跑了四年，一次都没翻车，照着抄作业，准没错。