真正重要的东西是I/O吞吐量。运行备份和恢复的会话是你在你的SQL Server上执行的I/O最密集的活动之一。那是因为当你运行备份和(或者)恢复时，你要读取整个数据库的内容，然后把数据库的整个内容写一遍，反之亦然(对恢复而言)。它与执行查询的最大差异在于，备份和恢复时系统是在顺序地读数据库文件，而不是以随机方式访问，随机方式才是使访问效率更高的做法。因为这么大的数据量需要被访问然后再做写操作，所以最好的方法是尽可能分离你的I/O活动。

　　从数据库的角度来看，在这一点上你基本上也无能为力。数据库文件已经被分成了文件组，已经保存在你系统的某个驱动器或磁盘上。如往常一样，你仍然可以修改和移动你的数据到其他驱动器或者磁盘，或者移动到其他文件组，但是你应该是不会经常定期做这种操作的。既然我们在讨论备份和恢复，我们会保持数据库现有的布局以便讨论另一个技巧。

　　大部分你必须做的事都是很明显的。你能分离的磁盘活动越多，你的备份吞吐量就会越大。例如，有几个测试是利用第三方SQL Server备份工具执行的，几个TB大小的数据库可以在一个小时内备份完成。要达到这种速度，需要有许多想法和计划融入到硬件配置中。

　　正如我早期提到的，优化备份过程中的读操作和写操作都很重要。在上面的例子中，供应商有充足到奢侈的数据库布局设计和磁盘子系统来保存备份文件。既然你已经让你的数据库保持正常运行了，那让我们来看看在接收端能够做些什么。

　　在配置你的数据库服务器时，要考虑类似这样的事情：是否你应该采用本地连接的，或者利用存储区域网络(SAN)，还是网络附加存储(NAS)。此外，要考虑将采用什么类型的控制器以及使用多少SCSI，iSCSI或者光纤通道。在决定了这些因素以后，再考虑你将应用于数据库服务器的RAID级别。

　　理解RAID

　　RAID(独立磁盘冗余阵列)级别有很多种变化情况。最常见的如下：

　　还有更多种可行的RAID配置。其中一些比较实用，而有的则不然。一些RAID配置只存在于某些供应商的产品中。

　　现在，我们来讨论下上面提到的四种RAID级别。既然备份过程是一个读过程(读取你已经存在的数据库文件)和写过程(写你的备份文件)的结合，我们将看看写操作方面，看看哪种RAID级别最适合你的环境。