环境中的数据复制技术太多

哪种解决scheme更适合于给定的场景，在很大程度上取决于所涉及的应用程序和数据，没有任何“全局”方法可以随时随地使用。

真的有太多的不同情况参与。 一些例子：

• Active Directory域控制器被devise为作为多主复制的分布式数据库工作; 而且您还需要在WAN设置中拥有本地DC，因为join域的Windows计算机需要有可用的DC才能正常工作。 与此同时，使用AD，在虚拟服务器层或物理存储层进行低级别的复制，您将不会受益，因为您无法从另一个数据库复制数据库一个，你不能启动一个克隆的DC，并期望它工作（甚至不尝试这样做，USN回滚是讨厌的 ）。
• 对于文件服务器，情况恰恰相反：虽然存在应用程序级别的复制技术（Windows中的DFS），但对于大量数据，存储级复制可能是最好的方法。
• 现在，假设您正在使用Exchange; 最近的Exchange系统（2007-2010）devise时考虑了事务数据库复制，这是唯一官方支持的方法; 您实际上可以复制Exchange数据库并将其装载到另一个Exchange服务器上（这就是所谓的“数据库可移植性”），因此可以使存储级别的复制起作用……但是更加痛苦的是，将用户移动到这样的服务器需要重新configuration。 而且，在上述两种情况下，实际上在多个地方具有本地数据副本（AD在任何地方都是需要的，并且不同办公室的用户可能需要访问相同的文件服务器数据），对于Exchange而言，这只是使得因为在正常的操作中，每个用户只能访问他/她自己的邮箱，这个邮箱一次只能在一台服务器上活动。
• 对于各种数据库系统，同样可以在应用程序级别或任何基础级别上工作; 但这很大程度上取决于应用程序：如果您需要在多个位置修改数据（而不是只读取它们），则存储复制无法合并冲突的副本，您将需要让DBMS处理该数据。

每种技术都有自己的好处和用例; 实际上没有“一刀切”的办法。

我迄今为止考虑过两个select。 两者的首要思想是将责任分配给一个团队：系统pipe理员或应用程序pipe理员。 只有一个团队参与，可以降低系统的复杂性和风险。

在虚拟服务器层复制标准化

通过仅在虚拟服务器层configuration复制，可以将操作系统及其中运行的任何应用程序视为黑匣子。 系统pipe理员正在控制。

优点：

• 所有应用程序的DR过程是相同的：停止复制，启动DR虚拟服务器，并要求不同的应用程序团队确认一切正常。
• 很容易确认你已经完全覆盖了所有的数据。
• 计划服务器/存储维护很容易，因为应用程序团队的参与很less。

缺点：

• 灾难恢复服务器大部分时间处于闲置状态：可能会浪费服务器资源。
• 鉴于IP地址与Prod匹配，在没有完全故障转移的情况下testingDR可能很困难。
• 复制是即时的，所以如果Prod中有数据损坏，它会立即传播到DR。
• 使用这种方法克隆到开发/testing可能很困难。
• 不能用于在虚拟机中运行不佳的系统。

可以与物理卷层技术结合使用，以提高复制的性能（同时仍由VM软件进行pipe理）。

标准化应用层复制

通过仅在应用程序层configuration复制，您可以将服务器，存储和操作系统视为黑匣子。 应用程序pipe理员可以控制。

优点：

• 许多应用程序可以以多主或主从模式运行，以利用所有服务器资源。
• 许多应用程序可以以简洁的格式传输更改，节省带宽并提高性能。
• 某些应用程序可以延迟更改的应用程序以防止在DR处立即传播损坏。
• 断开复制并重新configuration服务器作为开发/testing是相对容易的。

缺点：

• 每个应用程序团队都必须以自己独特的方式configuration复制。
• 并不是所有的应用程序都支持这种复制，所以需要一个回退选项。

可以与文件系统层技术结合使用，以支持无法复制的应用程序。