2.3 数据库备份与恢复演练

一句话判断

数据库备份的最大陷阱是“做了备份就以为安全了”。真正的安全要验证三件事：备份文件能打开、恢复流程跑得通、恢复出来的数据业务能用。这三件事只有靠“演练”才能确认，而演练恰恰是 90% 的人没做过的环节。

先把两种备份分清楚

1Panel 里其实有两套数据库备份机制，混了会出事：

备份方式 入口 备份了什么
数据库模块的备份 数据库列表 →【备份列表】 只备份这个库
网站模块的备份 网站列表 →【备份列表】 网站目录 + 关联的数据库

网站备份带数据库的前提：你在这个网站的【资源】里关联了数据库（见 1.3 节）。

一个常见误解：以为网站备份就等于数据库备份。如果没关联，网站备份里不含数据库内容。

实战建议：两套都做。网站的备份用于“整站恢复”，数据库模块的备份用于“只恢复某个库”。粒度不同，用途不同。

备份的技术细节：没什么黑魔法

官方说得很直白：

数据库 备份方式 默认路径
MySQL mysqldump /opt/1panel/backup/database/mysql
PostgreSQL pg_dump /opt/1panel/backup/database/postgresql

就是标准的导出工具，生成的是 SQL 文本文件。 知道这一点有好处：备份文件可以直接看、可以直接用别的工具导入、可以被版本管理。你不会被锁死在 1Panel 里。

坏处也要知道：mysqldump 是逻辑备份，大数据量时慢。一个 50G 的库，mysqldump 可能要几十分钟。这不是 1Panel 的问题，是工具特性。 超大库的备份策略要另行考虑（比如物理备份 + 主从同步），面板的备份功能定位是“日常中小库”。

恢复的三个硬约束

官方文档列出的恢复注意事项，字字是坑：

约束一：上传的压缩包里必须有 test.sql。

注意这个文件名是固定的。你导出的备份，1Panel 会自动按这个结构打包。但如果你自己手动打个 zip 塞个 xxx.sql，导入会失败。 要么改名，要么用面板自己的备份流程。

约束二：导入的 SQL 必须符合标准格式。

若你使用 phpmyadmin 导出的 sql 文件，可能会缺少版本编码等信息，导致无法通过 mysqldump 正确导入。

这是最高频的恢复失败原因。 跨工具迁移时，导出工具和导入工具要配套：

导出工具 建议的导入方式
1Panel 备份 1Panel 导入备份（最稳）
mysqldump 命令行 1Panel 导入 或 命令行 mysql < xxx.sql
phpMyAdmin 导出 用 phpMyAdmin 导入（官方建议）

约束三：清空/删库后再恢复，顺序不能错。

恢复是“把数据灌进一个已经存在的库”。如果库结构不对（比如表已经被业务程序改了），恢复会失败或数据错乱。

安全顺序：

  1. 先备份当前状态（万一恢复失败，还能退回去）；
  2. 确认目标库的结构和备份一致；
  3. 执行恢复；
  4. 验证。

恢复演练：本节的核心

为什么必须演练？ 三个真实的失败场景：

场景 平时发现不了，演练时才发现
备份文件损坏（压缩包坏了 / 磁盘有坏道） 不打开不知道
SQL 格式不兼容（跨工具、跨版本） 不导入不知道
自己不会操作（真出事时手抖、顺序错） 不练不知道

第三条最容易被忽略，也最致命。 真出事的时候是凌晨三点、老板在群里问、客户在催，这种压力下第一次走恢复流程，出错率极高。

低风险演练方案

不要在生产库上演练！ 用一个测试库：

  1. 建一个测试库（比如 db_drill），灌几条数据；
  2. 创建备份，下载到本地；
  3. 改几条数据（模拟“数据被改坏了”的场景）；
  4. 执行恢复；
  5. 确认数据变回了备份时的状态；
  6. 记录整个流程的耗时。

第 6 步很有价值：你会知道“恢复这个库要多久”。这个数字在出事时要报给老板的。

