Data Domain — 压缩常见问题

适用对象

• 所有 DDR
• 所有版本

压缩：常见问题：

理想情况下是的。在实践中，由于以下原因，完整备份使用的空间略多于增量备份。这些原因也解释了为什么在数据没有更改后进行的完整备份仍将占用一定的空间。

• 元数据大约占用备份逻辑大小的 0.5%。假设完整备份的逻辑大小为 100 GB，增量备份的逻辑大小为 2 GB。假设增量备份压缩为 1 GB。则完整备份至少需要 1.5 GB。
• DD 压缩引擎将重写一些重复的数据段以提高性能。更改的数据局部性越差，写入的重复数据就越多。重复数据会在之后通过“filesys cleaning”回收。大约 2% 的逻辑大小会被重写为重复。在此重复水平，完整备份可能需要 1 GB（压缩）+ 0.5 GB（元数据）+ 2 GB（重复数据）= 3.5 GB。写入的重复数据量可以通过系统参数来控制，但在实际应用中，我们一般不会调整此参数。
• 不同备份的数据分段可能略有不同，具体取决于 NFS 客户端发送数据的顺序。此顺序不具有确定性。通常，分段算法可容忍移位和重新排序。但是，它也会产生一些“强制”段，这些段容易发生移位和重新排序。通常，大约 0.2% 的段是强制的，因此可以预期会使用更多的空间。

“filesys show space”根据运行命令时所存储数据的逻辑大小和使用的磁盘空间提供压缩比。

“filesys show compression”根据每个文件在创建时的压缩方式提供压缩比。

“filesys show compression”主要用于支持和调试。在存在文件删除的情况下，“filesys show compression”会高估压缩比。

例如，假设第一个完整备份获得 2 倍压缩。没有发生任何数据更改的后续完整备份将获得 200 倍压缩。第一个完整备份将被删除。“filesys show space”将显示 2 倍的压缩比。“filesys show compression”现在将显示 200 倍的压缩比，因为现在存在的唯一文件在创建时的压缩比为 200 倍。

在上面提到的示例中，在第二次备份后，“filesys show space”将显示大约 4 倍的累积压缩比。如果继续不删除数据并执行更多备份，累积压缩比会渐近提高到 200 倍。

还有一些其他细微的区别：

•  “filesys show compression”不考虑容器级消耗，因此进一步高估了压缩比
•  “filesys show compression”不考虑全局压缩的重复消除，因此低估了压缩比
•  “filesys show compression”可以提供每个文件或每个目录的信息，而“filesys show space”仅限于整个系统
•  “filesys show compression”提供全局压缩和本地压缩之间的细分，而“filesys show space”则不提供

参考资料

• 为什么“filesys show space”和“vtl tape show summary”的压缩比不同？

“vtl tape show summary”中显示的压缩比旨在匹配“filesys show compression /backup/vtc”。

更宽泛地说，可以为该 VTL 命令提供一个可选的筛选器来选择磁带盒子集，并且压缩应该与该磁带盒子集上的“filesys show compression”匹配。

但是，由于 VTL UI 代码中的一个错误，因此“vtl tape show summary”中显示的压缩是错误的。这是一个已知问题，已在版本 4.5.0.0 中得到解决。
 

• 为什么“filesys show compression last 24 hours”与 VTL 的预期不符？

对于 VTL，“filesys show compression last 24 hours”等命令的输出通常不符合基于“system show performance”等其他来源的预期。

出现此问题的原因是“filesys show compression”(fsc) 中的一个特性。通常，“filesys show compression”显示所选文件的累积统计信息。限定词“last 24 hours”会选择过去 24 小时内更新的文件。统计信息仍为自文件创建或上次截断为零大小以来的累积数据。因此，如果在过去 24 小时内增加了文件，“filesys show compression last 24 hours”将显示其在过去 24 小时之前的累积统计信息。

