最大程度地减少恢复备份的需求

引言

本系列的第二篇文章讨论了维护具有不同宕机级别的系统的成本、数据丢失的方式以及备份的构成。在本文中，我将讨论如何配置硬件以最小化备份恢复的需求。

正确选择硬件

正确设置硬件是保护数据的第一步。在指定硬件和设置数据库时所做的决定，将决定你是数据库英雄还是替罪羊。普通的硬件技术人员不懂 SQL Server，而普通的 DBA 也不懂硬件。了解这两者的人可以带来真正的改变。

想想你普通的、低端的服务器。它可能有一两个硬盘和一两个电源。当 SQL Server 使用默认设置安装时，所有程序、数据和日志都放在同一个驱动器、同一个文件夹中（在我看来，放在 Program Files 文件夹里很麻烦）。

默认设置中有多少个单点故障？首先，单个硬盘或单个电源的故障将导致服务器宕机，至少是暂时的。如果硬盘发生故障，你需要更换新硬盘，重新安装 SQL Server 并恢复备份。这需要一些时间。

你可以采取许多措施来减少此类潜在的数据灾难性丢失风险。第一件事是考虑购买至少有两个电源的服务器。电源是一个相当常见的故障点，并且通常增加冗余电源只会使系统成本增加约 250 美元。这笔钱花得值。

RAID 级别

RAID（独立 [或廉价] 磁盘冗余阵列）硬盘是两个或多个磁盘组合使用，以提供容错和/或性能优势。在 Google 上搜索 RAID 会得到大量详细介绍 RAID 的文章，但下面是对流行的 RAID 级别的快速解释。

• RAID 0—条带化磁盘阵列，无容错。数据块分布在两个或多个磁盘上，提供更好的性能，但没有冗余。
• RAID 1—镜像和双工。同时将数据写入多个磁盘。在有适当的硬件支持的情况下，速度与非 RAID 磁盘大致相同。在 RAID 1 配置中，每两个磁盘只有一块磁盘的容量。
• RAID 5—数据和奇偶校验信息分布在多个磁盘上。RAID 5 使用分布式奇偶校验，因此单个磁盘上的奇偶校验信息不会成为瓶颈。读写奇偶校验信息会带来一些额外的开销。
• RAID 0+1—两个 RAID 0 条带，上面创建了一个 RAID 1 镜像。
• RAID 10—创建多个 RAID 1 镜像，并在其上创建 RAID 0。

还有其他一些 RAID 级别，但这些是最常用的。例如，RAID 4 类似于 RAID 5，但有一个专用的奇偶校验磁盘。当相同的硬件在 RAID 5 配置中可以做得更好时，不太可能有人会使用 RAID 4。

对于提供冗余的 RAID 级别，你可能会问，当一个磁盘损坏时会发生什么？这还取决于所涉及的硬件。

在许多情况下，RAID 磁盘是“热插拔”的，这意味着当控制器检测到故障时，你可以在服务器继续运行时简单地移除有问题的磁盘并更换它。替换磁盘后，新磁盘将更新，以包含所需的数据和奇偶校验信息。如果第一个损坏的磁盘在更换之前发生另一个故障，RAID 5 配置将失败。一些控制器允许使用“热备用”驱动器，该驱动器不包含任何数据，但在其中一个驱动器发生故障时会自动使用。

其他可能的故障点是网卡、内存、处理器和主板。许多服务器提供冗余网卡和纠错内存，以减少这些组件发生灾难性故障的可能性。如果处理器或主板发生故障，你可能需要进行一些维修。

SQL Server 的配置

这些硬件信息如何影响你安装和配置 SQL Server？在为 SQL Server 机器指定硬件和操作系统设置时，你可以采取许多措施来提高可靠性和可恢复性。

首先也是最重要的，你要将日志和数据放在不同的驱动器上。

每当 SQL Server 对数据库进行更改时，除了更改数据之外，还会将更改信息写入日志（是的，这有点夸张——有些操作不记录日志）。通过将日志放在一个驱动器或 RAID 阵列上，而将数据放在另一个驱动器上，你可以最大程度地消除数据灾难性丢失的风险。如果日志卷发生故障，你可以轻松地修复该卷而不会丢失数据。如果数据卷发生故障，通过备份和日志，你应该能够恢复到故障发生前的状态。

我最近在 SQL Server 备份过程中出现了一个尴尬的失误，原因是没有将数据和日志放在单独的卷上。虽然我在许多客户站点上监督了正确的备份和恢复程序，但我自己的个人站点（实际上是爱好站点，不是我的业务的一部分）保护得不太好。我当时使用的是一台非常旧的服务器，已经重新安装了几次，而我并不知道，我用于数据、备份和日志的不同逻辑卷实际上位于同一个物理卷上。你可以猜到接下来发生了什么：硬盘故障，带走了所有近期数据。

