随着企业和应用程序越来越依赖 MySQL 数据库来管理其关键数据，确保数据可靠性和可用性变得至关重要。在这个数字信息时代，强大的备份和恢复策略是应用程序稳定性的支柱。
本文中，我们将回顾所有常用的 MySQL 备份和恢复策略，它们是任何应用程序的基石。对应您的特定场景，有多个选项可供选择，每个选项都要求我们考虑相关问题以做出明智的决策。
作者：walter-garcia
本文和封面来源：https://www.percona.com/blog，爱可生开源社区翻译。
本文约 2500 字，预计阅读需要 7 分钟。
为什么 MySQL 备份很重要？
MySQL 备份在保护数据完整性、防止各种不可预见的灾难、硬件故障、数据丢失、损坏和意外删除方面发挥着关键作用。如果没有可靠的备份，数据丢失的后果可能会很严重。企业面临运营中断、财务损失、声誉受损甚至合规违规的风险。了解 MySQL 备份的重要性以及它们如何降低这些风险将有助于组织保证数据一致性、业务连续性，并确保数据在需要时安全且可恢复。
RTO 是什么？
RTO（RecoveryTimeObjective，恢复时间目标）是故障发生到业务恢复能时间点的最大长度。与之相关的问题是：
多久可以恢复？
RPO 是什么？
RPO（RecoveryPointObjective，恢复点目标）是故障发生后业务系统可容忍的数据丢失量。与之相关的问题是：
会丢失多少数据？
MySQL 备份类型有哪些？
MySQL 备份类型主要有两种：物理备份和逻辑备份。下面我们将提供对这两种备份类型以及其他一些策略的更多见解。
- 物理（Percona XtraBackup、RDS/LVM 快照、MySQL Enterprise Backup），只要将 MySQL 服务关闭，也可以使用 cp 或 rsync 命令行来复制数据目录 datadir。
- 逻辑（mysqldump、mydumper、mysqlpump、mysql shell 仅适用于 MySQL 8）。
此外，建议创建 binlog 文件的副本。这种做法有一个重要目的：它使我们能够将数据恢复到最后一个事务。
逻辑备份
这是逻辑数据库结构（CREATE DATABASE、CREATE TABLE 语句）和内容（INSERT 语句）的转储。建议将其用于较小量的数据。如果与物理备份相比，此方法的缺点是速度较慢（备份和恢复）。如果需要，您可以使用 mydumper 备份和恢复单个数据库或单个表，这对于将某些数据复制到不同的环境以运行测试非常有用。另外，mydumper 可以进行一致（只要所有表都是 InnoDB 引擎）备份并提供准确的主从日志位置。
输出比物理备份大，特别是以文本格式保存时，但它可以根据您使用的软件即时压缩。例如，mydumper 可以压缩，而 mysqldump 需要添加一个管道将输出重定向到 gzip 文件。
逻辑备份用于解决数据损坏或恢复表子集的需要。
物理备份
简而言之，它由数据库目录和文件的精确副本组成。这可以是 MySQL datadir 目录的全部或部分副本。这种备份最常用于轻松快速地恢复或创建新的副本节点，并用于解决主机故障。建议使用相同的 MySQL 版本进行恢复。建议使用 Percona XtraBackup，因为它可以包含任何相关文件，例如 cnf 配置文件等配置文件。
快照备份
某些文件系统实现允许存储“快照”。它们提供给定时间点的文件系统的逻辑副本，而不需要整个文件系统的物理副本。MySQL 本身不提供获取文件系统快照的功能，但可以使用 LVM 或 ZFS 等第三方解决方案来实现。
缺点是有时物理备份不会压缩太多，因为数据通常是二进制格式，有时表已经被压缩。
二进制日志备份
Binlog 备份专门针对 RPO。二进制日志文件包含执行的每个发生更改的 SQL 查询的记录。
从 MySQL 5.6 开始，您可以使用 mysqlbinlog 从远程服务器流式传输二进制日志。可以将二进制日志备份与 Percona XtraBackup 或 mydumper 备份结合起来，以允许恢复到最近备份的二进制日志的末尾。
增量/差异备份
增量备份是对自上次备份以来发生更改的所有内容的备份（二进制日志备份是增量备份的特殊情况）。如果数据集大小很大，这是一个非常好的选择，因为您可以在本周初进行完整备份并每天运行增量备份。此外，备份大小比完整备份小。
与增量备份相关的主要风险是：
- 单个损坏的增量备份可能会使所有其他备份失效
- 增量备份通常会对 RTO 产生负面影响
对于差异备份，它会复制与上次备份的差异，其优点是从一个备份到下一个备份的大量数据不会发生更改，因此结果可以是明显更小的备份。这可以节省磁盘空间。
Percona XtraBackup 支持增量备份和差异备份。
为什么需要 MySQL 备份？
当出现多种问题时，需要 MySQL 备份：
- 主机故障：我们可能会因磁盘停滞或磁盘损坏而遇到多种问题。同样，在云服务中，我们的数据库实例可能会损坏并且无法访问。
- 数据损坏：这可能发生在断电时，MySQL 无法正确写入并关闭文件，有时当 MySQL 再次启动时，由于数据损坏而无法启动，并且崩溃恢复过程无法修复它。
- 数据不一致：当人犯错误时，通过主节点或副本节点删除/更新错误数据。
- 数据中心故障：停电或互联网提供商问题。
- 立法/法规：提供一致的商业价值和客户满意度。
MySQL 备份和恢复最佳实践
在本节中，我们将探讨基本的 MySQL 备份和恢复最佳实践，以保护您的数据并确保数据库顺利运行。
异地存储
强烈建议将所有备份方法复制到另一个地方，例如云或外部文件服务器，这样在主机故障或数据中心故障的情况下，确保还有另一个副本。
并非所有备份文件都需要上传到云端，有时您需要花费在下载上的时间比恢复过程中消耗的时间还要多。
一个好的方法是在备份服务器上本地保留 1-7 天，以便需要快速恢复，这取决于您的业务法规。
加密
备份包含敏感数据，因此强烈建议加密，尤其是异地存储。当您需要恢复备份时，这会增加更多时间，但可以保证数据安全。
GPG 是加密备份的一个不错的选择，如果您使用此选项或其他替代方案，请不要忘记获取密钥/密码的副本。如果丢失，您的备份将毫无用处。
恢复测试
根据您的业务，强烈建议每月至少测试一次备份。此操作可验证您的备份未损坏，并提供有关恢复时间的关键指标。此过程应该自动化，以获取完整备份、恢复它，并最终将此服务器配置为当前主服务器或另一个副本的副本。这也有助于验证复制过程没有错误。
许多客户正在使用这种方法来刷新他们的 QA/STG 环境，以便从生产备份中获取最新数据。
除了上述内容之外，建议创建手动或自动恢复文档流程，以将所有步骤放在一起，以便在发生灾难时，您可以遵循它而不会浪费时间。
保留要求
最后但并非最不重要的一点是，保留不同备份类型的多个副本非常重要。
我们最好的建议是：
- 备份服务器本地的一到两个物理备份（只要空间允许）。
- 备份服务器上本地的每日 7 次和每周 4 次逻辑备份。
- 备份服务器本地 30 天的 binlog 备份。
- 对于异地备份（如 S3、Google Cloud 等），每月备份保留一年或更长时间。
对于本地备份，请记住，您至少需要当前数据集大小 2.5 倍的可用磁盘空间来保存/满足这些保留策略。不要忘记加密所有备份类型！
法律或监管要求也可能规定数据必须存档多长时间。
验证 MySQL 备份
因此，您已经获得了遵循所有最佳实践的备份过程。那你怎么知道备份成功了？你看过文件大小吗？您是否只检查创建了一个文件？也许您只查看了您使用的工具的退出代码？
“在验证备份之前，你还没有进行备份。” 很好的建议。换句话说，您所做的每个备份都可以被视为薛定谔的备份；在你验证之前，能确定它有效吗？
这里的最佳实践是使用您创建的备份简单地恢复 MySQL 服务器；然而，你创造了它。处理此恢复的机器不需要像源一样强大；一个简单的虚拟机就可以管理这项任务，并且可以很好地实现自动化。
您可以使用 mysql 客户端本身恢复 mysqldump：
zcat my_full_backup.sql.gz | mysql
使用 mydumper/myloader：
myloader --directory dump_dir --overwrite-tables --verbose=3
Percona XtraBackup：
# Prepare the backup
xtrabackup --prepare --parallel 4 --use-memory 4G --target-dir /var/backup
# Copy backup to original location (ie: /var/lib/mysql), assuming backup taken on same host
xtrabackup --copy-back --target-dir /var/backup
# Fix file permissions if necessary
chown -R mysql:mysql /var/lib/mysql
# Start MySQL
systemctl start mysql
是的，Percona XtraBackup 确实需要更多步骤，但物理备份始终是最快的备份方式和最快的恢复方式。
