Mysql 备份与还原

前言

好的，这是一份关于MySQL备份与还原的"前言"或概述。它旨在阐明备份的重要性、核心概念和基本框架，为深入学习和实施打下基础。

---

MySQL备份与还原：守护数据的生命线

前言

在数字时代的浪潮中，数据已成为企业最核心的资产之一。对于绝大多数业务系统而言，数据库扮演着"心脏"的角色，存储着用户信息、交易记录、产品资料等不可再生的关键数据。MySQL，作为全球最流行的开源关系型数据库，承载着无数网站、应用和服务的稳定运行。

然而，运行环境充满不确定性：

• 硬件故障：磁盘损坏、服务器宕机。
• 人为失误 ：误删除数据、误执行DROP TABLE或UPDATE语句。
• 软件缺陷：数据库或应用本身的Bug导致数据损坏。
• 恶意攻击：勒索病毒、黑客入侵篡改数据。
• 自然灾害：火灾、洪水、断电等不可抗力。

没有任何系统是100%可靠的。 一旦数据丢失或损坏，其带来的业务停滞、品牌信誉损失乃至法律风险，往往是灾难性的，甚至可能是致命的。

正是在这样的背景下，备份与还原 从一项普通的技术任务，升华为数据管理的基石和最后的安全防线 。它的核心目标非常简单却至关重要：在灾难发生时，能够以可接受的代价（时间、数据丢失量），将业务恢复并运行起来。

备份 ≠ 高可用，还原才是真正的考验。 许多人误以为使用了主从复制、集群等高可用架构就无需备份。事实上，复制解决的是"可用性"问题（服务不中断），而备份解决的是"数据恢复"问题。逻辑错误或恶意删除会瞬间同步到所有副本，此时只有备份才能拯救数据。因此，一个经典的准则是："任何没有经过完整恢复验证的备份，都是不可信任的。"

关于本指南的范畴：

本文将系统性地介绍MySQL备份与还原的核心概念、策略、主流工具及最佳实践。我们将探讨：

• 备份的两种灵魂 ：逻辑备份 （如mysqldump，生成SQL语句）与物理备份（如Percona XtraBackup，复制数据文件）的优劣与适用场景。
• 备份策略的黄金法则 ：如何结合全量备份 、增量备份 与差异备份，在恢复时间目标与存储成本之间取得平衡。
• 关键工具解析 ：从官方工具mysqldump、mysqlpump到企业级工具Percona XtraBackup，以及快照备份、导出导入工具的使用。
• 还原实战：一步步演示在不同灾难场景下的恢复流程，这是检验备份有效性的唯一标准。
• 自动化与监控：如何让备份任务自动、可靠地运行，并及时获知失败告警。
• 云环境下的新思考：当数据库部署在云上时，备份策略有何不同。

无论您是初涉数据库管理的开发者，还是负责核心系统的运维工程师，理解并掌握MySQL备份与还原，不仅是一项必备技能，更是一份对业务数据持续性的庄严承诺。

让我们开始这趟构筑数据"诺亚方舟"的旅程。记住，在数据的世界里，未雨绸缪远胜于亡羊补牢。

Mysql 备份与还原

数据备份的重要性

1、备份的主要目的是灾难恢复

2、在生产环境中，数据的安全性至关重要

3、任何数据的丢失都可能产生严重的后果

4、造成数据丢失的原因

程序错误

人为操作错误

运算错误

磁盘故障

灾难 (如火灾、地震) 和盗窃

数据库备份类型

物理备份

数据库备份可以分为物理备份和逻辑备份。物理备份是对数据库操作系统的物理文件（如数据文件、日

志文件等）的备份。这种类型的备份适用于在出现问题的时候需要快速恢复的大型重要数据库。

物理备份又可以成为冷备份（脱机备份）、热备份（连接备份）和温备份

① 冷备份 (脱机备份)

冷备份 (脱机备份) ：是在关闭数据库的时候进行的（tar）

