Mysql 备份与还原

热备份 (联机备份) ：数据库处于运行状态，依赖于数据库的日志文件（mysqlhotcopymysqlbackup）
热备份也称为在线备份，这种备份在数据库运行（在线）状态下进行，可以提供24x7的服务，不会因为备份而影响业务的正常运行。这是一个比较复杂的过程，需要数据库的支持，并且备份过程中需要对每个数据文件申请开始和结束备份的操作，否则可能会备份到一些不一致的数据。热备份优点是可以在数据库运行过程中进行备份，备份的细粒度可以调控，对业务几乎无影响；缺点是复杂，消耗系统和数据库资源

③ 温备份

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

温备份介于冷备份和热备份之间。一般来讲，温备份是指数据库在非峰值时间进行的备份，这时数据库可能未关闭但流量较小。和冷备份与热备份相比，温备份的优点是可以供不停机的环境下用作备份，同时也不会像热备份那样对在线服务产生太大影响；但和热备份相比，它无法提供24x7的全天候备份服务。当然，实际应用中这个概念使用得较少，通常用冷备份和热备份来区分备份操作。

2.２逻辑备份

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

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

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

① 完全备份

说法一：每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时刻的数据库，是差异备份与增量备份的基础完全备份的备份与恢复操作都非常简单方便，但是数据存在大量的重复并且会占用大量的磁盘空间，备份的时间也很长

说法二：这种备份策略是最简单和最可靠的，但是需要占用大量的存储空间和时间。这种策略通常在首次备份或者数据量不大的情况下使用

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

② 差异备份

说法一：备份那些自从上次完全备份之后被修改过的所有文件，备份的时间节点是从上次完整备份起，备份数据量会越来越大。恢复数据时只需要恢复上次的完全备份与最佳的一次差异备份

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

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

③ 增量备份

说法一：只有那些在上次完全备份或者增量备份后被修改的文件才会被备份以上次完整备份或上次增量备份的时间为时间点，仅备份期间内的数据变化，因而备份的数据量小，占用空间小，备份速度快。但恢复时，需要从上一次的完整备份开始到最后一次增量备份之间的所有增量依次恢复，如中间某次的备份数据损坏，将导致数据的丢失

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

说法二：增量备份只会备份自上次备份以后的新数据。这种备份策略可以节省存储空间和时间，但是恢复数据需要所有的备份。如果有一个备份丢失或者损坏，那么可能导致无法完全恢复数据。

总结：每次增量备份都是备份在上一次完全备份或者增量备份之后的数据，不会出现重复数据的情况，也不会占用额外的磁盘空间

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

备份方式比较

备份方式	完全备份	差异备份	增量备份
完全备份时的状态	表1、表2	表1、表2	表1、表2
第1次添加内容	创建表3	创建表3	创建表3
备份内容	表1、表2、表3	表3	表3
第2次添加内容	创建表4	创建表4	创建表4
备份内容	表1、表2、表3、表4	表3、表4	表4

逻辑备份的策略（增、全、差异）

如何选择逻辑备份策略（频率）

合理值区间 ⭐⭐⭐

一周一次的全备，全备的时间需要在不提供业务的时间区间进行 PM 10点 AM 5:00之间进行全备

增量：3天/2天/1天一次增量备份

差异：选择特定的场景进行备份

一个处理（NFS）提供额外空间给与mysql 服务器用

三、常见的备份方法

3.1 物理冷备

备份时数据库处于关闭状态，直接打包数据库文件（tar）
备份速度快，恢复时也是最简单的

3.2 专用备份工具 mysqldump 或 mysqlhotcopy

mysqldump（温备份）：
mysqlhotcopy（仅MyISAM引擎和 ARCHIVE 表）

3.3 二进制日志增量备份

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

-- 启用二进制日志
[mysqld]
log-bin=/var/log/mysql/mysql-bin.log

MySQL支持增量备份，进行增量备份时必须启用二进制日志。

二进制日志文件支持数据库复制功能，记录备份时间点后的所有数据变更信息，便于恢复操作。执行增量备份（包含上次完整或增量备份后的数据修改）时，必须刷新二进制日志。

3.4 第三方工具

Percona XtraBackup mysqlbackup：开源热备工具
MySQL Enterprise Backup：官方企业级方案

四、MySQL完全备份

4.1 核心特点

是对整个数据库、数据库结构和文件结构的备份
保存的是备份完成时刻的数据库
是差异备份与增量备份的基础

4.2 优缺点分析

优点	缺点
恢复操作简单	占用大量磁盘空间
无需复杂依赖	备份和恢复时间长
数据完整性高	重复数据多

五、数据库完全备份分类

5.1 物理冷备份与恢复

1、关闭MySQL数据库
2、使用tar命令直接打包数据库文件夹
3、直接替换现有MySQL目录即可

5.2 mysqldump备份与恢复

1、MySQL自带的备份工具，可方便实现对MySQL的备份
2、可以将指定的库、表导出为SQL 脚本
3、使用命令mysq|导入备份的数据

六、实战案例

6.1 环境准备

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');