幸运的是，这是不影响我的业务的个人数据；我的业务数据已正确备份，并在几小时内恢复。但是，仅仅因为这些数据没有商业价值，并不意味着它们不重要。恢复它需要巧妙地利用 Google 缓存的一个页面上的数据。那个关于鞋匠的孩子没鞋子的故事是怎么说的？

虽然 SQL Server 可以安装在 FAT、FAT32 或 NTFS 卷上，但没有理由不将 SQL Server 安装在 NTFS 卷上。NTFS 支持卷或目录的压缩，但强烈建议不要压缩用于 SQL Server 数据或日志文件的任何卷或目录。压缩会严重降低 SQL Server 的性能。如果一个卷要专门用于 SQL Server 的日志或数据，请使用 64 KB 的群集大小格式化驱动器（一个与 SQL Server 数据扩展单元大小匹配的大小）。

与其仅仅对数据和日志阵列使用 RAID 1（或 RAID 5 或 RAID 10），不如利用我们对日志和数据卷上数据的用法理解，做出更明智的选择。假设你对读写性能最感兴趣，并且不能容忍任何数据丢失，那么使用 RAID 10 或 0+1 用于数据，使用 RAID 1 用于日志，可以提供卓越的性能和可靠性，但成本很高。为了获得更高的可靠性，你可以拥有 RAID 10 或 0+1 数据卷和 RAID 1 日志卷的多个镜像副本。

假设你的需求稍微不那么极端，特别是如果写性能不是关键的话，使用 RAID 5 卷用于数据，使用 RAID 1 卷用于日志，可以提供比更昂贵的 RAID 10/RAID 1 选项所能提供的许多优势。

使用 RAID 5 或 RAID 10 进行数据存储，你很可能能够从单个磁盘故障中恢复。磁盘故障是你服务器最可能发生的与硬件相关的问题。

消除剩余的故障点

即使有了上面描述的 RAID 设置，仍然有多个故障点需要考虑。如果主板或磁盘控制器发生故障，你的数据可能仍在硬盘上，但直到硬件问题解决之前都无法访问。我说数据“可能”在硬盘上，因为磁盘控制器有可能以足够壮观的方式发生故障，从而导致所有数据一起丢失。

我通常从事 Web 应用程序开发，Web 协议的优点之一是消除单点故障的便利性。根据许多因素，你可以创建一个 Web 服务器集群，并在集群前面放置一个负载均衡器来分发传入的请求。HTTP 请求的无状态特性通常意味着每个单独的请求都可以由集群中的任何一台机器处理。如果用户请求项目列表，点击其中一个项目并被发送到另一台 Web 服务器，请求可以干净地处理。这忽略了诸如会话状态之类的内容，但许多 Web 技术允许在集群中的机器之间共享会话状态。

集群 SQL Server 要困难得多。要利用 Microsoft 的解决方案，你必须使用 Windows 2000/2003 Advanced Server 或 Datacenter 版本，以及 SQL Server Enterprise Edition。虽然我经常使用 Web 服务器集群，但我没有在 SQL Server 上使用过集群。我想部分原因在于这种解决方案的成本过高，以及设置的难度。

还要注意，如果你在同一物理位置的两个机器上集群 SQL Server，那么你并没有防御本系列第二部分讨论的所有类型的故障。集群不能防止灾难性的站点故障，如长时间停电、洪水和飓风。还有一些更平凡的站点故障，例如互联网连接丢失。

对于平凡的站点故障，有一些可能的解决方案。假设两个站点之间的连接正常，你可以创建一个包含实时数据库的非常近期的副本的服务器。我在关于使用 Red Gate Software 的 SQL Toolkit 同步 SQL Server 数据库的文章中讨论了一些将数据从一个 SQL Server 复制到另一个的方法。

我最近了解到的一个东西是日志传送。关于 SQL Server 复制的主题已经写了很多书，虽然它听起来可能是一个简单的解决方案，但它一点也不简单。更重要的是，它不便宜。它涉及部署最可靠的服务器，添加第二个故障转移站点，保持两个站点同步，以及管理客户端对正确位置的访问。 such a setup and configuration can easily bring your costs into the millions of dollars.

下一篇：SQL Server 数据备份的具体细节

既然你已经知道了为什么要备份、备份是什么以及如何配置硬件以最小化备份恢复的需求，下一步就是探索 SQL Server 备份的选项。应该在哪里备份？多久一次？备份后应该做什么？所有这些都将在下一篇文章中介绍。

关于 Doug Reilly

Douglas Reilly 是一名专注于 ASP.NET 和移动开发的软件开发人员。他于 2006 年 12 月在与癌症的长期斗争中去世。