冷备份也被称为脱机备份，它是指在数据库关闭的情况下进行的备份操作，因此也被称为全备份。这种

备份方式的优点是简单全面且无需额外资源，但劣势就是必须在数据库脱机的情况下进行，这在生产环

境中往往是无法接受的。

② 热备份 (联机备份)

热备份 (联机备份) ：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopy mysqlbackup）

热备份也称为在线备份，这种备份在数据库运行（在线）状态下进行，可以提供24x7的服务，不会因为

备份而影响业务的正常运行。这是一个比较复杂的过程，需要数据库的支持，并且备份过程中需要对每

个数据文件申请开始和结束备份的操作，否则可能会备份到一些不一致的数据。热备份优点是可以在数

据库运行过程中进行备份，备份的细粒度可以调控，对业务几乎无影响；缺点是复杂，消耗系统和数据

库资源

③ 温备份

温备份 ：数据库锁定表格(不可写入但可读)的状态下进行备份操作（mysqldump）

温备份介于冷备份和热备份之间。一般来讲，温备份是指数据库在非峰值时间进行的备份，这时数据库

可能未关闭但流量较小。和冷备份与热备份相比，温备份的优点是可以供不停机的环境下用作备份，同

时也不会像热备份那样对在线服务产生太大影响；但和热备份相比，它无法提供24x7的全天候备份服

务。当然，实际应用中这个概念使用得较少，通常用冷备份和热备份来区分备份操作。

逻辑备份

逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构

这种类型的备份适用于可以编辑数据值或表结构

从数据库的备份策略角度来看，备份又可分为完全 备份、差异备份和增量备份

① 完全备份

说法一：每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完

成时刻的数据库，是差异备份与增量备份的基础完全备份的备份与恢复操作都非常简单方便，但是数据

存在大量的重复并且会占用大量的磁盘空间，备份的时间也很长

说法二：这种备份策略是最简单和最可靠的，但是需要占用大量的存储空间和时间。这种策略通常在首

次备份或者数据量不大的情况下使用

总结：每次都进行完全备份，会导致备份文件占用空间巨大，并且有大量的重复数据； 恢复时，直接使

用完全备份的文件即可

② 差异备份

说法一：备份那些自从上次完全备份之后被修改过的所有文件，备份的时间节点是从上次完整备份起，

备份数据量会越来越大。恢复数据时只需要恢复上次的完全备份与最佳的一次差异备份

说法二：差异备份备份自上次全量备份以后的新数据。这种备份策略在存储空间和恢复时间上的需求介

于全量备份和增量备份之间。

总结：每次差异备份，都会备份上一次完全备份之后的数据，可能会出现重复数据。；恢复时，先恢复

完全备份的数据，再恢复差异备份的数据

③ 增量备份

说法一：只有那些在上次完全备份或者增量备份后被修改的文件才会被备份以上次完整备份或上次增量

备份的时间为时间点，仅备份期间内的数据变化，因而备份的数据量小，占用空间小，备份速度快。但

恢复时，需要从上一次的完整备份开始到最后一次增量备份之间的所有增量依次恢复，如中间某次的备

份数据损坏，将导致数据的丢失

每次增量备份都是在备份在上一次完成全备份

说法二：增量备份只会备份自上次备份以后的新数据。这种备份策略可以节省存储空间和时间，但是恢

复数据需要所有的备份。如果有一个备份丢失或者损坏，那么可能导致无法完全恢复数据。

总结：每次增量备份都是备份在上一次完全备份或者增量备份之后的数据，不会出现重复数据的情况，

也不会占用额外的磁盘空间

恢复数据，需要按照次序恢复完全备份和增量备份的数据

备份方式比较

常见的备份方法

物理冷备

备份时数据库处于关闭状态，直接打包数据库文件（tar）

备份速度快，恢复时也是最简单的

专用备份工具 mysqldump 或 mysqlhotcopy

mysqldump 常用的逻辑备份工具

mysqlhotcopy 仅拥有备份 MyISAM 和 ARCHIVE 表

启用二进制日志进行增量备份

