要备份SQL Server数据库的时候，除了那些通常的例如磁带容量和备份时间窗之外，还有很多因素需要考虑到。在这个技巧中，你可以学到应对那些常见的SQL Server数据库备份问题的方法。

　　软件兼容性需要在升级之前解决

　　SQL Server数据库备份的一个主要问题是备份应用的兼容性问题。一些和SQL Server 2008一起工作的很好的备份应用和SQL Server 2008 R2会有很大的兼容性问题。

　　一个例子就是赛门铁克公司的Backup Exec 12.5。如果你在尝试备份一个SQL Server 2008 R2服务器，你会看到一个错误信息说“尝试浏览微软SQL Server内容时遇到错误。”如果你最近升级到了SQL Server 2008 R2，保证你的备份软件是兼容的并在升级之后也可以使用就很关键了。

　　留意备份压缩的影响

　　微软推出SQL Server 2008的时候，他们引入了一个新的备份压缩功能。最早压缩备份功能只在SQL Server 2008企业版中才有，但后来微软把这个功能加入了标准版的SQL Server 2008 R2。

　　备份压缩的效果不一，取决于SQL Server数据库中所包含的数据类型。但是我看到过超过60%的压缩。除了备份尺寸的缩减，备份压缩功能还可能通过减少产生的磁盘I/O而降低备份花费的时间。

　　但是压缩的好处是有代价的。备份压缩非常占用CPU。实际上，看到基本CPU利用率在压缩备份的时候上升400%都是不稀奇的。不过要注意那不一定对所有的压缩备份都一样。对服务器CPU的影响随可以压缩的数据的量的大小而变化。

　　SQL Server比较偏向于一个是CPU密集型的应用，所以很重要的一点是要权衡带来的好处和对任何功能的可能的影响，以及可能的增加的CPU利用率。如果SQL Server运行在一个有很多资源的物理服务器上，那么一个压缩的备份可能会使得服务器在备份进行的过程中变慢，不过使用压缩通常不会带来灾难性的问题。

　　对运行在虚拟机中的SQL Server就可能不一样了。在一个虚拟环境中，多个虚拟机分享一个物理服务器的硬件资源。理想状态下这些资源的共享方式应该是避免一个虚拟的任务高峰对同一个服务器上运行的其他虚拟机造成影响。

　　问题是虚拟机服务器的卖点是，他是降低硬件成本的一种方法。在它尽其所能进行节省的过程中，多数的IT部门都会过度利用他们的硬件资源（特别是CPU和内存）以便达到每个宿主服务器上的虚拟机密度最大化。

　　过度使用CPU资源在CPU的工作量可以预测，而且做过充分的容量计划以保证CPU核不会工作过量的情况下，通常不会成为一个问题。不过如果你在一个运行在CPU过度使用的主机上的虚拟化SQL Server中，突然引入一个和备份压缩相关的繁重工作，备份工作会明显地影响在宿主服务器上运行的其他虚拟机。

　　应对数据库一致性避免数据库损坏

　　尽管较新版本的SQL Server比一些较早版本在保持数据库一致性方面做得好些，一致性在高事务性的环境中还是可能成为一个问题。底线是数据库一致性需要在进行备份之前处理，这样你就不会最后备份的是损坏了的数据。

　　帮你保证数据库一致性的一个方法是使用SQL Server 2008 R2的维护计划向导。维护计划向导可以被用来创建SQL Server 代理任务来在你的数据库里执行内部一致性检查，来发现数据损坏的迹象。这个向导也可以被用来自动化其他的任务，例如重建索引，删除空数据库页，更新索引统计，和运行备份任务。

　　SQL Server会在可能的情况下尝试自动修理数据损坏，但是有的时候损坏范围过大，以至于SQL无法修复，或者有的时候你在尝试恢复的时候才发现备份包含了损坏的数据。在这些情况下，你可能不得不使用第三方工具，例如Office Recovery来修复那些损坏的数据。