互联网教程

数据库备份与恢复怎么做

备份的价值只在恢复那一刻体现。只备份不验证,等于把希望寄托在一个没打开过的压缩包上。

发布者:黔序科技依据官方文档核验:2026 年 11 月

核心结论

  • 每天逻辑备份 + 定期物理备份
  • 备份文件要异地存一份并验证可恢复
  • 误删数据靠 binlog 做时间点恢复

一句话:两套东西:定期全量备份(应对灾难)与 binlog(应对误操作)。只有全量备份时,误删一张表只能回到昨晚,今天的数据全丢。

逻辑备份(最常用)

  1. 写脚本用 mysqldump 导出指定库,加 --single-transaction 保证一致性且不锁表。
  2. 压缩加密导出后 gzip 压缩,敏感数据加密。
  3. 定时用 crontab 每天低峰执行,文件名带日期。
  4. 异地上传到对象存储的另一个地域或另一台服务器。
  5. 清理保留最近 N 份,避免磁盘被撑满。

恢复

  1. 建空库恢复到新库而不是直接覆盖生产库,先验证内容。
  2. 导入解压后执行导入,注意字符集参数要与原库一致。
  3. 核对比表数量、关键表行数、最新一条记录的时间。
  4. 切换确认无误后再改应用连接指向新库。

注意:备份文件存在和生产库同一块盘上,是最常见的假安全。磁盘坏了两个一起没,勒索软件加密时也会一起加密。异地 + 独立账号是底线。

误删数据的时间点恢复

开启 binlog 后,可以用「最近一次全量备份 + 备份之后的 binlog」恢复到误操作前一秒。前提是 binlog 格式设为 ROW、且没有被过早清理(expire_logs_days 别设太短)。

验证机制

  • 每月抽一份备份恢复到测试实例,跑一次业务查询。
  • 恢复失败要能告警,而不是等真出事才发现。
  • 记录每次恢复演练的时间与结果,形成可查的记录。

资料来源

  • MySQL释 官方文档:mysqldump、binlog 与时间点恢复(PITR)。
  • 对象存储文档:生命周期与跨区域复制。
  • 《网络安全法》第二十一条:重要数据备份释要求。

常见问题

备份文件多大算正常?

与数据量正相关,但突然变小要警惕——可能导出中断或表被清空。给备份文件大小设个下限告警。

能不能只备份不恢复测试?

技术上可以,但实际上等于没有备份。恢复流程里的坑(字符集、权限、版本差异)只有真跑一次才会暴露。

云数据库还要自己备份吗?

云厂商有自动备份,但建议额外导一份到自己的对象存储。账号被误删或欠费停服时,平台备份也拿不到。

相关阅读