3、系统备份与快照：备份的重要性、创建系统快照、从快照恢复

各位好，我是老张。今天咱们聊聊备份和快照。

说实话，干运维这么多年，我最怕听到的一句话就是：「哎呀，刚才手滑了，数据没了。」

嗯，每次听到这种话，我心里就咯噔一下。因为我知道，接下来大概率是一场硬仗。所以，备份这件事，我把它排在升级恢复操作里的第三位，不是因为它不重要，而是因为它太重要了，重要到应该成为你的肌肉记忆。

3.1 备份的重要性：别等丢了才后悔

先讲个我自己的教训。

几年前，我负责一个电商平台的数据库。有一次做版本升级，我自认为准备充分，直接在生产环境上跑脚本。结果呢？一个参数写错了，导致表结构被破坏。当时我冷汗就下来了——因为那天是双十一大促的前一天。

幸好，我前一天刚手动打了一个快照。恢复只用了8分钟。业务影响控制在极小范围内。

你想想看，如果没有那个快照，会是什么后果？数据恢复可能需要几小时甚至几天，业务损失可能上百万。所以，备份不是「可选项」，而是「必选项」。

我个人习惯把备份分成三类：

说白了，全量备份是「底牌」，增量备份是「日常」，快照是「应急王牌」。三者配合使用，才能做到万无一失。

3.2 创建系统快照：手把手教你打一张「安全牌」

快照是什么？你可以把它理解成系统在某个时刻的「照片」。它记录了磁盘上所有数据的状态，包括文件系统、数据库、配置等等。

创建快照的时机，我建议遵循「三前原则」：

• 升级前：不管是大版本升级还是小补丁，先打快照
• 配置变更前：改防火墙规则、改内核参数、改数据库配置，先打快照
• 数据操作前：删表、清日志、迁移数据，先打快照

我曾经遇到过一位同事，升级前嫌麻烦没打快照，结果升级脚本有bug，系统直接起不来了。最后花了整整一天手动恢复。从那以后，他每次操作前都会念叨一句：「快照打了没？」

好，咱们看看具体怎么打快照。以 Linux 系统为例，使用 LVM 快照功能：

# 1. 查看当前卷组和逻辑卷
lvdisplay

# 2. 创建快照（假设卷组名为 vg_data，逻辑卷名为 lv_root）
lvcreate -L 10G -s -n snap_root_before_upgrade /dev/vg_data/lv_root

# 3. 确认快照已创建
lvs | grep snap

这里要注意：快照的大小要合理。太小了，如果数据变化量大，快照会撑爆；太大了，浪费空间。我个人习惯给快照分配原卷大小的 10%-20%。

3.3 从快照恢复：关键时刻的救命稻草

好，假设最坏的情况发生了——升级中断，系统起不来了。这时候，快照就是你最后的救命稻草。

恢复流程其实不复杂，但有几个关键点必须注意：

1. 先停止所有对原卷的写操作：避免数据进一步损坏
2. 卸载原卷：如果原卷正在使用，先 umount
3. 合并快照：将快照数据写回原卷
4. 重新挂载并启动服务

具体命令如下：

# 1. 停止服务
systemctl stop nginx mysql

# 2. 卸载原卷
umount /dev/vg_data/lv_root

# 3. 合并快照（注意：合并后快照会自动删除）
lvconvert --merge /dev/vg_data/snap_root_before_upgrade

# 4. 重新挂载
mount /dev/vg_data/lv_root /mnt

# 5. 启动服务
systemctl start nginx mysql

另外，恢复完成后，我建议做两件事：

• 验证数据完整性：检查关键文件、数据库表、日志是否正常
• 重新打一个快照：恢复后的系统状态，值得再保存一次

嗯，这里还要提一句：快照不是万能的。它只能恢复磁盘数据，不能恢复内存状态。如果你的应用有大量未写入磁盘的数据，快照恢复后可能会丢失。所以，对于数据库这类应用，建议在打快照前先执行 FLUSH TABLES 或 CHECKPOINT 操作。

3.4 知识体系图：备份与快照的核心逻辑

为了让你更直观地理解，我画了一张流程图：

这张图的核心逻辑很简单：升级前打快照，升级成功则万事大吉，升级失败则从快照恢复。说白了，快照就是你的「后悔药」。

好了，关于备份与快照，我就讲这么多。记住一句话：备份做得好，半夜睡得香。