好了,开始我们今天的话题吧.在Exchange 2007 sp1里面.New feature.SCR(备用连续复制).
先弄清楚几个感念吧,你也可以直接看Exchange 2007 sp1的帮助文档.
在 LCR 和 CCR 中,SCR 也使用存储组主动副本和被动副本的概念,但它们分别称为 SCR 源和 SCR 目标。不过,SCR 源和 SCR 目标都是存储组副本。(无法针对 SCR 使用恢复存储组。)SCR 的起点(SCR 源)是单一副本群集或 CCR 环境中独立的邮箱服务器或群集邮箱服务器上的任意存储组。不过请注意,尽管 SCR 源可以是群集邮箱服务器,但 SCR 本身不是群集解决方案,也不需要使用 Windows 群集服务,这一点很重要。SCR 的终点(SCR 目标)既可以是独立邮箱服务器,也可以是故障转移群集中的节点,群集中已安装邮箱角色但尚未配置群集邮箱服务器。
每个 SCR 源存储组拥有的 SCR 目标数都不受限制。例如,一个源可以在其所在的数据中心拥有一个目标,在其他数据中心拥有另一个目标。但是,Microsoft 建议每个源对应的目标不要超过四个。如果您决定使用四个以上的目标,则必须相应地针对内存、CPU、磁盘资源和规划来评估可能会对 SCR 源服务器造成的影响。每个 SCR 目标计算机可以具有多个源服务器。源计算机和目标计算机都必须运行 Exchange 2007 Service Pack 1。操作系统必须受 Exchange 2007 Service Pack 1 支持(例如,Windows Server? 2008 或 Windows Server 2003 SP2)。不过,无论您使用哪种操作系统,SCR 都不支持跨操作系统,所以它要求 SCR 源上的操作系统与该源对应的所有 SCR 目标上的操作系统匹配。因此,如果 SCR 源运行 Windows Server 2003,则该源的所有 SCR 目标也必须运行 Windows Server 2003。SCR 在 Exchange 2007 Standard Edition 中提供。如果将 SCC 或 CCR 环境中的群集邮箱服务器用作 SCR 源,则需要使用 Exchange 2007 企业版。使用企业版时,每个 SCR 目标最多支持 50 个实例(50 个复制的存储组);使用标准版时,最多支持 5 个实例。SCR 目标也有一些必须满足的要求。首先,源计算机和目标计算机必须位于同一个 Active Directory 域中,不过它们可以位于相同或不同的 Active Directory 站点中。此外,源及其所有目标上的数据库和日志文件路径必须与 SCR 正在复制的各个存储组相匹配。最后,将某个节点或服务器配置为 SCR 目标后,将无法为 SCR 目标计算机上的任何存储组启用 LCR,并且无法将任何群集邮箱服务器添加到备用故障转移群集。
SCR 的一个主要区别在于它支持每个存储组使用多个目标,而 LCR 和 CCR 均仅支持一个目标(被动副本)。另一个主要区别是您无法备份 SCR 副本,这与 CCR 和 LCR 不同。使用 SCR 时,如果针对 SCR 源存储组执行受支持的备份(在 CCR 和 LCR 中,则是针对 SCR 源存储组的主动副本或被动副本执行备份操作),则会更新 SCR 目标的数据库标题并截断日志文件。与 LCR 和 CCR 一样,SCR 的日志传送是连续的并使用一种“拉”模型。新的日志文件关闭并使用下一代日志文件序列号命名后,SCR 目标计算机上运行的 Microsoft Exchange 复制服务就会从 SCR 源计算机中拉出已关闭的事务日志文件,检查并验证这些文件,然后将其移动到 SCR 目标计算机上对应的存储组日志文件文件夹。
在说几个常用的cmdlet
Disable-StorageGroupCopy
禁用存储组的 SCR 目标。
Get-StorageGroupCopyStatus
确定 SCR 目标的当前运行状况。
New-StorageGroup
新建启用 SCR 的存储组,无需使用 Enable-StorageGroupCopy cmdlet 单独启用 SCR。
Restore-StorageGroupCopy
禁用 SCR 并在恢复过程中通过 Mount-Database 操作使 SCR 目标数据库可用于装载。
Resume-StorageGroupCopy
用于使已挂起 SCR 的存储组继续进行连续复制。
Suspend-StorageGroupCopy
对启用 SCR 的存储组挂起连续复制活动。
Update-StorageGroupCopy
用于为 SCR 目标存储组设定或重新设定种子。
好了.开始吧..
实验环境是Exchange2007 sp1
用到4台虚拟机,1台DC,2台Exchange 2007 sp1 都装有邮箱角色,分别作为SCR的源和目标.都是单独的邮箱角色.还有一台outlook.并在SG\DB里面启用邮箱,为了效果明显,发了几封邮件.
分别建了两个存储组.SG和SGT.数据库分别是DB和SGTDB.
Snap1
启用SCR.
Enable-StorageGroupCopy ex\sg -StandbyMachine max –replaylagtime 0.0:0:0 –truncationlagtime 0.0:0:0
重播延迟时间 (replaylagtime)
将日志文件复制到 SCR 目标计算机后,SCR 会执行一些 LCR 和 CCR 不执行的操作。SCR 不会立即将日志文件重播到数据库副本,而是强制实施 50 个日志文件的内置重播延迟外加 24 小时。SCR 还允许您在这些内置延迟以外指定附加的时间延迟。延迟重播活动在很多情况下都非常有用。例如,在活动数据库出现逻辑损坏的情况下,延迟可以防止 SCR 目标数据库出现逻辑损坏。
管理员控制的重播延迟使用参数 ReplayLagTime 进行设置,该参数指示 Exchange 复制服务在重播已复制到 SCR 目标计算机的日志文件前应等待的时间量。格式为 Days.Hours:Minutes:Seconds,默认值为 24 小时。该值最大可设置为 7 天,最小可设置为 0 秒,将该值设置为 0 秒可有效消除日志重播活动中除默认延迟 50 个日志文件之外的任何延迟。
除 ReplayLagTime 外,Exchange 还具有 50 个日志文件的内置硬编码延迟,与 ReplayLagTime 的值设置无关。为了确定重播日志文件的时间,Exchange 使用较大的 ReplayLagTime 值或 x 个日志文件,其中 x=50。上述设置针对需要为某个存储组重新设定种子的情形提供了一层额外的保护,即如果使用连续复制的 SCR 源(例如 CCR 环境中的群集邮箱服务器)遇到故障转移,并且需要使用 Restore-StorageGroupCopy cmdlet 使一个或多个存储组联机。(种子设定的过程是:使用可扩展存储引擎 (ESE) 流备份 API 为 SCR 目标计算机上的 SCR 源数据库制作联机副本。)通过延迟 SCR 目标上的重播活动,当 SCR 源的故障转移遭受损失时,需要为 SCR 副本重新设定种子的概率会降至最低,因为 SCR 源上数据丢失本身的特点可及时将两个副本紧密联系在一起。
截断延迟时间(truncationlagtime)
SCR(引入了多个数据库副本的概念)允许在所有 SCR 目标计算机检测完日志文件后,立即在 SCR 源计算机上截断日志文件。SCR 源服务器上的日志截断不会等待所有日志都重播到所有 SCR 目标后才执行,因为 SCR 目标副本的日志重播延迟时间可以配置为很大的值。
TruncationLagTime 的新参数为日志截断添加额外延迟,该参数指定在截断已复制到 SCR 目标计算机并重播到数据库副本的日志文件前,Exchange 复制服务应等待的时间(格式为 Days.Hours:Minutes:Seconds)。该时间段在日志文件成功重播到数据库副本后立即开始计算。该值最大可设置为 7 天,最小可设置为 0 秒,后者会有效消除日志截断活动中的任何延迟。
在 SCR 环境中,每三分钟运行一次后台线程,以确定是否存在需要截断的日志文件。如果日志文件生成顺序低于存储组的日志文件检查点,并且日志文件的存在时间早于 ReplayLagTime + TruncationLagTime,则会截断 SCR 目标上的日志文件。
在使用 SCR 扩展的 LCR 或 CCR 环境中,如果满足以下四个条件,则会截断 SCR 目标上的日志文件:日志文件已备份,日志文件生成顺序低于存储组的日志文件检查点,存储组的被动副本处于允许截断日志文件的状态,并且所有 SCR 目标均已对日志文件进行检测。 
Snap2
查看SCR状态…
 
Snap3
在源上面SG存储组会变成共享状态.
Snap4 Snap5
同步完成后在目标服务器上,相同的路径下也会出现SG
只是SG\DB大小和源服务器的不太一样,小很多.同步需要时间
其实这里可以用Update-StorageGroupCopy 手工同步.我人懒,不做演示了.自己看Help doc.
Snap6 Snap7
在我狂发了几封超大mail后..
搞点破坏.反正还有副本.
从副本恢复.
如果碰见下面的提示,加-force
Snap8
在MAX上更改SGT\SGTDB的路径.指定到SG副本的位置.
 Snap10
 
Snap11
挂载数据库…囧..
日志里面有如下错误.
 
Snap12
哎..修吧…
Snap14 Snap15 Snap16 Snap17 Snap18
看见Clean shutdown..OK!
Snap19
为源服务器据库上的邮箱重新配置以指向新数据库..
Snap20
感觉头还是很晕啊..
各位就凑合着看吧…