日志 LUN 大小在一定程度上取决于备份和还原设计。例如，如果设计允许后退两周并重播自那时起生成的所有日志，则需要两周日志文件的空间。如果备份设计包括每周完整备份和每日差异备份，则日志 LUN 需要大于整周日志文件的空间，以允许在还原期间进行备份和重播。大多数执行夜间完全备份的企业，会将所需的每天日志生成容量的分配提高到两到三倍。采用该方法可防止备份失败导致填满日志驱动器而卸除数据库。

如果计划在 Exchange 2010 中使用邮箱恢复和单个项目恢复功能作为备份基础结构（从而启用循环日志记录），那么最佳做法是，您应该确保将所需的每天日志生成容量的分配提高到三倍。这样可确保当复制已挂起或在正常参数下无法运行时，数据库不会由于截断故障而卸除。

移动邮箱是大型邮箱部署的主要容量因素。许多大型公司每夜或每周将一定百分比的用户邮箱移动到不同的数据库、服务器或网站。如果您的组织也是如此，您可能会发现为日志 LUN 多提供一些空间以容纳邮箱移动是非常必要的。

尽管源服务器会记录小型记录删除，目标服务器仍必须先将所有传输数据写入事务日志。如果一天生成 10 GB 的日志文件，并且将 30 GB 的缓冲区保留三天，则移动 50 个 2 GB 的邮箱 (100 GB) 将填满目标日志 LUN 并导致停机。在上述情况下，可能必须为日志 LUN 分配额外容量以支持移动邮箱。

对于大多数部署来说，我们建议您在创建日志 LUN 时向日志大小增加 20% 的开销因素（考虑其他所有因素之后），这样可以确保出现意外的日志生成时存在必要的容量。

高可用性会在三个重要方面影响日志容量要求：

• 数据库副本计数   整个系统的日志容量会基于在高可用性部署中选择的数据库副本的数量而增加。如果有三个数据库副本分布在三个服务器上，则需要为每个服务器上的每个副本设置日志容量。
  
• 日志截断机制   由于 Exchange 2010 中的高可用性最多可以提供每个邮箱数据库的 16 个副本，因此它可提供将连续复制循环日志记录作为日志截断/删除机制的基础（与运行完整/增量备份来截断/删除旧日志相对）。有关详细信息，请参阅了解备份、还原和灾难恢复和高可用性和站点恢复中的“日志截断而不备份”部分。
  
• 数据库副本重播延迟   Exchange 2010 中的高可用性提供了一种选择，可以延迟被动数据库副本上的日志重播（按副本配置）。此功能用于当将日志播放到延迟数据库副本中时提供延迟。此延迟有助于防止可能会使不需要的内容复制到所有数据库副本的事件。通过在将带有不需要的内容的日志播放到数据库中之前挂起重播，可以防止将该内容播放到延迟数据库副本中。
  为数据库副本启用重播延迟后，日志容量要求会相应地发生更改。如果配置了 14 天延迟，则需要设置 17 天的日志。只有配置了延迟的数据库副本需要额外的日志容量，该数据库的其他副本（没有延迟）将具有正常的（非延迟）日志容量要求。
  

有关详细信息，请参阅了解高可用性因素。

LUN 的容量要求将基于数据集（数据库、事务日志、内容索引和恢复空间）的大小以及其他一些可用空间。多数操作管理程序都具有容量阈值，当 LUN 的利用率超过 80％ 时，容量阈值可提供警报。

可以使用以下公式来确定 LUN 的相应大小：

LUN 容量 = 数据大小 /（1 - 可用空间百分比要求）

例如，如果数据大小要求为 3000 MB，可用空间要求为 20％，则承载该数据的 LUN 的大小必须为 3750 MB。

本文来自微软官方知识库。