进行增量备份，需要刷新二进制日志

MySQL支持增量备份，进行增量备份时必须启用二进制日志。二进制日志文件为用户提供复制，对执行

备份点后进行的数据库更改所需的信息进行恢复。如果进行增量备份（包含自上次完全备份或增量备份

以来发生的数据修改），需要刷新二进制日志。

第三方工具备份

免费的MySQL 热备份软件 Percona XtraBackup mysqlbackup

MySQL完全备份

是对整个数据库、数据库结构和文件结构的备份

保存的是备份完成时刻的数据库

是差异备份与增量备份的基础

MySQL完全备份优缺点

1. 优点：

   备份与恢复操作简单方便

2. 缺点：

   数据存在大量的重复

   占用大量的备份空间

   备份与恢复时间长

数据库完全备份分类

物理冷备份与恢复

关闭MySQL数据库

使用tar命令直接打包数据库文件夹

直接替换现有MySQL目录即可

mysqldump备份与恢复

MySQL自带的备份工具，可方便实现对MySQL的备份

可以将指定的库、表导出为SQL 脚本

使用命令mysq|导入备份的数据

实战案列

环境准备

create database szsxjd
use szsxjd;
create table if not exists info1 (
id int(4) not null auto_increment,
name varchar(10) not null,
age char(10) not null,
hobby varchar(50),
primary key (id));
insert into info1 values(1,'user1',20,'running');
insert into info1 values(2,'user2',30,'singing');

MySQL完全备份与恢复

InnoDB 存储引擎的数据库在磁盘上存储成三个文件: db.opt(表属性文件)、表名.frm(表结构文件)、表

名.ibd(表数据文件)。

物理冷备份与恢复

systemctl stop mysqld

#压缩备份

tar zcvPf /opt/mysql_all_$(date +%F).tar.gz /usr/local/mysql/data/

mv /usr/local/mysql/data/ /opt/

#解压恢复

tar zxvPf /opt/mysql_all_2025-09-15.tar.gz -C /usr/local/mysql/

mysqldump 备份（温备份）

create table info2 (id int,name char(10),age int,sex char(4));
insert into info2 values(1,'user',11,'性别');
insert into info2 values(2,'user',11,'性别');

(1)、完全备份一个或多个完整的库 (包括其中所有的表)

mysqldump -u root -p[密码] --databases 库名1 [库名2] ... > /备份路径/备份文件名.sql    

#导出的就是数据库脚本文件

例:

mysqldump -u root -p --databases szsxjd > /opt/szsxjd.sql       #备份一个szsxjd库 

结构和数据

mysqldump -u root -p --databases mysql szsxjd > /opt/mysql-szsxjd.sql    #备份

mysql与szsxjd两个库结构和数据

(2)、完全备份 MySQL 服务器中所有的库

mysqldump -u root -p[密码] --all-databases > /备份路径/备份文件名.sql

例:

mysqldump -u root -p --all-databases > /opt/all.sql

(3)、完全备份指定库中的部分表

mysqldump -u root -p[密码] 库名 [表名1] [表名2] ... > /备份路径/备份文件名.sql

例:

mysqldump -u root -p [-d] kgc info1 info2 > /opt/szsxjd_info1.sql

#使用"-d"选项，说明只保存数据库的表结构

#不使用"-d"选项，说明表数据也进行备份

#做为一个表结构模板

(4)查看备份文件

grep -v "^--" /opt/szsxjd_info1-2.sql | grep -v "^/" | grep -v "^$"

Mysql 完全恢复

