你肯定已经看过了所有关于数据库备份重要性的博客文章和帖子，并相应地在你的数据库中做了应用。你现在可以高枕无忧了吗？错！

　　对你的数据库进行备份只是整个保护过程中的第一步。下一步是确保那些备份受到保护。你还需要测试这些备份，确保这些备份确实可以用来恢复数据库。在你需要使用数据库备份做恢复时，唯一比没有做备份更坏的消息是：你以为你做了，但实际上没做成功。

　　存储备份文件

　　可能最常见的数据库备份技术都会提到把数据库备份到同一台服务器的磁盘上。如果该磁盘是与你的数据库所在磁盘物理独立的RAID阵列，这没有问题。

　　既然备份是用来在可能出现的最坏情况下做恢复，那它们就需要被保护，避免受到这类灾难的损害。毕竟，如果当服务器出现故障时备份也一起丢了，这样的备份有什么用呢？

　　对这些备份有两件最常见的事情要做：备份保存到磁盘上后，要么尽快把备份转移到磁带上，要么把它们转移到另一台专门用来长期存储的服务器上。这两种方案都是可以接受的，因为你保留了第二份备份。这样的话，如果服务器坏了，原始备份也随之丢了，你仍然可以恢复数据库。

　　测试备份文件

　　在你把备份保存到另一个位置后——不管是磁带还是另一台服务器——你必须问问自己，那些备份是否能用来恢复数据库。确保你的备份可用是备份过程中重要的一步。只在维护计划中勾选“验证备份完整性”是不够的，因为它只简单地保证备份文件头正确，并没有验证整个备份的有效性。

　　确认备份真正有效地唯一方法就是用该备份执行一次恢复。当然这并不意味着你应该拿你的数据库备份把它恢复到你的生产服务器中。它只是说明你需要再某个测试环境执行一次恢复，确保整个备份和所有日志备份都是有效的。

　　要正确地做到这一点，需要有一台可用的服务器，我们要把最后一个完整备份和所有日志文件恢复到这台服务器上。虚拟机可以完美地做到这一点，因为这样会占用相当少的内存和CPU。如果你在恢复系统的过程中遇到了问题，首先识别并纠正问题，然后再用修正后的完整备份再测试一遍。

　　让备份安全

　　现在你已经可以保证服务器坏了的时候备份不会丢失，接下来你需要检查确保没有其他人可以拿到你的备份，并用备份恢复数据库，从而窃取你公司的数据。

　　保证备份安全的方法有多种，要选用哪一种取决于你执行备份时使用的技术。

　　如果是把备份存储到磁盘的情况，就在文件夹上设置NTFS许可，并使用Windows防火墙或者基于硬件的替代方案来阻止未授权的访问，这就够了。另一方面，如果你把备份存储在磁带上，并把磁带装到了一个存储设备中;或者为了把备份复制到脱机环境使用了基于磁盘的存储，那么你需要一个更复杂的安全方案来替代。

　　以这样的方式使用磁带时，大部分磁带备份方案都包含了对备份加密的方案。向你的系统管理员确认一下，看看你的磁带备份系统支持什么选项。

　　如果你备份到了磁盘上，并以脱离网络或者不支持加密磁带备份系统的方式把备份离线传递走，那么你需要在备份方案之外寻求一种加密机制了。如果你运行的是SQL Server 2008，你可以使用全数据库加密选项，它会加密数据库中的数据，这样在备份中数据也是加密的。

　　你还可以找第三方工具来加密备份。象Quest软件公司的LightSpeed for SQL Server，Idera公司的SQL Safe Backup和RedGate公司的SQL Backup这类工具在执行加密时都支持备份加密，这样就只有授权的用户才能恢复这些备份。

　　一旦对备份启用了加密机制，你还需要再修改一下测试策略。你需要确保你不使用存储在产品服务器中的任何数据，就能把备份恢复到另一台服务器。这意味着你应该把加密密钥存储到安全的位置，确保只有授权的人员可以获取到。

　　测试自动化

　　如果你准备进行测试了——基本上应该每周或每月执行——你可以努力让测试自动执行。大部分企业的备份方案有自动恢复备份的方法，它就是为这个目的而设计的。该自动化机制也会按照一定规律的时间表，通过从备份中恢复文件和（或者）数据库来测试备份。一旦自动恢复完成，自动恢复功能会发送一个状态报告的电子邮件给你，你应该检查报告内容并确认是否成功了。同时，你可以保留这封电子邮件，必要的时候提供给审计人员，作为具备备份恢复能力的证据。