编者注：Robert L Davis是微软的高级数据库管理员和专家，同时是《SQL Server》杂志的撰稿人，并合著《Pro SQL Server 2008 Mirroring》一书。

每个人都会犯错，DBA也不例外。不过DBA犯错时，通常他们也是第一个发现错误，并立刻修正错误。但，有些错误是不可原谅的，因为可能给企业造成不可挽回的损失。我将陆续介绍DBA的5大失误，这些失误会危及到数据的可恢复性、完整性和安全性，是不可原谅的错误，DBA为此可能会付出丢掉工作的代价。

DBA第一大失误：你的备份可靠吗？

DBA的首要重点工作是备份。这一点，再如何强调其重要性，都不为过。就算万事出错，你都应该确保备份是任何灾难事件中最后的一根稻草。我听到或遇到太多类似的事件，发生意外事件时，发现备份工作没有做，或者备份被损坏，无法恢复。这可能导致公司采取严厉措施规定什么样数据必须保存，并得处理数据丢失的严重后果。没有按照规定进行可靠的备份可能会让你丢掉工作。

在完美的数据世界中，DBA应该了解对恢复事件和数据丢失的要求。这两个要求通常被称为恢复时间目标（Recovery Time Objective，RTO）和恢复点目标（Reovery Point Objective，RPO），用来设计灾难恢复计划（和相应的的备份计划），以支持数据恢复。

在灾难发生时，RTO是允许你宕机的时间，RPO是允许你丢失的数据量。DBA的目标应该是尽可能将数据流失接近零。在制定灾难恢复计划的备份计划时，你应该假设所有其他级别的保护都失败，从备份中还原是你防御的最后一道防线。

如果你真的走到这最后一道防线，最后的好备份就是你将丢失的数据量。这将帮助你确认备份的频率，如果数据丢失量的要求低，你就需要频繁备份。你应该高频率备份的唯一备份类型是日志备份。这就意味要么是完整恢复模式（full recovery model），或大容量日志恢复模式（bulk-logged recovery model）。

有可靠的备份不仅仅意味着只是备份，而是指知道备份可以恢复，知道何时进行恢复。这就是测试备份的用武之地了。作为最低限度，你应该使用BACKUPVERIFYONLY命令来测试备份是否可恢复。

除了验证备份之外，我还会强烈建议使用CHECKSUM选项，对所有的备份和恢复进行验证。CHECKSUM选项执行额外的检查，可能时会确定数据库是否已损坏。如果额外的检查发现数据损坏，备份操作将失败，并提醒数据已损坏。此外，它还会对整个备份文件执行校验，这将帮助你检测是否备份文件是在创建后被损坏的。

对整个备份文件进行最后的CHECKSUM操作，最大的好处是如果备份文件本身已损坏，那么对该文件进行恢复会立刻失败。这对非常大型的数据库而言，尤为重要。因为一个还原操作可能需要花数小时。如果备份文件已经损坏，它在页头有一个额外的校验值，那么效验将在恢复操作开始之时重新计算，并很快失败。虽说找出备份文件受损的恢复时间并非好事，但远远好过经过几个小时的恢复运行才发现文件受损。

DBA能够确保备份可恢复的最好方法就是通过执行实际的恢复进行测试。理想情况下，我更喜欢结合使用自动修复备份（以确保它们有效）和运行灾备训练（演习停机情况下，DBA运行整个恢复过程）。规划和实践是当实际灾难发生时，帮助你达到恢复需求的关键所在。

我想说的是，DBA应该做的第一件事情和最后一件事情都是备份。如果我遇到新的服务器或环境，我做的第一件事情就是确保所有的服务器都有备份，并成功运行。之后，我会重新检查备份情况，基于实际的RPO和RTO需求制定一个灾难恢复计划。如果DBA没有做到第二步，还算情有可原，但是没有可靠的备份就是一个无可饶恕的失误。假如发生灾难或意外，DBA却没有可靠的备份，恐怕工作难保。