没做备份的数据库就是裸奔

误删表、程序写错批量更新、磁盘损坏、勒索病毒——这些事故随时可能发生。没有备份，一次操作失误可能让全部业务数据清零。备份是数据库运维的底线，不是锦上添花。衡量一套备份好不好，不看备没备，看能不能在规定时间内完整恢复。

本文核心知识点
  • 全量备份某一时刻的完整数据副本。
  • 增量备份只备份变化的部分。
  • PITR基于 binlog 恢复到任意时间点。
  • RTO/RPO恢复时间与可容忍丢失量。
数据库备份配图：蓝色渐变背景左侧带对勾盾牌方块发光箭头指向中央数据库圆柱，右侧顺序日志方块再经恢复箭头指回数据库，扁平科技插画
全量备份与日志两路守护数据库、可随时恢复，正是备份恢复的意象。

全量备份与增量备份

全量备份把整个库存一份，恢复简单但耗时、占空间大，一般每天一次。增量备份只备份上次备份后变化的数据，快又省，但恢复要先还原全量、再依次叠加增量。生产常用全量加增量组合：定期全量、频繁增量，兼顾空间和恢复速度。

binlog 与时间点恢复

MySQL 的 binlog 记录了所有写操作。配合全量备份，可以把数据恢复到任意一个时间点（PITR）：先还原全量备份，再重放到事故前一秒的 binlog。这样即使白天误删数据，只要 binlog 没丢，就能恢复到误删之前，把损失降到最小。

# 恢复流程示意：先还原全量，再重放 binlog 到误删前
mysql < full_backup.sql
mysqlbinlog --stop-datetime="2026-10-25 14:59:59" binlog.000123 | mysql

备份必须定期验证

最危险的情况是：平时一直有备份，真出事时才发现备份文件损坏、恢复到一半报错。备份的价值只能靠恢复演练证明。定期在测试环境把备份完整还原一遍，确认能起、数据对得上，备份才算数。不验证的备份等于没备份。