Linux LVM 快照备份与恢复

1次阅读

快照卷默认不显示在普通lvs列表中,需用lvs -a或lvdisplay查看;它是写时复制机制,需指定–size并监控data%;合并前源卷必须inactive;挂载快照应只读,适合短时一致备份。

Linux LVM 快照备份与恢复

lvs 输出里看不到快照卷?检查 lvdisplaylvs -a

快照卷默认不显示在普通 lvs 列表中,容易误以为创建失败。LVM 把快照当“附属逻辑卷”处理,必须加 -a 参数才列出,或者用 lvdisplay 查看源卷详情——它会明确标出 OriginSnapshot 关系。

常见错误现象:运行 lvcreate -s 后立刻执行 lvs,发现目标卷没出现,怀疑命令没生效;其实快照已建好,只是被过滤了。

  • lvs -a 是最直接的确认方式,快照卷名后带 snap 或你指定的名字,Attr 列首字母是 s(如 swi-a-s---
  • 快照卷和源卷必须在同一卷组(VG),否则 lvcreate -s 会报错 Volume group "xxx" not found
  • 快照卷路径是 /dev/<vg>/<snapshot_name></snapshot_name></vg>,不是子目录,别去 /dev/mapper/ 下翻找别名

快照空间耗尽就只读甚至失效?控制 --size 和监控 data%

快照不是复制,而是写时复制(COW)机制:源卷数据块被修改前,先拷一份到快照空间。一旦快照区填满,LVM 默认让快照变为 Inactive 状态,后续对源卷的写入可能失败或静默丢弃——这不是 bug,是设计如此。

使用场景:仅适合短时间备份窗口(比如 rsync 拷贝期间),不适合长期挂载做“只读副本”。

  • 创建时务必显式指定 --size,例如 lvcreate -s -L 2G -n snap_home /dev/vg0/home;不加 -L 会用默认策略(通常极小),极易爆满
  • lvs -o +data_percent 实时看快照空间占用,data% 接近 100% 就得立即处理(备份完删掉快照,或扩大它——但扩大有风险,见下条)
  • 扩容快照卷(lvextend -L +1G /dev/vg0/snap_home)可行,但不能缩容;且扩容不解决已有脏块积问题,只是延缓失效

恢复时直接 lvconvert --merge?必须确保源卷未激活

合并快照(即“回滚”)本质是把快照里保存的旧数据块,覆盖回源卷对应位置。LVM 要求源卷处于 inactive 状态,否则拒绝执行,报错 Cannot merge during logical volume is active

容易踩的坑:很多人在系统运行时尝试合并根文件系统快照,结果卡住或失败——因为 / 卷必然活跃。

  • 合并前先关机进 rescue 环境,或用 live CD 启动,再执行 lvconvert --merge /dev/vg0/snap_home
  • 合并命令本身不加 -y 也会交互确认,但关键不是这个,是状态检查;即使加了 -y,源卷活跃照样失败
  • 快照合并后自动删除,不需要再手动 lvremove;但如果合并中断(比如断电),下次启动可能提示 Snapshot has invalid state,需用 lvconvert --repair(慎用,可能丢数据)

rsync 备份快照卷比直接备份原卷更安全?是,但得挂载为只读

快照卷内容在创建瞬间冻结,后续源卷所有写入都不影响它。所以用 rsync -aHAX 拷贝挂载的快照,能得到强一致备份;而直接备份活跃的源卷,可能遇到文件正在被写、数据库锁表等问题。

性能影响很小:快照卷读取走的是 COW 元数据路径,不额外加重源卷 I/O。

  • 挂载前务必加 -o ro,例如 mount -o ro /dev/vg0/snap_home /mnt/backup;快照卷本身不支持读写,强行读写会报错 Invalid argument
  • 不要在快照上运行 fsck,除非你知道它对应的是哪个内核版本的 ext4/xfs;快照元数据格式与主卷一致,但校验工具可能因版本差异误报
  • 备份完成后立即卸载并删除快照(umount /mnt/backup && lvremove /dev/vg0/snap_home),避免持续占用空间和增加 COW 开销

快照不是万能备份方案:它依赖 VG 剩余空间、无法跨主机、不防误删文件。真正要落地,得配合定时脚本检查 data%、自动清理过期快照、以及把 rsync 结果同步到另一台机器——这些才是容易被忽略的实操断点。

text=ZqhQzanResources