在非 VTL 环境中，备份文件仅写入一次，因此更新的文件与创建的文件之间没有太大差异。使用 VTL 时，备份可以附加到现有磁带文件。例如，假设有一个容量为 100 GB 的磁带，并且已使用 50 GB。如果在过去 24 小时内此磁带中增加了 10 GB 的数据，“filesys show compression last 24 hours”将显示以 60 GB 写入的文件的“原始字节”。
 

• 累积压缩比是如何计算的？

各个压缩比不是线性累加的。

假设第一个完整备份上的压缩是 2 倍，第二个完整备份上的压缩是 20 倍。累积压缩不是 (2+20)/2 或 11 倍，而是 2/(1/2+1/20) 或 3.64 倍。

通常，较低的压缩比对累积压缩比的影响比较高的压缩比更大。

假设第 i 个备份具有逻辑大小 si和压缩比 ci。可以按如下方式计算 k 个备份的累积压缩比：

C =（总逻辑大小）/（已用总空间）
总逻辑大小 = s1 + s2 + ..+ sk
总已用空间 = s1/c1 + s2/c2 + ... + sk/ck

通常，逻辑大小大致相同。在这种情况下，上述计算简化为：

例如，如果第一个完整备份获得 3 倍压缩，而每个后续完整备份获得 30 倍压缩，保留期为 30 天，则用户会看到 30/(1/3+29/30) 或 23 倍的累积压缩。
 

• Data Domain 压缩的工作原理是什么？

此问题在另一篇知识库文章“了解 Data Domain 压缩”中进行了详细回答，Data Domain：了解 Data Domain 压缩
 

• Data Domain 是否支持多路复用？​​​​​​​

来自备份应用程序的多路复用数据将导致极差的全局重复数据消除效果。有关更多信息，请参阅相关文章“不支持备份软件中的多路复用”Data Domain：备份软件中的多路复用。 
 

• 使用一对一目录复制时，为什么副本会显示更好的全局压缩？​​​​​​​

这通常是因为系统上写入的重复数据段的级别有所不同：

• 存储在源中的数据已经针对之前存储在源中的数据进行了一次重复数据消除。
• 通过网络发送的数据已针对副本中存储的数据进行了一次重复数据消除。
• 存储在副本上的数据经过了两次重复数据消除，一次是通过网络发送数据时，另一次是在接收的数据写入副本时。

由于重复数据消除过程会留下一些重复项，因此经过多次重复数据消除的数据具有较少的重复项。假设存储在源中的数据与副本中的数据相似，存储在源中并通过网络发送的数据经过一次重复数据消除，因此它们大致相同。存储在副本中的数据经过两次重复数据消除，因此压缩效果更好。

文件系统清理会删除大部分重复项。因此，在源和副本上运行清理后，存储在这两处的数据量应该大致相同。

• 使用 lz、gzfast 和 gz 本地压缩设置时，压缩有何变化？

filesys option set compression {none | lz | gzfast | gz}
 

警告：在更改本地压缩类型之前，必须关闭文件系统。然后，可以在设置压缩选项后立即重新启动它。

通常，压缩顺序如下：

粗略的区别是：

• lz 到 gzfast 可将压缩比提高约 15%，占用 2 倍 CPU
• lz 到 gz 可将压缩比提高约 30%，占用 5 倍 CPU
• gzfast 到 gz 可将压缩比提高约 10-15%

请注意，更改本地压缩首先会影响在进行更改后写入 Data Domain Restorer 的新数据。旧数据将保留其以前的压缩格式，直至下一个清理周期。下一个清理周期会将所有旧数据复制转发为新的压缩格式。这会导致清理运行时间更长，占用更多 CPU。

如果客户系统的 CPU 已经不足，特别是如果客户同时执行备份和复制，这可能会降低其备份和/或复制速度。建议客户明确安排一些时间来执行此转换。

知识参考：

• 解决迁移问题
• Data Domain：了解 Data Domain 压缩