LVM 快照是这样工作的吗?

LVM 快照是这样工作的吗?

我正在尝试弄清楚 LVM 快照的工作原理,以便可以在我的文件服务器上实现它,但我在 Google 上很难找到任何解释其工作原理的内容,而不是如何将其用于基本备份系统。

从我读过的内容来看,我认为它的工作原理如下:

  • 您有一个带有主分区的 LVM,并且分区中有大量未分配的可用空间
  • 然后,您拍摄快照并将其安装到新的逻辑卷上。快照应该有变化,因此第一个快照将是完整副本,对吗?
  • 然后,第二天您再拍摄一张快照(这张快照的分区大小不必那么大)并挂载它。
  • LVM 以某种方式跟踪快照,并且不会在主卷上存储未改变的位。
  • 然后你决定你已经有足够多的快照,并删除第一个快照。我不知道这是如何工作的,也不知道这会如何影响下一个快照。

有人能纠正我错在哪里吗?我猜,最多在谷歌上找不到任何东西。


虚拟主机

obu1:/home/jail/home/qps/backup/D# vgdisplay
  --- 卷组 ---
  VG 名称 fileserverLVM
  系统 ID
  格式化 lvm2
  元数据区域 1
  元数据序列号 3
  VG 访问 读/写
  VG 状态可调整大小
  最高等级 0
  当前 LV 2
  打开 LV2
  最大 PV 0
  电流 PV 1
  幕 PV 1
  VG 大小 931.51 GB
  大小 4.00 MB
  总 PE 238467
  分配 PE / 大小 238336 / 931.00 GB
  免费 PE / 大小 131 / 524.00 MB
  VG UUID qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

答案1

为什么不看看LVM-HOWTO 的快照部分

LVM 快照是基本的“写时复制”快照解决方案。快照实际上只不过是要求 LVM 为您提供指向文件系统当前状态的“指针”,并将快照之后所做的更改写入指定区域。

LVM 快照“实时”存在于快照所针对的卷的卷组内,而不是其他卷。您的陈述“...大量未分配的可用空间,而不是分区”听起来好像您认为快照“实时”存在于快照所针对的卷组之外,但这并不准确。您的卷组位于硬盘分区中,而快照所针对的卷和您拍摄的任何快照都实时存在于该卷组中。

LVM 快照的正常使用方式不是用于长期存储,而是获取文件系统的一致“图片”,以便进行备份。备份完成后,快照将被丢弃。

创建 LVM 快照时,您需要指定一定数量的空间来保存快照处于活动状态时所做的任何更改。如果所做的更改多于您为快照指定的空间,则快照将变得不可用并且必须丢弃。您不想让快照闲置,因为 (a) 它们会填满并变得不可用,并且 (b) 快照处于活动状态时系统的性能会受到影响——速度会变慢。

编辑:

Microsoft 卷影复制服务和 LVM 快照的作用并没有太大的不同。Microsoft 的解决方案更全面一些(Microsoft 的典型情况是——无论好坏,他们的工具和产品通常都试图解决相当大的问题,而不是专注于一件事)。

VSS 是一种更全面的解决方案,它将对支持快照的硬件设备和基于软件的快照的支持统一到一个 API 中。此外,VSS 具有 API,允许通过快照 API 将应用程序置于静止状态,而 LVM 快照仅与快照有关 - 任何使应用程序静止都是您的问题(将数据库置于“备份”状态等)。

答案2

正如 Evan 所说,LVM 快照是写时复制快照解决方案的一个示例。它的工作原理与 Evan 所暗示的略有不同,但差别不大。

如果您的 LVM 卷没有快照,则写入卷的过程会如您所料。块已更改,仅此而已。

创建快照后,LVM 会创建一个块池。此池还包含卷的 LVM 元数据的完整副本。当对主卷进行写入(例如更新 inode)时,被覆盖的块会被复制到这个新池中,而新块则会写入主卷。这就是“写时复制”。因此,从拍摄快照到主卷的当前状态之间更改的数据越多,该快照池占用的空间就越大。

当您挂载快照时,拍摄快照时写入的元数据允许将快照池块映射到卷(或更高级别的快照)中已更改的块上。这样,当访问特定块时,LVM 就知道访问的是哪个块。就该卷上的文件系统而言,没有快照。

James 指出了该系统的一个缺陷。当您拥有同一卷的多个快照时,每次写入主卷中的块时,都可能触发每个快照中的写入。这是因为每个快照都维护自己的更改块池。此外,对于长快照树,访问快照会导致服务器上进行大量计算,以确定需要为访问提供哪个确切的块。

当您处理快照时,LVM 只会删除快照池并根据需要更新快照树。如果删除的快照是快照树的一部分,则某些块将被复制到较低级别的快照。如果它是最低级别的快照(或唯一的快照),则只会删除池,并且操作非常快。


一些文件系统确实提供文件系统内快照,ZFS 和 BTRFS 只是其中两个比较知名的。它们的工作原理类似,尽管文件系统本身管理已更改/未更改的映射。这可以说是一种更好的方法,因为您可以对整个快照系列进行 fsck 以保证一致性,而这是您无法通过直接 LVM 实现的。

答案3

LVM快照效率低,快照越多系统运行越慢。

我只支持 xfs,因为它是我们使用的,并且 xfs_freeze 可用于停止对文件系统的新访问并在磁盘上创建稳定的映像。

写时复制以便高效利用磁盘空间。

您已在逻辑卷中创建了文件系统,其中有用于快照的备用空间。

这是常见问题解答中的一个例子

答案4

@Evan Anderson 和 @sysadmin1138 的答案虽然非常具有启发性,并且在当时(2009 年)非常准确,但现在由于以下原因而有些过时:不同的 LVM 快照方法:

  • 第一个(我们称之为经典 LVM)是上述答案中描述的。它基本上将要被覆盖的数据复制到特定的磁盘部分,这意味着多个快照会破坏性能(即:如果一个快照使系统速度降低 3-5 倍,两个快照使系统速度降低 6-10 倍,三个快照使系统速度降低 12-15 倍,等等)。这反过来又使它们无法支持滚动快照策略。此外,它们的元数据存储(纯文本)并未针对速度进行优化。事实上,它们的主要用途是备份:拍摄单个快照,并在备份后删除;

  • 新的(称为 Thin LVM 或叶酸)完全是另一回事。它严重依赖二进制优化元数据(btree)来快速高效地跟踪空间块。拍摄快照不是占用任何磁盘空间(即:不应声明快照大小,也不应将其分开),除了一些更多使用的元数据空间。覆盖已分配的块可能再次导致读取-修改-写入,但对于大型写入(其中“大型”表示大于精简池数据块),可以完全避免这种情况。更重要的是,多个快照不会不是复制比单个快照更多的数据,因为只有元数据被改变以将各个快照指向相同的数据块。从更坏的一面来看,应该注意精简快照可以“填满”整个卷,导致所有写入停滞。

您应该使用哪种 LVM 卷?对于根文件系统,我通常使用经典的 LVM 卷:它们非常可靠,而且更容易恢复。此外,根分区本身通常不包含太多有价值的数据(因此正常的备份过程就足够了)。另一方面,对于数据卷,我通常希望一些滚动快照延续到过去的几天/几周,因此我使用 Thin LVM(或 ZFS 池,但这是另一回事……)。有关其他背景信息,您可以阅读这里

相关内容