目录
在企业中数据的价值至关重要,数据保障了企业业务的正常运行。因此,数
据的安全性及数据的可靠性是运维的重中之重,任何数据的丢失夫都可能对企业产
生严重的后果。通常情况下造成数据丢失的原因有如下几种:
程序错误。
人为操作错误。
运算错误。
磁盘故障。
灾难(如火灾、地震)和盗窃
按备份内容分类 ：完整备份 ：将整个数据库包括数据文件、日志文件以及数据库对象等全部复制到备份介质上。这是最基本的备份方式，优点是恢复时只需一个备份文件，可快速还原整个数据库到备份时的状态。缺点是备份时间长、占用空间大，尤其是对于大型数据库。差异备份 ：只备份自上次完整备份以来发生更改的数据。它基于完整备份，每次执行差异备份时，会检查数据库中自上次完整备份后被修改过的页面，并将这些页面备份下来。这种备份方式的优点是备份时间相对较短，占用空间较小，恢复时先还原完整备份，再还原最新的差异备份即可，恢复速度也比较快。日志备份 ：主要备份数据库的事务日志，记录了数据库的所有更改操作。通过日志备份，可以将数据库恢复到特定的时间点或故障点。日志备份通常需要与完整备份或差异备份结合使用。其优点是可以实现更精细的恢复，例如恢复到某一时刻的数据库状态，缺点是恢复过程相对复杂，需要按照一定的顺序应用多个日志备份。按备份方式分类 ：冷备份 ：也称为静态备份，是在数据库关闭状态下进行的备份操作。这种方式的优点是备份过程简单，不会出现数据不一致的情况，因为数据库处于静止状态。缺点是在备份期间数据库无法使用，会影响业务的正常运行，适用于允许数据库短时间停机的场景。热备份 ：又称动态备份，是在数据库运行状态下进行的备份。它通过数据库的日志文件和其他机制来确保备份的数据一致性。热备份的优点是不影响数据库的正常使用，能在不中断业务的情况下进行备份。但实现较为复杂，对系统性能有一定影响，并且需要更多的硬件资源支持。温备份 ：介于冷备份和热备份之间。在进行温备份时，数据库处于一种特殊的状态，允许某些只读操作继续进行，但会限制写入操作。这种备份方式能在一定程度上减少对业务的影响，同时保证备份数据的一致性，其性能和复杂度也介于冷备份和热备份之间。按备份存储位置分类 ：本地备份 ：将备份数据存储在与数据库服务器相同的本地存储设备上，如硬盘、磁带等。优点是备份和恢复速度快，因为数据传输距离短。缺点是本地存储设备可能会受到硬件故障、火灾、洪水等灾害的影响，导致备份数据丢失，数据安全性相对较低。异地备份：将备份数据存储在远离数据库服务器的其他地理位置的存储设备上，可以是通过网络连接的远程服务器，也可以是云存储服务。异地备份能有效防止本地灾害对数据的破坏，提高数据的安全性和可靠性。但由于数据传输距离远，备份和恢复速度可能会受到网络带宽的限制。
使用数据库管理系统自带的备份工具 许多数据库管理系统（如 MySQL、Oracle、SQL Server 等）都提供了内置的备份功能。以 MySQL 为例，可以使用mysqldump命令行工具来进行备份。该工具可以将数据库中的数据和结构导出到一个 SQL 文件中，例如：mysqldump -u username -p password database_name > backup.sql，在还原时只需执行该 SQL 文件即可。Oracle 数据库则可以使用 RMAN（Recovery Manager）工具进行备份，RMAN 提供了强大的备份和恢复功能，支持多种备份策略，如完整备份、差异备份和增量备份等。SQL Server 可以通过 SQL Server Management Studio 图形化界面或 T-SQL 语句来进行备份操作，使用BACKUP DATABASE语句可以将数据库备份到指定的文件。利用第三方备份软件 市面上有许多第三方备份软件，如 Veeam、Commvault、Symantec Backup Exec 等，这些软件通常支持多种数据库类型，提供了更丰富的功能和更灵活的备份策略。它们可以与数据库管理系统集成，实现自动化的备份任务调度、数据加密、异地存储等功能。例如，Veeam 软件针对不同的数据库有专门的插件，能够实现高效的备份和恢复，并且支持在备份过程中对数据进行压缩和加密，以提高存储效率和数据安全性。Commvault 软件则提供了集中管理控制台，可以对多个不同类型的数据库进行统一的备份管理，方便企业进行大规模的数据备份和恢复操作。基于云的备份服务随着云计算的发展，越来越多的企业选择将数据库备份存储在云端。云服务提供商（如阿里云、腾讯云、亚马逊 AWS 等）提供了专门的数据库备份服务。以阿里云的 RDS（关系型数据库服务）为例，用户可以在控制台中轻松设置备份策略，包括备份时间、备份保留天数等。阿里云会自动按照用户设置的策略对数据库进行备份，并将备份数据存储在云端的对象存储服务（OSS）中。腾讯云的 CynosDB 也提供了类似的备份功能，支持全量备份和增量备份，并且可以将备份数据跨地域存储，以提高数据的容灾能力。亚马逊 AWS 的 RDS 则提供了多种备份选项，用户可以选择将备份数据存储在 Amazon S3 等存储服务中，还可以利用 AWS 的其他服务来实现更复杂的备份和恢复策略。
物理冷备份一般用tar命令直接打包数据库文件夹,而在过进行备份之前需
要使用"systemctlstopmysqld"命令关闭mysqld服务。
备份数据库创建一个aaa目录为备份数据存储路径，使用tar创建备份文件，整个数据库文件夹备份属于完全备份
[root@localhost ^]# systemctl stop mysqld
[root@localhost ^]# mkdir /backup
[root@localhost ^]# tar zcf /backup/mysql_all-$(date
+%F).tar. gz
/usr/local/mysql/data/
[root@localhost ^]# ls -l /backup/
-rw-r--r-- 1 root root 2473377 3月22日 16：18 mysql------all-2025-03-22.tar.gz恢复数据库
执行下面操作将数据库文件/usr/local/mysql/data/转移至bak目录下,模拟故障。
[root@localhost ~]# mkdir bak
[root@localhost ~]# mv /usr/local/mysql/data//root/bak/
[root@localhost ~]# mkdir restore
[root@localhost ~]# tar zxf /backup/mysql_all-2025-03-:22. tar. gz
restore/
[root@localhost ~]# mv restore/usr/local/mysql/data/ /usr//local/mysql/
[root@localhost ~]# systemctl start mysqld备份整个数据库
mysqldump -u 用户名 -p 密码 数据库名 > 备份文件.sql示例
mysqldump -u root -p123456 mydb > /data/backup/mydb_backup.sql备份特定表
mysqldump -u 用户名 -p 密码 数据库名 表1 表2 > 备份文件.sql示例
mysqldump -u root -p123456 mydb users orders > /data/backup/mydb_tables.sql备份结构（不包含数据）
mysqldump -u 用户名 -p 密码 -d 数据库名 > 结构文件.sql备份数据（不包含结构）
mysqldump -u 用户名 -p 密码 -t 数据库名 > 数据文件.sql增量备份（需结合 binlog）
# 先全量备份
mysqldump -u 用户名 -p 密码 --single-transaction --master-data=2 数据库名 > 全量备份.sql
# 后续通过 binlog 实现增量
mysqlbinlog binlog.000001 > 增量备份.sql恢复到新数据库
# 1. 创建目标数据库
mysql -u 用户名 -p 密码 -e "CREATE DATABASE 新数据库名;"
# 2. 导入备份文件
mysql -u 用户名 -p 密码 新数据库名 < 备份文件.sql恢复到已有数据库（需先清空数据）
# 1. 清空目标数据库（危险操作！）
mysql -u 用户名 -p 密码 -e "DROP DATABASE 数据库名; CREATE DATABASE 数据库名;"
# 2. 导入备份
mysql -u 用户名 -p 密码 数据库名 < 备份文件.sql恢复单个表
mysql -u 用户名 -p 密码 数据库名 < 表备份文件.sql增量备份与恢复概述
MySQL 增量备份是数据库管理中的重要策略，用于在两次全量备份之间捕获并保存数据变化。这种方法能显著减少备份时间和存储空间需求，同时确保数据可恢复至任意时间点
增量备份的实现方式
基于二进制日志（binlog）的增量备份
二进制日志记录了所有更改数据的 SQL 语句，是 MySQL 增量备份的基础。以下是配置和使用 binlog 进行增量备份的步骤
启用二进制日志
在my.cnf或my.ini配置文件中添加以下内容
[mysqld]
log-bin=mysql-bin
server-id=1
binlog-format=ROW
expire-logs-days=7重启 MySQL 服务使配置生效
创建全量备份
使用mysqldump创建初始全量备份
mysqldump -u root -p --all-databases --single-transaction --master-data=2 > full_backup.sql定期备份 binlog
使用mysqlbinlog工具备份自上次备份以来的所有 binlog
mysqlbinlog --start-datetime="2025-05-10 00:00:00" --stop-datetime="2025-05-12 23:59:59" /var/lib/mysql/mysql-bin.000001 > incremental_backup_$(date +%Y%m%d).sql基于时间点恢复（PITR）的增量恢复
当需要恢复到某个特定时间点时，可以按以下步骤操作
恢复全量备份
mysql -u root -p < full_backup.sql应用增量备份
按时间顺序应用各个增量备份文件
mysql -u root -p < incremental_backup_20250510.sql
mysql -u root -p < incremental_backup_20250511.sql在数据库管理中，"一般恢复" 通常指的是从完整备份中还原数据的标准流程，不涉及时间点恢复或复杂的增量恢复场景
恢复前的必要检查
确认备份文件存在且完整
ls -lh /path/to/backup.sql # 检查SQL备份文件
ls -lh /path/to/backup.sql.gz # 检查压缩备份文件验证 MySQL 服务状态
systemctl status mysql # Linux系统
net stop mysql # Windows系统（管理员权限）检查目标数据库状态
若恢复到空库，需确保目标数据库已创建
CREATE DATABASE IF NOT EXISTS target_db;从 SQL 备份恢复（最常见方式）
恢复完整数据库
mysql -u root -p target_db < /path/to/backup.sql恢复压缩备份（自动解压并导入）
# 针对gzip压缩的备份
gunzip -c /path/to/backup.sql.gz | mysql -u root -p target_db
# 针对bz2压缩的备份
bunzip2 -c /path/to/backup.sql.bz2 | mysql -u root -p target_db恢复时指定字符集
mysql -u root -p --default-character-set=utf8mb4 target_db < backup.sql从物理备份恢复（复制数据文件）
适用于直接复制 MySQL 数据目录（如 InnoDB 表空间文件）的场景
停止 MySQL 服务
systemctl stop mysql备份现有数据目录（谨慎操作）
mv /var/lib/mysql /var/lib/mysql_backup复制备份文件到数据目录
cp -R /path/to/backup_data/* /var/lib/mysql/修复权限并启动服务
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql复全量备份
首先需要从最近的全量备份中恢复数据
# 使用 mysqldump 备份恢复
mysql -u username -p < full_backup.sql
# 或使用物理备份（如 Percona XtraBackup）
xtrabackup --prepare --target-dir=/path/to/backup
xtrabackup --copy-back --target-dir=/path/to/backup基于位置恢复（point-in-time recovery）
使用mysqlbinlog工具从 binlog 中提取特定位置的 SQL 语句并执行 按时间点恢复
# 从binlog中提取指定时间范围的SQL并执行
mysqlbinlog --start-datetime="2025-05-10 00:00:00" \
--stop-datetime="2025-05-12 10:30:00" \
/var/log/mysql/binlog.000001 | mysql -u username -p按位置（position）恢复
# 从binlog中提取指定position范围的SQL并执行
mysqlbinlog --start-position=1234 \
--stop-position=5678 \
/var/log/mysql/binlog.000001 | mysql -u username -p恢复到最新状态
若需恢复到最新状态（不指定停止时间 / 位置）
mysqlbinlog /var/log/mysql/binlog.000001 | mysql -u username -p前提条件
启用 binlog ：确保 MySQL 配置中 log_bin 已启用。定期全量备份 ：需要最近一次的全量备份（如 mysqldump 或物理备份）。完整 binlog：从全量备份时间点到目标恢复时间点的所有 binlog 文件。
恢复全量备份
# 使用逻辑备份恢复（mysqldump）
mysql -u username -p < full_backup.sql
# 或使用物理备份恢复（Percona XtraBackup）
xtrabackup --prepare --target-dir=/path/to/backup
xtrabackup --copy-back --target-dir=/path/to/backup确定目标时间点
明确需要恢复到的具体时间
目标恢复时间：2025-05-12 14:30:00提取并应用 binlog
使用 mysqlbinlog 工具提取从备份时间到目标时间点的所有变更
# 从 binlog 中提取指定时间范围的 SQL 并执行
mysqlbinlog --start-datetime="2025-05-10 00:00:00" \ # 全量备份时间
--stop-datetime="2025-05-12 14:30:00" \ # 目标恢复时间
/var/log/mysql/binlog.000001 \
/var/log/mysql/binlog.000002 \
| mysql -u username -p验证恢复结果
-- 检查数据是否恢复到目标时间点
SELECT * FROM your_table ORDER BY updated_at DESC LIMIT 10;常见问题处理
binlog 缺失 ：若部分 binlog 丢失，只能恢复到最后一个可用的 binlog 时间点。权限问题 ：确保执行恢复的用户有足够权限（如 SUPER 权限）。大文件处理：对于大 binlog 文件，可先过滤并保存为临时 SQL 文件再执行
评估企业数据
数据资产梳理 ：对企业内各类数据进行全面盘点，包括数据库、文件系统、邮件系统、业务系统产生的数据等，明确数据的类型、规模、重要性和敏感度。数据增长趋势分析：通过分析历史数据增长情况，预测未来一段时间内的数据增长趋势，以便合理规划备份存储容量。
明确业务需求
RTO 和 RPO 指标确定 ：根据业务的重要性和对数据丢失的容忍程度，确定恢复时间目标（RTO）和恢复点目标（RPO）。例如，对于核心业务系统，可能要求 RTO 在几分钟内，RPO 为近实时；而对于一些非关键业务，RTO 可以是数小时，RPO 可以是一天或数天。业务高峰和低谷期分析：了解业务系统的使用高峰和低谷期，以便在备份策略中合理安排备份任务的执行时间，避免对业务系统性能产生较大影响。
选择备份方式
全量备份 ：定期对所有数据进行完整备份，优点是恢复时简单快捷，可直接从全量备份中恢复数据；缺点是备份时间长、占用存储空间大。一般建议每周或每月进行一次全量备份。增量备份 ：只备份自上次全量备份或增量备份以来发生变化的数据，备份速度快、占用空间小，但恢复时需要依次应用全量备份和多个增量备份，恢复过程相对复杂。可以每天或每小时进行增量备份。差异备份：备份自上次全量备份以来发生变化的数据，恢复时只需使用全量备份和最近一次的差异备份，恢复速度比增量备份快，但每次差异备份的数据量会随着时间增加而增多。可根据业务需求选择每隔几天进行一次差异备份。
确定备份存储介质和位置
存储介质选择 ：常见的存储介质有磁盘、磁带、云存储等。磁盘存储读写速度快，适合快速恢复数据；磁带存储容量大、成本低，但读写速度慢，适合长期归档存储；云存储具有可扩展性强、数据安全可靠、异地容灾等优点，但需要考虑网络带宽和存储成本。企业可根据自身情况选择单一或多种存储介质组合。存储位置规划：为了防止本地灾难导致数据丢失，应将备份数据存储在异地，实现异地容灾。可以选择企业的其他分支机构、数据中心或云存储平台作为异地存储位置。
制定备份计划
备份频率设置 ：根据业务需求和数据变化频率，合理设置全量备份、增量备份或差异备份的执行频率。例如，对于核心业务系统的数据库，可每天进行增量备份，每周进行一次全量备份；对于文件服务器，可根据文件修改情况，每小时或每天进行增量备份，每月进行一次全量备份。备份时间安排：将备份任务安排在业务低谷期执行，以减少对业务系统性能的影响。例如，对于大多数企业来说，夜间或周末是业务相对空闲的时间段，可将备份任务设置在这些时间段运行。
数据安全与加密
访问控制 ：对备份数据的访问进行严格的权限管理，只有授权人员才能访问和恢复数据。通过设置用户角色和权限，限制不同用户对备份数据的操作权限。数据加密：对备份数据进行加密处理，确保数据在存储和传输过程中的安全性。可采用对称加密或非对称加密算法，对备份文件进行加密，只有拥有正确密钥的用户才能解密和恢复数据。
监控与报警
备份任务监控 ：建立备份监控系统，实时监控备份任务的执行状态，包括备份进度、备份成功率、存储空间使用情况等。通过监控系统及时发现备份过程中出现的问题，如备份失败、存储空间不足等。报警机制设置：当备份任务出现异常情况时，能够及时发出报警通知。报警方式可以包括邮件、短信、即时通讯工具等，确保相关人员能够及时了解备份问题并采取相应的措施。
测试与验证
恢复测试 ：定期进行备份数据的恢复测试，以验证备份数据的可用性和完整性。恢复测试可以在测试环境中模拟实际的灾难场景，将备份数据恢复到测试系统中，检查数据是否能够正常恢复和使用。策略验证：根据业务需求的变化和技术的发展，定期对备份策略进行评估和验证，确保备份策略仍然能够满足企业的数据保护需求。如有必要，对备份策略进行调整和优化。
成本控制
预算规划 ：制定备份策略时，要考虑到硬件设备、软件许可、存储介质、云服务费用、人力成本等各项开支，合理规划备份预算。成本优化：通过合理选择存储介质、优化备份策略、利用开源软件等方式，降低备份成本。例如，对于长期保存的冷数据，可以选择成本较低的磁带或云归档存储；对于一些非关键数据，可以适当延长备份周期，减少备份存储量。
GTID 基本原理
格式 ：source_uuid:transaction_id，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23唯一性 ：source_uuid是服务器唯一标识符，transaction_id是事务序列号。自动追踪：主库生成 GTID，从库执行时记录已执行的 GTID，避免重复执行
GTID 优势
简化复制配置 ：无需手动指定二进制日志位置（binlog position）。自动故障转移 ：主从切换时，从库可自动识别未执行的事务。幂等性恢复：多次应用同一 GTID 的事务不会重复执行
GTID 配置
在my.cnf中启用 GTID
[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = binlog
server_id = 1 # 每个节点必须唯一基于 GTID 的恢复场景
场景 1：主从切换后恢复
# 从库执行，获取当前已执行的GTID集合
SHOW MASTER STATUS;
# 新主库设置，从指定GTID集合开始复制
CHANGE MASTER TO
MASTER_HOST='new_master_host',
MASTER_USER='repl_user',
MASTER_PASSWORD='password',
MASTER_AUTO_POSITION=1; # 使用GTID自动定位基于 GTID 的时间点恢复
# 从binlog中提取指定GTID范围的SQL
mysqlbinlog --include-gtids="3E11FA47-71CA-11E1-9E33-C80AA9429562:10-20" \
binlog.000001 | mysql -u root -p全量备份与恢复
# 创建全量备份
xtrabackup --user=root --password=password --backup --target-dir=/data/backup/full_backup_$(date +%F)
# 准备备份（应用事务日志）
xtrabackup --prepare --target-dir=/data/backup/full_backup_2025-05-12恢复命令
# 停止MySQL服务
systemctl stop mysql
# 复制备份文件到数据目录（需确保数据目录为空）
xtrabackup --copy-back --target-dir=/data/backup/full_backup_2025-05-12
# 修改权限
chown -R mysql:mysql /var/lib/mysql
# 启动MySQL
systemctl start mysql恢复命令
# 准备全量备份
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_1
# 应用第一次增量备份
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_1 --incremental-dir=/data/backup/incr_1
# 应用第二次增量备份
xtrabackup --prepare --target-dir=/data/backup/full_1 --incremental-dir=/data/backup/incr_2
# 复制恢复文件到数据目录
xtrabackup --copy-back --target-dir=/data/backup/full_1结合 GTID 与 XtraBackup 的恢复策略
在备份时记录 GTID 信息，恢复时基于 GTID 定位
# 备份时记录GTID
xtrabackup --user=root --password=password --backup --target-dir=/data/backup \
--extra-lsndir=/data/backup/lsn
# 查看备份中的GTID信息
cat /data/backup/lsn/xtrabackup_binlog_info
# 基于GTID恢复到指定点
xtrabackup --prepare --target-dir=/data/backup --to-gtid="3E11FA47-71CA-11E1-9E33-C80AA9429562:42"性能优化建议
-
并行备份 ：使用
--parallel参数加速备份xtrabackup --parallel=4 --backup --target-dir=/data/backup
压缩备份：减少存储空间占用
xtrabackup --compress --compress-threads=4 --backup --target-dir=/data/backup流式备份：直接备份到远程服务器或对象存储
xtrabackup --backup --stream=xbstream --target-dir=/data/backup | ssh user@remote "cat > /backup/backup.xbstream"格式与组成
GTID 采用source_uuid:transaction_id格式：
source_uuid ：服务器唯一标识符（server_uuid），存储在auto.cnf文件中。transaction_id：事务序列号，从 1 开始递增
3E11FA47-71CA-11E1-9E33-C80AA9429562:100GTID 集合
每个服务器维护一个GTID 集合，记录已执行的所有事务
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100,
5CE1FA47-71CA-11E1-9E33-C80AA9429563:1-50GTID 工作原理
2.1 事务生成与传播
主库 ：每个事务提交时，生成唯一 GTID 并写入 binlog。从库：复制 binlog 时，验证 GTID 是否已执行（通过 GTID 集合判断），避免重复执行。
关键系统变量
-- 查看GTID模式状态
SHOW VARIABLES LIKE 'gtid_mode'; -- ON|OFF
-- 查看GTID集合
SELECT @@GLOBAL.gtid_executed;
-- 查看当前服务器UUID
SELECT @@server_uuid;GTID 核心优势
自动故障转移
主从切换时，新主库自动知道哪些事务已执行，无需人工干预
-- 从库设置（自动定位到主库最新GTID）
CHANGE MASTER TO
MASTER_HOST='new_master',
MASTER_USER='repl',
MASTER_PASSWORD='pass',
MASTER_AUTO_POSITION=1; -- 使用GTID自动定位简化备份恢复
基于 GTID 恢复到指定时间点或事务
# 恢复到特定GTID
mysqlbinlog --include-gtids="3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100" binlog.000001 | mysql多源复制支持
轻松合并多个服务器的事务，例如主主复制或多主一从
-- 从多个主库复制（每个主库有独立的UUID）
CHANGE MASTER 'master1' TO MASTER_AUTO_POSITION=1;
CHANGE MASTER 'master2' TO MASTER_AUTO_POSITION=1;GTID 配置与启用
5.1 配置文件参数
在my.cnf中添加
[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON # 强制GTID一致性
log_bin = /var/log/mysql/binlog
server_id = 1 # 必须唯一
log_slave_updates = ON # 从库更新写入binlog现有实例升级到 GTID
# 1. 停止复制
STOP SLAVE;
# 2. 安全启用GTID（需重启）
SET GLOBAL gtid_mode = 'OFF_PERMISSIVE';
SET GLOBAL gtid_mode = 'ON_PERMISSIVE';
SET GLOBAL gtid_mode = 'ON';
SET GLOBAL enforce_gtid_consistency = ON;
# 3. 重启MySQL
systemctl restart mysql
# 4. 重置复制（使用GTID）
RESET SLAVE ALL;
CHANGE MASTER TO MASTER_AUTO_POSITION=1;
START SLAVE;XtraBackup 核心特性
在线热备份 ：备份时不阻塞数据库读写，适合生产环境。物理备份 ：直接复制数据文件（.ibd、.frm），恢复速度快。增量备份 ：仅备份自上次备份以来变化的数据页，节省时间和空间。压缩备份 ：支持多种压缩算法（如 quicklz、zlib、zstd），减少存储占用。并行备份 / 恢复 ：通过多线程提升性能。跨平台支持：支持 Linux、Windows、macOS 等。
安装 XtraBackup
以 Ubuntu/Debian
# 添加 Percona 仓库
wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
percona-release enable-only tools release
# 安装 XtraBackup 8.0（适用于 MySQL 8.0）
apt-get update
apt-get install percona-xtrabackup-80全量备份与恢复
# 创建全量备份
xtrabackup --user=root --password=password \
--backup --target-dir=/data/backup/full_$(date +%F)
# 准备备份（应用事务日志）
xtrabackup --prepare --target-dir=/data/backup/full_2025-05-12恢复命令
# 停止 MySQL 服务
systemctl stop mysql
# 复制备份文件到数据目录（需确保数据目录为空）
xtrabackup --copy-back --target-dir=/data/backup/full_2025-05-12
# 修改权限
chown -R mysql:mysql /var/lib/mysql
# 启动 MySQL
systemctl start mysql增量备份流程
# 1. 首次全量备份
xtrabackup --backup --target-dir=/data/backup/full_1
# 2. 第一次增量备份（基于 full_1）
xtrabackup --backup --incremental-basedir=/data/backup/full_1 \
--target-dir=/data/backup/incr_1
# 3. 第二次增量备份（基于 incr_1）
xtrabackup --backup --incremental-basedir=/data/backup/incr_1 \
--target-dir=/data/backup/incr_2增量恢复流程
# 1. 准备全量备份（不回滚未提交事务）
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_1
# 2. 应用第一次增量备份
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_1 \
--incremental-dir=/data/backup/incr_1
# 3. 应用第二次增量备份（最后一次无需 --apply-log-only）
xtrabackup --prepare --target-dir=/data/backup/full_1 \
--incremental-dir=/data/backup/incr_2
# 4. 复制恢复文件到数据目录
xtrabackup --copy-back --target-dir=/data/backup/full_1