于磁盘的备份
首先来看的是最简单的技术——备份。在SQL Server 2008的企业版中，备份有了一个新的特性，那就是备份压缩。那么备份压缩对于高可用有什么帮助呢？
那么就要提到现在业界非常流行的一种备份解决方案——磁盘备份解决方案，有很多与该解决方案相近的名称：在线备份、虚拟磁带库等等。这些方案其实都是基于一个思想，将数据备份到快速的在线磁盘设备上，这样就可以利用磁盘的高速IO和高速检索能力。不过磁盘的高昂代价往往是这种企业在这一解决方案面前驻足不前的主要原因，而现在SQL Server 2008企业版中的备份压缩可以大幅度减少备份后的文件尺寸，因此基于磁盘的备份解决方案看起来也更加有竞争力了。
基于磁盘的备份带来最大的好处就是利用磁盘高速IO的能力进行快速的还原。这就可以缩短服务离线的时间，同时也可以减少数据库备份这一维护操作对应用的影响。
数据库镜像 故障转移集群
上面我们介绍的故障转移集群、日志传送亦或基于磁盘的备份都是作为单一技术出现的，而在真实的大中型企业环境中为了确保数据应用的持续在线，我们通常有一些组合多种高可用技术的方案。通过混合不同可用性技术，我们将可以采长补短。
例如数据库镜像技术。
虽然数据库镜像可以解决故障转移集共享存储存在单点失效威胁、依赖于特殊硬件等一系列的问题，但是数据库镜像最大的问题就是故障转移路径过短。对于大中型企业来说，仅有两个节点的故障转移路径有些不足。因此通过增加一个故障转移集群作为数据库镜像的镜像节点就可以解决了数据库镜像故障转移路径过短的问题。
上面这种解决方案当主体服务器失效后，数据库镜像会将启动镜像节点，而由于镜像节点是由一个故障转移集群承担的，因此当镜像节点中的一个节点失效后还有一个后备节点，因此还可以有一个后备节点承担。
其实故障转移集群和数据库镜像是各有利弊，因此这两种技术融合在一起后的解决方案不仅仅是上面这一种，下面就给出另外一种解决方案的示意图：
细心的读者可能会发现，方案二种没有了见证节点，这意味着从主集群切换到镜像集群需要手动完成。那么为什么这种解决方案中没有了见证节点呢？
因为数据库镜像和故障转移集群都拥有自动故障转移的特性，如果两种技术的自动切换都生效的话，那么在主体集群的活动节点失效后就会有两个节点同时试图生效——主体集群的后备节点和镜像集群的活动节点，那么结果就只有一个，数据库镜像会话失败。
远程故障转移集群
对于某些跨地区甚至是跨洲的大型集团来说，站点失效这个困扰会逐渐进入IT主管和DBA的脑海中。