6.2 完全备份与恢复

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

6.2.1 物理冷备恢复

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_2026-08-04.tar.gz -C /usr/local/mysql/

6.2.2 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] szsxjd info1 info2 > /opt/szsxjd_info1_info2.sql
#使用“-d”选项，说明只保存数据库的表结构 
#不使用“-d"选项，说明表数据也进行备份
#做为一个表结构模板

(4)查看备份文件
grep -v "^--" /opt/szsxjd_info1_info2.sql | grep -v "^/" | grep -v "^$"
grep -v "^--" /opt/szsxjd_info1_info2_d.sql | grep -v "^/" | grep -v "^$"

6.2.3 Mysql 完全恢复

#恢复数据库
1.使用mysqldump导出的文件，可使用导入的方法
source命令
mysql命令
2.使用source恢复数据库的步骤
登录到MySQL数据库
执行source备份sql脚本的路径
3.source恢复的示例
MySQL [(none)]> source /backup/all-data.sql

使用source命令恢复数据：

1.模拟数据库出现问题
mysql -uroot -p登录数据库
mysql> show databases;  查看数据库信息

应用示例：

创建备份(对表进行备份)
mysqldump -uroot -p szsxjd info1 > /opt/info1.sql  
mysql -uroot -p -e 'drop table szsxjd.info1;'  #删除数据库的表
mysql -uroot -p 登录数据库查看

恢复数据表：

> source /opt/info1.sql  
查看表信息
mysql> show tables in szsxjd;
或者免交互方式：
mysql -uroot -p123456 -e 'show tables in szsxjd;'

方式二：

mysql -uroot -p szsxjd < /opt/info1.sql   #恢复info1表
mysql -uroot -p -e 'show tables in szsxjd;'  #查看info1表

PS:mysqldump 严格来说属于温备份，会需要对表进行写入的锁定
在全量备份与恢复中，假设现有szsxjd库，szsxjd库中有一个info1表，需要注意：
①当备份时加 -- databases ,表示针对于szsxjd库

#备份命令
mysqldump -uroot -p123456--databases szsxjd > /opt/szsxjd_01_all.sql 备份库后
#恢复命令过程为：
mysql -uroot -p123456
drop database  szsxjd ;
exit
mysql -uroot -p123456 < /opt/szsxjd_01_all.sql

② 当备份时不加 --databases，表示针对szsxjd库下的所有表

#备份命令
mysqldump -uroot -p123456 szsxjd > /opt/szsxjd_02_all.sql
#恢复过程：
mysql -uroot -p123456
drop database szsxjd;
create database szsxjd;      # 手动创建库
exit
mysql -uroot -p123456 szsxjd < /opt/szsxjd_02_all.sql 
#查看szsxjd_01.sql 和szsxjd_02.sql
主要原因在于两种方式的备份（前者会从"create databases"开始,而后者则全是针对表格进行操作）

在生产环境中，可以使用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

6.3 MySQL 增量备份与恢复

6.3.1 MySQL数据库增量恢复类型

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

数据库在某一时间点可能既有错误的操作也有正确的操作
可以基于精准的位置跳过错误的操作
发生错误节点之前的一个节点，上一次正确操作的位置点停止

基于时间点恢复

跳过某个发生错误的时间点实现数据恢复
在错误时间点停止，在下一个正确时间点开始

6.3.2 MySQL 增量备份

6.3.2.1 开启二进制日志功能

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()以及用户自定义函数(UDF)时，或在主从复制等架构中记录日志时会出现问题。
总结：通过SQL语句执行增删改查操作时，在高并发场景下可能出现错误。由于时间差异或延迟的影响，实际执行顺序可能与预期不符，比如删除操作可能先于修改操作执行，导致数据准确性降低。
② ROW(基于行)
仅记录发生变动的数据行，不保存 SQL 语句的上下文信息。
缺点:日志量过大，若执行类似 UPDATE...SET...WHERE TRUE 这类全表更新操作，会导致 binlog 文件体积持续增长。
总结：针对 UPDATE、DELETE 等多行操作，仅记录实际变动的数据行，不记录sql的上下文环境。比如sql语句记录一行，但是ROW就可能记录10行，记录精度高。高并发场景下由于写入量大，可能影响性能
③ MIXED 推荐使用
一般的语句使用statement，函数使用ROW方式存储。

2、重启数据库

# 重启数据库
systemctl restart mysqld

3、查看二进制日志文件的内容

cp /usr/local/mysql/data/mysql-bin.000001 /opt/
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000001
二进制日志中需要关注的部分：
at ：开始的位置点
end_log_pos：结束的位置
时间戳： 250916 18:48:25
SQL语句

--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.000001 > /opt/mysql-bin.000001.txt

6.3.2.2 进行完全备份

增量备份时基于完全备份的，所以我们直接完全备份数据库

mysqldump -uroot -p szsxjd info1 > /opt/szsxjd_info1_$(date +%F).sql
mysqldump -uroot -p szsxjd > /opt/szsxjd_all_$(date +%F).sql

6.3.2.3 可每天进行增量备份操作