#恢复数据库
1.使用mysqldump导出的文件，可使用导入的方法
source命令
mysql命令
2.使用source恢复数据库的步骤
登录到MySQL数据库
执行source备份sql脚本的路径
3.source恢复的示例
MySQL [(none)]> source /backup/all-data.sql
================================================================================
======
使用source命令恢复数据
1.模拟数据库出现问题
[root@server1 backup]# mysql -uroot -pabc123 登录数据库
mysql> show databases;  查看数据库信息
应用示例：
创建备份(对表进行备份)
[root@server1 ~]# mysqldump -uroot -p123456 szsxjd info1 > /opt/info1.sql  
[root@server1 ~]# mysql -uroot -pabc123 登录数据库查看
[root@server1 ~]# mysql -uroot -p123456 -e 'drop table szsxjd.info1;'  #删除数据库
的表
恢复数据表
mysq 
mysql> select * from info1;  查询所有字段
mysql> show tables; 查看表信息
或免交互l> source /opt/info1.sql  
mysql -uroot -p123456 -e 'show tables from szsxjd;'

方式二：

[root@mysql abc]# mysql -uroot -p123456 szsxjd < /opt/info1.sql   #恢复info1表
[root@mysql abc]# mysql -uroot -p123456 -e 'show tables from szsxjd;'  #查看info1
表
PS:mysqldump 严格来说属于温备份，会需要对表进行写入的锁定
在全量备份与恢复实验中，假设现有0805yjs（szsxjd）库，0805yjs（szsxjd）库中有一个test表，需
要注意的一点为：
① 当备份时加 --databases ,表示针对于0805yjs（szsxjd）库
#备份命令
mysqldump -uroot -p123456--databases szsxjd > /opt/szsxjd_01-all.sql 备份库后
#恢复命令过程为：
mysql -uroot -p123456
drop database  szsxjd ;
exit
mysql -uroot -p123456 < /opt/szsxjd_01.sql
② 当备份时不加 --databases，表示针对szsxjd库下的所有表
#备份命令
mysqldump -uroot -p123456 szsxjd > /opt/szsxjd_all.sql
#恢复过程：
mysql -uroot -p123456
drop database szsxjd;
create database szsxjd;
exit
mysql -uroot -p123456 szsxjd < /opt/szsxjd_02.sql 
#查看szsxjd_01.sql 和szsxjd_02.sql 
主要原因在于两种方式的备份（前者会从"create databases"开始,而后者则全是针对表格进行操作）
4.在生产环境中，可以使用Shell脚本自动实现定时备份（时间频率需要确认）
0 1 * * 6 /usr/local/mysql/bin/mysqldump -uroot -p123456 szsxjd info1 > 
./szsxjd_infol_$(date +%Y%m%d).sql ;/usr/local/mysql/bin/mysqladmin -u root -p 
flush-logs

MySQL 增量备份与恢复

MySQL数据库增量恢复

一般恢复: 将所有备份的二进制日志内容全部恢复

2.基于位置恢复

数据库在某一时间点可能既有错误的操作也有正确的操作

可以基于精准的位置跳过错误的操作

发生错误节点之前的一个节点，上一次正确操作的位置点停止

3.基于时间点恢复

跳过某个发生错误的时间点实现数据恢复

在错误时间点停止，在下一个正确时间点开始

MySQL 增量备份

增备实验

1.开启二进制日志功能

vim /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED      #可选，指定二进制日志(binlog)的记录格式为MIXED（混合输入）
server-id = 1              #可加可不加该命令
#二进制日志(binlog)有3种不同的记录格式: STATEMENT (基于SQL语句)、ROW(基于行)、MIXED(混合
模式)，默认格式是STATEMENT
① STATEMENT（基于SQL语句）:
每一条涉及到被修改的sql 都会记录在binlog中
缺点：日志量过大，如sleep()函数，last_insert_id()>，以及user-defined fuctions（udf）、
主从复制等架构记录日志时会出现问题
总结：增删改查通过sql语句来实现记录，如果用高并发可能会出错，可能时间差异或者延迟，可能不是我们
想想的恢复可能你先删除或者在修改，可能会倒过来。准确率底
② ROW(基于行)
只记录变动的记录，不记录sql的上下文环境
缺点:如果遇到update......set....where true 那么binlog的数据量会越来越大
总结：update、delete以多行数据起作用，来用行记录下来，只记录变动的记录，不记录sql的上下文环境，
比如sql语句记录一行，但是ROW就可能记录10行，但是准确性高，高并发的时候由于操作量，性能变低 比较
大所以记录都记下来，
③ MIXED 推荐使用
一般的语句使用statement，函数使用ROW方式存储。
systemctl restart mysqld 
================================================================================
=====================
mysql  增量备份 STATEMENT与ROW 通俗解释
 
