SQL Server中备份，除了镜像方式外还有复制方式。(SQLServer 2012中还引进了AlwaysOn，并且官方建议不再使用镜像)
数据库复制-----概述
复制是一组技术，它将数据和数据库对象从一个数据库复制和分发到另一个数据库，然后在数据库之间进行同步以保持一致性。 使用复制，可以在局域网和广域网、拨号连接、无线连接和 Internet 上将数据分发到不同位置以及分发给远程或移动用户。
快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全刷新时也可以使用快照复制。
数据库复制-----复制类型
- 事务复制
事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。
事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：
- 希望发生增量更改时将其传播到订阅服务器。
- 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
- 应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
- 发布服务器有大量的插入、更新和删除活动。
- 发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。
- 合并复制
合并复制通常也是从发布数据库对象和数据的快照开始， 并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。 订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：
- 多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
- 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
- 每个订阅服务器都需要不同的数据分区。
- 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
- 应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
- 快照复制
快照复制完全按照数据在特定时刻的状态分发数据，而不监视数据是否更新。 发生同步时，将生成完整的快照并将其发送到订阅服务器。
当符合以下一个或多个条件时，使用快照复制本身是最合适的：
- 很少更改数据。
- 在一段时间内允许具有相对发布服务器已过时的数据副本。
- 复制少量数据。
- 在短期内出现大量更改。
在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。 对于给定的某些类型的数据，更频繁的快照可能也比较适合。 例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。 但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。 评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。
详细内容请查阅：
http://technet.microsoft.com/zh-cn/library/ms151198.aspx
http://msdn.microsoft.com/zh-cn/library/ms152531.aspx
