3.2 备份与恢复失败

先给一个判断

备份失败一般不可怕，恢复失败才可怕。 备份失败你还有原始数据；恢复失败可能把好好的数据覆盖成半残状态。所以这一节的总体原则是：备份失败 → 看日志修备份；恢复失败 → 立刻停手，先保护现状。任何恢复操作之前，都先做一个当前状态的备份当底牌。

现象与原因对照表

现象 可能原因 第一步
备份任务状态失败 磁盘空间不足 df -h
备份了但文件很小/为空 数据库实际是空的 / 权限不够 看备份文件大小和内容
上传备份恢复失败 上传的压缩包里没有要求的 SQL 文件 看任务日志报错
恢复后网站数据还是旧的 恢复了别的库 / 网站关联的是另一个库 核对“关联资源”
手动导出的 SQL 导不进去 导出工具的格式不兼容 换导入方式
备份文件越来越大 备份目录被包含进了源目录 / 没设保留份数 检查任务参数

规律：凡是“备份失败”，先做两件事——看任务日志、看磁盘空间；凡是“恢复失败”，先做一件事——停手，备现状。

备份：官方怎么做的

1Panel 的数据库备份用 mysqldump 方式，默认备份目录是 /opt/1panel/apps 之外的 /opt/1panel/backup/database/mysql（不同版本路径以面板实际显示为准）。备份是异步任务，进度和错误在 日志审计 → 任务日志 里看。

备份失败的两个高频原因：

# 原因一：磁盘满了（最常见）
df -h /

# 原因二：备份目录权限或空间问题，看一下目录
ls -ld /opt/1panel/backup/database/mysql

数据库本身的当前状态也能辅助判断：如果数据库正在被大查询占满资源，备份任务可能超时。这种情况把备份安排在凌晨低峰期（用计划任务），比白天手动备份稳得多。

用计划任务做常态化备份

生产环境不应该靠人记得点备份。计划任务支持备份应用、网站和数据库，关键参数：

参数 建议设置 为什么
执行周期 每天凌晨 避开业务高峰，对性能无感
备份账号 至少配一个远程目标 本机备份本机，出事一起没
保留份数 7~30 份 太少回不去，太多吃磁盘
排除规则 排除缓存目录 备份体积小一半
压缩密码 记牢并存好 丢了密码备份无法恢复

一个隐形大坑（官方原话）：备份目录类的任务，“避免把备份输出目录再次包含进源目录，否则可能造成递归归档或空间快速增长”。翻译一下：备份存哪，备份就别把哪一起打包，否则每次备份都把之前的备份全打进去，磁盘几天就爆。

日志类备份的注意事项

计划任务里还有“备份日志”和“切割网站日志”。注意两点：

  1. 日志被系统轮转或删除后，任务只能备份当时还在的内容；
  2. 网站日志切割要配合保留份数，否则历史日志慢慢吃满磁盘（详见 4.4 节）。

恢复：三个硬约束

官方文档把恢复的坑说得非常直白：

  1. 上传文件恢复时，压缩包里必须存在要求的 SQL 文件（如 test.sql），否则无法正确导入；
  2. 导入的 SQL 文件格式必须符合标准——用 phpMyAdmin 导出的文件可能缺版本、编码等信息，导致 mysqldump 方式导入失败；
  3. 实在导不进去，可以尝试用 phpMyAdmin 导入（数据库列表上方的【管理】可以跳转 phpMyAdmin / Adminer）。

翻译成人话：不是所有 .sql 文件都能互相喂。跨工具移动数据时，优先用同一种工具导出导入；碰壁了换 phpMyAdmin 的导入功能试一次。

一个完整的复现与修复

场景一：备份失败。

现象：创建数据库备份，任务状态显示失败。

排查：

  1. 打开任务日志，报错写着写入失败 / 空间不足；
  2. df -h / 一看，根分区用了 98%；
  3. 先清理：用 工具箱 → 缓存清理 清掉系统垃圾、未用镜像、构建缓存（详见 4.4 节），腾出空间；
  4. 重新备份，成功。

场景二：恢复失败。

现象：从本地下载的老备份恢复到新装的数据库，导入失败。

排查：

  1. 任务日志报“找不到要求的 SQL 文件”；
  2. 解压备份包看内容——当年是用 phpMyAdmin 导出的单文件，压缩包结构和 1Panel 要求的不一样；
  3. 用 phpMyAdmin 的导入功能直接导这个文件，成功。