在MySQL中，增量备份是指只备份发生变化的数据，而不是整个数据库。在增量备份中，可以使用基于语句
（Statement）或基于行（Row）的方式来记录和复制这些变化。
基于语句的增量备份（Statement-Based Incremental Backup）：
    通俗解释：就像记录每一步操作一样，基于语句的增量备份会记录每个SQL语句的变化，而不是具体的数
据行。当备份时，只需要记录执行过的SQL语句，而不是具体的数据内容。
    适用场景：适用于简单的SQL语句操作，如INSERT、UPDATE、DELETE等，可以通过记录SQL语句来还
原数据变化。
基于行的增量备份（Row-Based Incremental Backup）：
    通俗解释：就像记录每个人的变化一样，基于行的增量备份会记录每个数据行的变化情况，而不是SQL语
句。当备份时，只需要记录哪些数据行发生了变化，而不是具体的SQL语句。
    适用场景：适用于复杂的数据变化情况，如涉及多个表之间关联的操作，可以通过记录数据行的变化来还
原数据。
在增量备份中，选择基于语句或基于行的方式取决于您对数据变化的关注点和备份恢复的需求。基于语句的增
量备份更注重SQL操作的记录，而基于行的增量备份更注重数据行的变化情况。根据具体情况选择合适的备份
方式可以更有效地保护和恢复数据。
================================================================================
=====================
查看二进制日志文件的内容
cp /usr/local/mysql/data/mysql-bin.000001 /opt/
① mysqlbinlog --no-defaults  /opt/mysql-bin.000001
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000001
#--base64-output=decode-rows：使用64位编码机制去解码（decode）并按行读取（rows）
#-v: 显示详细内容
#--no-defaults : 默认字符集（不加会报UTF-8的错误）
PS: 可以将解码后的文件导出为txt格式，方便查阅
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002 > 
/opt/mysql-bin.000002
例如，STATEMENT模式记录量较少，但有可能会因为没有记录下所有细节而产生问题；ROW模式可以记录下所
有细节，但是记录量可能会非常大。所以在实际使用中需要根据情况选择适合的模式。

二进制日志中需要关注的部分

1、at ：开始的位置点

2、end_log_pos：结束的位置

3、时间戳： 210712 11:50:30

4、SQL语句

2.进行完全备份(增量备份时基于完全备份的，所以我们直接完全备份数据库)