可每天进行增量备份操作，生成新的二进制日志文件(例如:mysql-bin.000002)

mysqladmin -u root -p flush-logs

6.3.2.4 插入新数据，以模拟数据的增加或变更

PS:在第一次完全备份之后刷新二进制文件，在第二个二进制文件中记载着"增量备份的数据"

mysql> create database yjs0805;
mysql> use yjs0805;
mysql> create table test1 (id int(4),name varchar(4));
mysql> insert into test1 values(1,'one');
mysql> insert into test1 values(2,'two');
mysql> select * from test1;

6.3.2.5 再次生成新的二进制日志文件

mysqladmin -u root -p flush-logs
#之前的步骤4的数据库操作会保存到mysql-bin.000002文件中
#之后我们测试删除szsxjd库的操作会保存在mysql-bin.000003文件中
#（以免当我们基于mysql-bin.000002日志进行恢复时，依然会删除库）

6.3.3 MySQL增量恢复

6.3.3.1 一般恢复

模拟丢失所有数据的恢复步骤：

#模拟丢失所有数据
mysql -uroot -p
mysql> show databases;
mysql> drop database yjs0805;
mysql> exit

# 基于mysql-bin.000002恢复
# 备份日志文件
cp /usr/local/mysql/data/mysql-bin.000002 /opt/
#查看日志文件
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002
# 使用日志文件进行一般恢复
mysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -u root -p

6.3.3.2 基于位置恢复

① 插入三条数据

mysql> use yjs0805;
mysql> select * from test1;
mysql> insert into test1 values(3,'true');
mysql> insert into test1 values(4,'f');
mysql> insert into test1 values(5,'t');
mysql> select * from test1;

例如：有一个需求test1表中id =3的开始的数据操作失误，需要跳过，应该如何操作？
② 确认位置点，刷新二进制日志并删除test1表

cp /usr/local/mysql/data/mysql-bin.000003 /opt/
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000003
例如：
at 1417
#250916 19:30:04
insert into test1 values(3,'true')
at 1712
#250916 19:30:09
insert into test1 values(4,'f')
#刷新日志
mysqladmin -uroot -p flush-logs
删除test1表
mysql> use yjs0805;
mysql> show tables;
mysql> drop table yjs0805.test1;

③ 基于位置点恢复

#仅恢复到操作 ID 为“1417"之前的数据，即不恢复从"user3"开始的数据
mysqlbinlog --no-defaults --stop-position='1417' /opt/mysql-bin.000003 | mysql -uroot -p

#恢复从"user4"开始的的数据，跳过"user3"的数据恢复
mysqlbinlog --no-defaults --start-position='1712' /opt/mysql-bin.000003 | mysql -uroot -p

#恢复从位置为1417开始到位置为1712为止，仅恢复user3
mysqlbinlog --no-defaults --start-position='1417' --stop-position='1712' /opt/mysql-bin.000003 | mysql -uroot -p

6.3.3.3 基于时间点恢复

和基于位置的恢复很类似：

mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小时:分钟:秒' --stop-datetime='年-月-日小时:分钟:秒' 二进制日志 | mysql -u 用户名 -p 密码

# 先删除test1表
drop table yjs0805.test1;

#仅恢复到16:41:24 之前的数据，即不恢复"user3"开始的数据
mysqlbinlog --no-defaults --stop-datetime='2025-09-16 19:30:04' /opt/mysql-bin.000003 | mysql -uroot -p

#仅恢复"user4"开始的数据，跳过"user3"的数据恢复
mysqlbinlog --no-defaults --start-datetime='2025-09-16 19:30:09' /opt/mysql-bin.000003 | mysql -uroot -p

mysqlbinlog --no-defaults --start-datetime='2025-09-16 19:30:04' --stop-datetime='2025-09-16 19:30:09'/opt/mysql-bin.000003 | mysql -uroot -p

七、总结

本文系统性地介绍了 MySQL 数据库备份与恢复的核心知识体系，涵盖了从基础概念到实战操作的完整流程。

7.1 核心要点回顾

备份的重要性：数据是企业的核心资产，备份是应对程序错误、人为失误、硬件故障及自然灾害等数据丢失风险的最后防线。
备份类型：主要分为物理备份（冷、热、温备份）和逻辑备份，以及从策略上划分的完全备份、差异备份和增量备份。
备份方法：包括物理冷备、mysqldump/mysqlhotcopy 工具、二进制日志增量备份以及第三方专业工具（如 Percona XtraBackup）。

7.2 实战操作总结

通过实战案例，我们掌握了以下关键操作：

完全备份与恢复：使用 mysqldump 进行逻辑备份，并通过 source 命令或重定向输入进行恢复。物理冷备则通过打包数据库文件实现。
增量备份与恢复：关键在于开启并利用二进制日志（binlog）。
- 一般恢复：应用所有二进制日志。
- 基于位置恢复：通过 --stop-position 和 --start-position 参数精确跳过错误操作。
- 基于时间点恢复：通过 --stop-datetime 和 --start-datetime 参数在特定时间点进行恢复。