复盘要点：备份文件要定期验证能不能恢复。官方文档原话提醒：“任务执行成功只表示备份流程完成”，生产环境应该定期做恢复验证，确认应用版本、数据库版本、压缩密码和远端文件都可用。一直没试过的备份，约等于没有备份。

再补一句：场景二的“下载老备份来恢复”，其实是迁移场景的预演——跨版本（比如 MySQL 5.7 的备份恢复到 8.0）经常还要处理字符集和语法的差异，低版本备份往高版本恢复成功率较高，反过来要特别小心（升级和数据迁移的坑见 3.4 节）。

网站和应用备份的两点提醒

备份对象 入口 注意事项
网站 网站列表 → 更多 → 备份列表 关联了数据库的会一起备份
应用 已安装应用 → 备份 可下载、可导入恢复
数据库 数据库列表 → 备份 mysqldump 方式
全量 面板设置 → 快照 整个 1Panel 的状态

网站配置 → 资源 里可以把网站和一个数据库关联，备份网站时会同时备份关联的数据库。注意官方的警告：切换关联的数据库会导致以前的备份无法恢复——关联关系别随手换。

恢复前的标准动作

养成这个习惯，能避免 90% 的悲剧：

  1. 先备份当前状态（哪怕现状是坏的，也留个底）。怎么操作：数据库列表 → 备份，把当前这个半残的库先备一份，名字里注明“恢复前快照”；
  2. 确认目标库的总行数/表数，恢复后用来对比验证：
# 恢复前数一下（在数据库管理工具里执行）
SHOW TABLES;
SELECT COUNT(*) FROM 你的核心表;
  1. 恢复后重新数一遍，对得上才算成功；
  2. 重启/刷新使用该库的应用，让它重新读取数据。

为什么要数行数？ 因为恢复“成功”有时候只是导入流程没报错，数据其实没进去或者只进去一半。任务状态是绿色，不代表数据是真的。多花 30 秒验证，能省掉后面一整天的“数据怎么不对”。

网站备份恢复的特殊情况

网站恢复走 网站列表 → 备份列表 → 恢复，恢复的是网站目录的文件。特别注意：

  • 恢复不会恢复 OpenResty 的网站配置（伪静态、CORS 那些），要单独留底（见 2.4 节）；
  • 关联的数据库恢复，要在数据库那边单独操作，网站和数据库的备份点要对齐——网站恢复到周一、数据库恢复到周三，出来的组合谁也不知道对不对。

快照：系统级的后悔药

除了逐个备份，1Panel 还支持系统快照（面板设置 / 计划任务 → 系统快照），把整个 1Panel 的状态打成一个包。做大规模调整（升级、迁移、换配置）之前拍一个快照，出问题能整体回滚。快照的相关注意事项见 1.4 节，这里只强调一件事：快照占空间不小，要配合保留份数和镜像包含选项使用，别让快照自己把磁盘吃满。

下载异地：备份的最后一公里

备份文件留在服务器本机上，和服务器一起没了。 1Panel 支持在备份账号里配置远程目标（面板设置 → 备份账号），计划任务里可以把备份同时推到远端。哪怕只是一周下一次备份到本地电脑，也比全在服务器上强。

判断你的备份策略及不及格，问自己三个问题：

  1. 备份在另一台机器/另一个地理位置上吗？
  2. 最近三个月恢复验证过一次吗？
  3. 如果现在服务器没了，多长时间能恢复？

三个都能答“是”才算合格。大部分人的备份是“有在备份”，而不是“能恢复”——这两件事差得很远。

本节要点

  • 备份失败先看任务日志，第一位嫌疑是磁盘空间；
  • 恢复失败立刻停手，先给现状做备份再继续；
  • 上传恢复要求压缩包结构符合规范，跨工具导出的 SQL 换 phpMyAdmin 导入；
  • 备份要定期做恢复验证，没验证过的备份等于没有；
  • 备份文件务必异地保存，别和业务放一台机器；
  • 网站配置不在网站备份里，要单独留底。

备份与恢复的官方说明见 1Panel 官方文档：MySQL，以官方文档为准。

下一节：数据库告一段落，来说应用商店——应用安装失败和容器起不来，怎么从日志里揪出原因。