[root@mysql data]# mysqldump -uroot -p123456 szsxjd info1 > 
/opt/szsxjd_info1_$(date +%F).sql
[root@mysql data]# mysqldump -uroot -p123456 szsxjd > /opt/szsxjd_all_$(date 
+%F).sql
3.可每天进行增量备份操作，生成新的二进制日志文件(例如:mysql-bin.000002)
mysqladmin -u root -p flush-logs
4.插入新数据，以模拟数据的增加或变更
PS:在第一次完全备份之后刷新二进制文件，在第二个二进制文件中记载着"增量备份的数据"
mysql> create database yjs0805;
Query OK, 1 row affected (0.00 sec)
mysql> use yjs0805;
Database changed
mysql> create table test1 (id int(4),name varchar(4));
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test1 values(1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(2,'two');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test1;
+------+------+
| id   | name |
+------+------+
|    1 | one  |
|    2 | two  |
+------+------+
2 rows in set (0.00 sec)
5.再次生成新的二进制日志文件(例如:mysql-bin.000003)
mysqladmin -u root -p flush-logs
#之前的步骤4的数据库操作会保存到mysql-bin.000002文件中，之后我们测试删除szsxjd库的操作会保存
在mysql-bin.000003文件中 （以免当我们基于mysql-bin.000002日志进行恢复时，依然会删除库）

MySQL增量恢复

1. 一般恢复

(1)、模拟丢失更改的数据的恢复步骤（直接使用恢复即可）
① 备份yjs0805库中test1表
mysqldump -uroot -p123456 yjs0805 test1 > /opt/yjs0805_test0805.sql
② 删除yjs0805库中test1表
drop table yjs0805.test1;
③ 恢复test1表
mysql -uroot -p yjs0805 < yjs0805_test0805.sql
#查看日志文件
[root@mysql data]# mysqlbinlog --no-defaults --base64-output=decode-rows -v 
mysql-bin.000002
(2)、模拟丢失所有数据的恢复步骤
① 模拟丢失所有数据
[root@mysql data]# mysql -uroot -p123456
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| szsxjd             |
| yjs0805            |
+--------------------+
7 rows in set (0.00 sec)
mysql> drop database yjs0805;
Query OK, 1 row affected (0.00 sec)
mysql> exit
② 基于mysql-bin.000002恢复
mysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -u root -p

2. 断点恢复

mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
例:
at 302
#201122 16:41:16
插入了"user3"的用户数据
at 623
#201122 16:41:24 
插入了"user4"的用户数据
(1)、基于位置恢复
① 插入三条数据
mysql> use yjs0805;
mysql> select * from test1;
+------+------+
| id   | name |
+------+------+
|    1 | one  |
|    2 | two  |
+------+------+
2 rows in set (0.00 sec)
mysql> insert into test1 values(3,'true');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(4,'f');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test1 values(5,'t');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test1;
+------+------+
| id   | name |
+------+------+
|    1 | one  |
|    2 | two  |
|    3 | true |
|    4 | f    |
|    5 | t    |
+------+------+
5 rows in set (0.00 sec)
#需求：以上id =4的数据操作失误，需要跳过
② 确认位置点，刷新二进制日志并删除test1表
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000003
960 停止 
1066 开始
#刷新日志
mysqladmin -uroot -p123456 flush-logs
mysql> use yjs0805;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_yjs0805 |
+----------------+
| test1          |
+----------------+
1 row in set (0.00 sec)
mysql> drop table yjs0805.test1;
Query OK, 0 rows affected (0.00 sec)
③ 基于位置点恢复
#仅恢复到操作 ID 为"623"之前的数据，即不恢复"user4"的数据
mysqlbinlog --no-defaults --stop-position='623' /opt/mysql-bin.000003 | mysql -
uroot -p
#仅恢复"user4"的数据，跳过"user3"的数据恢复
mysqlbinlog --no-defaults --start-position='623' /opt/mysql-bin.000003 | mysql -
uroot -p
mysqlbinlog --no-defaults --start-position='400' --stop-position='623' 
/opt/mysql-bin.000002 | mysql -uroot -p      #恢复从位置为400开始到位置为623为止
(2)、基于时间点恢复
mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时:分钟:秒' --stop-
datetime='年-月-日小时:分钟:秒' 二进制日志 | mysql -u 用户名 -p 密码
#仅恢复到16:41:24 之前的数据，即不恢复"user4"的数据
mysqlbinlog --no-defaults --stop-datetime='2025-09-16 0:52:12' /opt/mysql-
bin.000003 | mysql -uroot -p 
#仅恢复"user4"的数据，跳过"user3"的数据恢复
mysqlbinlog --no-defaults --start-datetime='2025-09-16 0:52:12' /opt/mysql-
bin.000003 | mysql -uroot -p
mysqlbinlog --no-defaults --start-datetime='2025-09-16 0:52:12' --stop-
datetime='2025-09-16 0:52:27' /home/mysql-bin.000003 | mysql -uroot -p
如果恢复某条SQL语之前的所有数据，就stop在这个语句的位置节点或者时间点
如果恢复某条SQL语句以及之后的所有数据，就从这个语句的位置节点或者时间点start

总结

简单口诀：定期备份要记牢，多种方式结合好，恢复测试不能少，异地保存更可靠。