进阶：损坏场景演练

更硬核的演练，在测试环境故意制造故障：

故障 演练动作
误删一张表 从备份恢复
整个库被删 重建库结构 → 恢复
只有部分数据要回滚 看备份文件，提取需要的 SQL 段

部分数据回滚是进阶技能：备份是 SQL 文本，打开它，找到对应的 INSERT 语句，单独执行。这比整库恢复快得多，风险也小。 前提是你知道怎么读 SQL。

备份节奏与保留策略

库的重要性 建议节奏 保留
核心业务库（订单、用户） 每日 + 变更前 最近 7~30 份
内容库（文章、配置） 每日或每两日 最近 7~14 份
缓存类（Redis） 靠持久化，定期备份 少量即可
测试库 变更时 少量

“变更前备份”值得单独强调：改库结构、批量更新、清理数据之前，先备一次。这种备份的精准度最高——正好是“出事前那一刻”。

结合计划任务（第 5.1 节）可以做自动定时备份。自动 + 手动两条腿：自动保底，手动精准。

备份保管的三个要点

第一，别让备份和数据库在同一块盘上。

磁盘坏了，库和备份一起没。至少下载一份到本地，或者放到对象存储。 1Panel 的备份支持下载，这步动作成本极低，回报极高。

第二，定期验证备份可读。

不用每次——每季度抽一份最新的备份，打开看看，解压看看，导入测试库看看。“备份成功”和“备份可用”是两回事。

第三，敏感数据的备份要注意安全。

备份里是明文数据（mysqldump 不加密）。下载到本地、传到对象存储，都要考虑这条链路的安全性。别把客户数据的备份随手扔公共网盘。

灾难恢复的真实流程

假设最坏情况：服务器挂了，库没了，只剩本地下载的备份。

灾难恢复流程
  1. 在新服务器装好 1Panel
  2. 通过应用商店安装同版本数据库
  3. 创建空库（库名、编码和原来一致）
  4. 上传备份文件，执行恢复
  5. 逐张表核对行数（和记忆/日志比对）
  6. 应用改连接信息指向新库
  7. 业务回归测试
  8. 观察一段时间再认为恢复完成

第 5 步最容易被跳过。 恢复“成功”（没报错）不等于数据完整。至少抽查核心表的行数和最新记录的时间戳。

时间戳这个技巧很好用：记一下备份时业务最新数据的时间点。恢复后，看表里最新的记录是不是这个时间点——是，说明恢复完整；不是，说明数据丢了一部分。

一个真实的误操作案例

某公司运维要清理日志表，DELETE FROM log_table 忘了加条件——表里几十万条记录全没了。处理过程：

  1. 先停掉所有写入（防止继续污染）；
  2. 翻最近的备份——运气好，当晚有自动备份；
  3. 在测试库恢复这份备份，确认结构和数据；
  4. 从恢复的库中导出 log_table 的数据；
  5. 灌回生产库；
  6. 核对行数，确认。

结果：数据基本找回，丢失的是备份后到误操作之间的新增。

这个案例的三条教训： - 自动备份保了命——没它就是全丢； - 恢复在测试库做，不在生产库——避免二次事故； - 变更前备份能把损失降到零——可惜当时没做。

本节要点

  • 两套备份（数据库模块 / 网站模块带关联库）粒度不同，建议都做；
  • mysqldump 是逻辑备份，大数据量会慢，这是工具特性；
  • 导入要求压缩包内有 test.sql，跨工具导出的 SQL 可能格式不全；
  • 恢复演练每季度一次，记录恢复耗时；
  • 备份别和库放同一块盘，至少存一份到本地或对象存储；
  • 恢复后抽查核心表行数和最新时间戳，确认数据完整。

更完整的备份参数见 《1Panel 官方文档：功能手册》 的数据库章节。

下一节：单机到头，就该上集群了——但集群的能力边界，可能和你想的不一样，见 2.4 节。