必备的MySQL备份策略：为你的数据选择正确的方法

你的MySQL备份策略只有在压力下能够恢复时才有效。一个转储文件、一个文件系统快照和一个物理备份解决不同的恢复问题，因此正确的选择取决于你的数据大小、停机容忍度以及你能承受丢失多少数据。

为什么MySQL备份需要恢复计划

备份不仅能保护你免受磁盘故障的影响。它们还能帮助你从应用程序错误、糟糕的部署、意外删除、勒索软件和区域故障中恢复。

从两个目标开始：

RTO： 在恢复期间数据库可以停机多长时间？
RPO： 你能丢失多少最近的数据？

例如，一个小型内部维基可能可以容忍每晚的mysqldump和一小时的恢复。一个生产订单系统可能需要物理备份加上二进制日志，以便在发生错误的DELETE之前恢复到特定秒。

使用`mysqldump`进行逻辑备份

逻辑备份将模式和数据导出为SQL。它们可移植且易于检查，但在大型数据库上创建速度慢，恢复速度更慢。

备份一个数据库：

mysqldump -u your_username -p your_database_name > backup_file.sql

备份所有数据库：

mysqldump -u your_username -p --all-databases > all_databases_backup.sql

备份特定表：

mysqldump -u your_username -p your_database_name table1 table2 > specific_tables_backup.sql

当你的模式依赖于例程、事件和触发器时，请包含它们。在典型的mysqldump使用中，触发器默认包含，但在备份运行手册中明确意图有助于审查者注意到它。

mysqldump -u your_username -p --routines --events --triggers your_database_name > database_with_programs.sql

恢复到现有数据库：

mysql -u your_username -p your_database_name < backup_file.sql

对于InnoDB密集型工作负载，添加--single-transaction，以便转储读取一致快照而无需长时间的表锁：

mysqldump -u your_username -p --single-transaction --routines --events your_database_name | gzip > backup_file.sql.gz

如果你依赖非事务性表（如MyISAM），不要将--single-transaction作为唯一的一致性保护。这些表需要不同的锁定或快照计划。

针对大型数据库的物理备份

物理备份复制MySQL数据文件，而不是将数据库重建为SQL。它们通常更适合大型数据集，因为恢复时间更接近复制文件并应用恢复日志。

常见选项包括：

文件系统或云卷快照，协调以确保MySQL数据崩溃一致或应用程序一致。
Percona XtraBackup，一个广泛使用的开源工具，用于MySQL兼容的InnoDB数据的热物理备份。
MySQL Enterprise Backup，Oracle为MySQL Enterprise部署提供的商业备份工具。

使用XtraBackup创建完整备份：

xtrabackup --backup --target-dir=/path/to/backup/full --user=your_username --password=your_password

在恢复前准备备份：

xtrabackup --prepare --target-dir=/path/to/backup/full

停止MySQL并移开旧数据目录后恢复：

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.before-restore
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/path/to/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

此示例假设使用Debian风格的服务名称和数据目录。在运行恢复命令之前，请检查你的软件包、容器镜像或托管数据库文档。

二进制日志和时间点恢复

备份告诉你可以从哪里恢复。二进制日志帮助你在备份后重放更改，这是时间点恢复所需的。

在自管理的MySQL上启用二进制日志，使用适合你版本和打包的log_bin设置。然后将二进制日志备份到与数据库服务器分开的位置。

当你恢复时，通常：

恢复最新的良好完整或增量备份。
使用mysqlbinlog重放二进制日志直到目标时间或位置。
如果从操作错误中恢复，在错误语句之前停止。

选择正确的备份策略

使用简单的决策规则：

小型数据库：从自动化的mysqldump、压缩、异地存储和定期恢复测试开始。
中型数据库：添加二进制日志备份，以便可以恢复到某个时间点。
大型或业务关键型数据库：使用物理备份、支持的增量备份、二进制日志、监控和文档化的恢复演练。

不要仅根据备份速度选择。在事件期间，恢复速度更重要。

真正重要的备份实践

自动化备份作业，但手动测试恢复，直到过程变得枯燥。将备份存储在异地，加密敏感备份，监控作业失败，并保持足够的保留时间以检测几天后发现的静默损坏或意外删除。

还要记录确切的恢复顺序。在真正的故障期间，未来的你不应该猜测哪个完整备份、增量备份和二进制日志范围属于一起。

要点

选择与恢复目标匹配的备份方法。mysqldump适用于小型数据库和可移植恢复。物理备份适合大型系统。当你需要时间点恢复时，二进制日志弥补了差距。无论你选择什么，只有在测试环境中成功恢复后，备份才算有效。