数据备份对于DBA来说是一项最基本的工作，但又是十分关键的，每个SQL Server上面执行的最重要的任务之一都是运行备份和恢复，可以说数据备份是确保数据安全的最后一道防线。在进行数据库备份时有许多不同的选项，特别是随着SQL Server新版本的不断推出，为了满足用户不断增长的需要，微软也与时俱进的引入一些新的功能，这里仅仅谈一些在备份过程中最有用的几个选项。

压缩(Compression）

备份压缩是从SQL Server 2008企业版开始出现的，SQL Server 2008 R2的标准版也开始引进的这个功能，它不仅仅能使你的备份文件变的更小，意味着占用了更少的存储空间（微软内部测试，平均压缩比5:1，注意，备份压缩率和数据库有关系，包括数据类型、数据是否加密以及表的设计等），通过网络进行备份拷贝所需的网络带宽也相应的减小，在提高你的备份和恢复操作的速度同时，相应的也就减少了停机时间，这是很有用的一个特点，当然，压缩也需要消耗资源，它要使用更多的CPU,但是对于大多数的SQL Server系统来讲，和I/O相比，CPU都应该被排到后面，建议最好是在访问的非高峰期备份时使用压缩选项；如果要在高峰期进行备份，压缩进程所消耗的额外CPU会对并发操作产生不利影响,SQL Server 2014引入了资源调控器，通过将特定SQL Server用户的会话映射到限制CPU使用的资源调控器工作负荷组，来对这些会话进行分类(详细内容请查看SQL Server联机丛书)。

复制(Copy_only)

根据需要满足的down机时间和数据丢失可以制定一个备份策略，日复一日相同的操作应该交由SQL Agent来自动完成执行。假设有一天你因为其他原因需要一个当时的数据库的完整备份，如果你进行了完整备份，那随后的所有备份(差异备份和日志备份)都会以此完全备份为新的起点，也就是说 自此次完全备份创建新的备份链，如果不想影响现有的备份策略，可以在完全备份时使用copy_only选项。

数据传输选项Buffercount和Maxtransfersize

数据库会慢慢地变大，几十个GB甚至会几个TB，这时即使压缩也会消耗掉大量的时间完成完全备份，这时建议使用并行备份——即将数据库备份到多个物理驱动器上，进一步的话我们还可以使用Buffercount和Maxtransfersize进行在备份过程中的性能优化。 BUFFERCOUNT指定用于备份操作的 I/O 缓冲区总数。 可以指定任何正整数；但是，较大的缓冲区数可能导致由于 Sqlservr.exe 进程中的虚拟地址空间不足而发生“内存不足(out of memory)”错误。

缓冲区使用的总计空间由下面公式确定：buffercount*maxtransfersize，建议备份使用的缓冲区空间是物理内存的1/16。当执行备份和恢复操作时可以使用trace Flag 3213查看你的备份和恢复参数。

MAXtrANSFERSIZE是指定要在 SQL Server 和备份介质之间使用的最大传输单元（字节）。 可能的值是 65536 字节 (64 KB) 的倍数，最多可到 4194304 字节 (4 MB)。如果备份的缓冲取空间超出了1/16物理内存的大小，建议调整Buffercount和Maxtransfersize的值达到要求。

描述和文件名(Description和Names)

适当的保存备份文件看似对于很多人来讲都不为重视，比如说应该保留多长时间周期的备份文件，一些人为了简单化，就保留了最近一份的备份，显然，这也有可能在恢复时带来灾难，原因是你的备份文件中的数据是正确的吗？完全可以因为你备份时驱动器的问题导致数据失败，如果避免这样的情况发生，我们就可以通过保留多个数据库备份，可以通过恢复页来保证数据的安全有效。一般建议保留4个备份周期的文件。这又可能带来一个问题，可能你的磁盘上堆积了大量的文件，如果没有正确的命名，如果需要你在紧急情况下恢复数据库你就有可能变得手忙脚乱（当然，你可以查看各个日子文件的LSN来确认恢复顺序），所以建议在备份时为备份添加适当的描述和文件名就很有帮助，比如说20130609_1330_SalesDB_Log.bak ，从名字一目了然就可以看出备份时间、哪一个数据库和备份类型，同样你也可以使用描述Description，通过添加适当的描述，为将来(比如恢复)时提供更多的有用信息。

加密

如若说你的数据库备份丢失，也会带来安全问题，考虑到之前某著名网站的用户信息泄露事件，就是因为备份的数据库文件丢失造成的，当然，保存在一个安全的地方也是一个要考虑的问题，但是在现在的网络环境下，还需要文件本身的安全，这就是对数据库备份进行加密，在SQL Server 2014之前对数据库备份的加密一般通过对整个数据库加密或者使用第三方备份加密工具，但是都有一定的问题存在(请参看：SQL Server 2014新特性-原生备份加密http://www.cnblogs.com/CareySon/p/3853016.html)，而SQL Server 2014引入的加密功能对数据安全提供了非常好的解决方案，主要是因为SQL Server的备份加密基本不会增加备份文件的大小，并且在一般情况下，除了使用3DES算法的加密外，其他的AES算法加密对CPU也不会造成瓶颈问题。

校验和Checksum

这个选项有两个作用：

1、从数据文件读取数据页时，用来验证他们的页面校验和，如果发现无效的校验和现，默认情况下备份将会失败并产生一个具体页面损坏的信息

2、计算整个备份文件的校验和并存储在备份文件的头部

注意随着时间的推移频繁的读写数据对于I/O子系统来讲会比较容易的损坏磁盘上的数据文件和日志文件包括备份文件，这时虽然不会影响数据库的访问，但是当你需要读取损毁的页面时，SQL Server会报告损害的信息；所以说对于一个合格的DBA来讲，仅仅进行简单的备份是不够的，同时还要保证备份文件的完整性，页面校验和是在数据页从磁盘读出再被写入磁盘时进行的检查，对于SQL Server来讲是用来确认I/O子系统已经损坏了一个数据页的一种方法。

状态Stats

这个选项可以使备份时显示完成的进度，默认是每完成10%改变一下进度显示，你也可以使用Stats=X来指定，当你对一个大的数据库进行手动备份时这个选项就特别有用，可以提示你备份的进度，同样这个选项在恢复Restore数据库时也同样适用。

备份到URL

把SQL Server 备份到 URL实际上是将数据库备份到Windows Azure Blob 存储服务中。首先需要创建 Windows Azure 帐户,这个功能自从SQL Server 2012 SP1 CU2 就开始支持，不过只能通过 transact-SQL、PowerShell和 SMO实现此功能。在SQL Server 2014 中，最大的变化就是 SQL Server Management Studio 界面上开始支持备份到 Windows Azure Blob 存储服务或从中还原。

原文链接：http://www#qdjch#com/?p=788

关于作者

姜传华，长期从事数据库的教学、设计、开发和应用管理工作，有着20年以上的IT工作经历，深刻理解关系数据库原理及SQL Server体系架构。同时也活跃于Microsoft的各大论坛网站。

个人博客：http://www#qdjch#com/

联系方式：qdjch#hotmail.com（将#修改为@）