物理主机数据卷升级：用 LVM 快照验证离线回退

应用升级不只替换程序，还可能修改索引、资源文件与数据格式。仅保留旧安装包，不能保证数据卷可以回退。对于已经采用 LVM（逻辑卷管理）的物理主机，可以在停止写入后建立短期快照，再通过离线合并恢复升级前的状态。关键不在于快照命令是否成功，而在于写入边界、剩余容量和恢复验收是否完整。

一、先确认目标卷与回退边界

本文以 Debian 13、ext4 文件系统和经典 LVM 数据卷为例，不涉及根文件系统、启动卷或精简池。CloudUDP 的标配是两块 1TB NVMe 各自直连，没有硬件 RAID；这并不表示系统已经采用 LVM，实际布局必须现场核对。

先记录挂载源、文件系统类型、逻辑卷属性及卷组剩余空间：

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

如果目标只是普通分区，立即停止套用本文流程。不要为获得快照而格式化现有数据。若输出包含精简卷、缓存层或其他复杂布局，应采用对应存储方案的流程。

下文假定实际数据卷为 vgdata/appdata，挂载点为 /srv/appdata，关联服务为 app.service。这些名称必须替换为现场值，并确认不存在嵌套挂载及其他写入者。命令分阶段执行，不应整篇复制运行。

快照不等于备份

经典快照通过写时复制保存原卷被改写前的数据块，依赖原卷及其底层存储。它既不能隔离硬盘故障，也不会覆盖卷外的配置、程序或远端数据。

合并快照会撤销快照建立后的全部卷内写入。若升级后已接收业务请求，必须先导出需要保留的新数据，并确认其能与旧版程序兼容，不能直接回退。

二、停服后建立一致的恢复点

升级前先准备独立备份，记录程序版本、配置摘要及应用健康状态。快照只能保证指定卷的块状态；涉及多个卷或外部数据库时，仍需设计跨组件的一致性边界。

停止服务前应暂停入口请求、队列消费者与定时任务，防止服务停止后仍有进程改写数据。以下命令以卸载成功作为静止条件，不使用强制或懒卸载：

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

若卸载报忙，检查当前工作目录、打开文件和其他服务；未清除写入者前不继续。随后建立快照：

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

这里的 20G 是演示用快照空间，不是产品配置或通用推荐值。执行前确认卷组有足够空闲空间，且 preupgrade 尚不存在。快照容量应按回退观察期内被改写的数据块估算，而不是按原卷总容量机械取比例。

原卷重新挂载后，先创建一个小型验收文件，再进行受控升级。此时仍应阻止真实业务写入，否则后续回退需要额外的数据交接步骤。

三、只读核对快照并监控占用

快照建立成功后，必须验证其内容可读。以下选项仅针对本文的 ext4 示例：ro 表示只读，noload 阻止挂载时回放日志；不能直接用于其他文件系统。

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json 代表实际选定的稳定业务文件，需事先确认存在且有验收意义。清单存放在目标卷外，回退后只比较文件摘要字段，不比较挂载路径。

按变化量判断风险

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data% 表示经典快照空间的使用比例，不是原卷文件系统使用率。应在升级前后持续采样，观察增长速度；批量重建索引、覆盖大文件等操作可能快速消耗空间。

接近预设警戒线时，应暂停后续写入并评估扩容。卷组仍有空闲空间且快照有效时，可按评估增加容量：

sudo lvextend -L +10G /dev/vgdata/preupgrade

增加空间并不会延长业务允许的回退期限。若快照已经失效，不能把扩容视为修复，应转向独立备份恢复流程。没有告警接收与处置路径的快照监控，不构成可靠保护。

四、离线合并并验证恢复结果

决定回退后，先关闭业务入口，保存失败证据及必须保留的新数据。卷外程序与配置也要恢复到匹配版本；仅还原数据卷可能形成旧数据配新程序的错误组合。

确认快照有效、快照挂载点已卸载，再停止全部关联服务并卸载原卷。以下操作会改变数据，执行前再次核对卷名：

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

若合并被安排在下次激活时执行，应观察状态直至合并完成，不能仅凭命令返回成功就启动业务。成功后快照卷会消失，再挂载原卷并检查：

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

文件摘要应与基线一致，快照建立后创建的验收文件应消失。但这些只能证明指定文件发生了回退，不能证明应用正确。还需核对程序版本、关键记录数量、读取结果和一次受控写入，再启动服务并检查日志。

五、把演练结果变成升级检查单

先在非业务数据卷演练一次完整流程，记录快照创建、容量增长、合并状态及应用检查结果。生产升级前至少确认：

• 目标是已存在的经典 LVM 数据卷，挂载源与卷名相互对应。
• 所有写入者可停止，原卷可正常卸载，独立备份已验证。
• 快照空间有变化量依据，卷组留有扩容余量。
• 旧版程序、卷外配置及恢复清单均可取得。
• 新写入的保留方式与业务恢复条件已经明确。

升级通过验收且回退观察期结束后，确认快照未挂载，再用 lvremove /dev/vgdata/preupgrade 清理仍然存在的快照；已经合并的快照无需重复删除。

最终交付物应是一份包含卷布局、恢复点、容量记录与业务验收结果的操作记录。快照只是短期回退工具，可靠性来自可重复执行的恢复过程，而不是多保留一个卷名。

常见问题