当越来越多的用户依靠远程复制作为灾备基石时，复制和数据库优化并不总能协调进行的问题也逐渐显现出来，这一问题在Exchange上尤为明显。为了收回未用空间，用户必须使Exchange数据库离线以进行碎片整理和压缩。更多的问题出现在复制阶段，此时数据库的变化必须进行远程镜像，这同时也增加了流量。

目前，复制服务提供商们还没有明确的解决办法。Double-Take软件公司的解决方案工程主管Bob Roudebush说:“在我看来，这个问题是普遍存在的。它并不是某个解决方案或复制技术所特有的。”

为了应对这一问题，一些公司对它们的存档和复制过程进行了分解。例如，将那些必须在其它Exchange数据库中进行存档的邮箱和那些标明需要进行复制的邮箱分离开来。企业策略集团(ESG)的分析师Brian Babineau称:“这是一个化整为零的解决方案。但本质上，问题还是没有得到解决。”

Double-Take通过使用户可以断开复制连接而提供了另一种选择。如果数据库必须下线，那么复制可以在碎片整理和其它数据库维护工作完成后再次连接。Double-Take可以采用块校验比较对数据进行镜像，并仅将被变动的数据块进行传送。

微软推荐它的“簇连续复制(CCR)”功能，它将出现在年底提供的Exchange 2007中。CCR采用log shipping技术，允许Windows Server 2003 Cluster中的活跃节点(active node)向同一cluster中的非活跃节点(passive node)进行复制，该非活跃节点可以是处于地理上的远端位置。微软的Exchange用户教育技术撰稿Scott Schnoll推荐采用Exchange的Move Mailbox功能来代替离线碎片整理。该功能建立一个空的新数据库，这样，当所有的旧数据中的邮箱被移入新数据库中后，旧数据库就可以被删除，新数据库就可以被远程复制。

Scott Schnoll说:“由于新数据是Move Mailbox过程加入的，它们全都是在连续的块中被写入的。服务过程中的中断仅出现在每个单独的mailbox被移动时。”他还补充说这一在线操作可以进行时间预定。

在这些解决方案中没有一个是完美的，特别是对于大型企业环境来说。有这样一个用户，他是一个国际化通信公司的高级系统工程师，目前正在实施一个有分布在全球的43000个Exchange用户，13TB数据的系统的灾难恢复方案。在他看来，保持数据库备份完整的理想办法是，制造商建立自己的Exchange碎片整理引擎，其可以在主站和灾难恢复地同时运行。“但是，这肯定会使微软非常不快。”