误区 #30：有关备份的30个误区
全是错的
在开始有关备份的误区之前，如果你对备份的基础没有了解，请看之前我在TechNet Magazine的文章:SQL Server误区30日谈-Day27-使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB

30-15)可以备份数据库快照
不可以，虽然我也希望可以备份数据库快照。

30-16)可以使用数据库镜像来替代日志备份
不，只有在数据库镜像所基于的数据库可用时，镜像才可用。如果数据库本身被损坏，镜像一般也不会幸免。而数据库本身suspect,数据库镜像往往也会suspect。
当然，由于当数据库中页被修改时，也需要被同步到镜像，因此存在多个镜像对数据库性能的影响会非常大。此外，当数据库中被修改的部分越来越多时，镜像也会不断膨胀。因此无法用镜像代替日志备份。

30-17)日志备份所占的大小会和日志所占的大小一致
错误。日志中包含了需要回滚活动事务的日志。DBCC SQLPERF (LOGSPACE)所体现出来的日志空间使用并不能正确反映出日志条目所占的空间。Search Engine Q&A #25: Why isn\'t my log backup the same size as my log?。此外，需要备份的日志部分往往是自上次日志备份以来所有的日志。如果日志大于自上次日志备份以来所有的日志，说明还有长时间活动未结束的事务。

30-18)无法备份损坏的数据库
错误，你可以使用WITH CONTINUE_AFTER_ERROR选项来备份损坏的数据库（如果这个选项还不行，可能是boot页或文件头页损坏了），这也是除了OS级别之上的SQL SERVER备份损坏数据库的唯一办法。

30-19)你不能禁止别人进行BACKUP LOG .. WITH NO_LOG 和TRUNCATE_ONLY操作
错误，在SQL Server 2005中，的确是这样，但是在SQL Server 2008中，你可以通过跟踪标记3231来实现这一点。

30-20)日志备份无论在什么条件下都会清除日志
错误。如果日志备份的同时并没有并行执行数据库备份，则日志备份会尝试清除不活动的VLF。对于SQL Server的角度来说，那些没有备份的日志是也就是SQL Server所必须的日志，这类日志不能被清除。因此对于某些特殊情况，虽然进行了日志备份，但SQL Server仍然认为这些日志是必须的，SQL Server会不断检查这些日志直到认为这些日志不再必须，我在TechNet杂志的一篇文章对此有详细的探讨:Understanding Logging and Recovery in SQL Server。

30-21)差异备份是增长式的
错误,差异备份所备份的数据是自上次完整备份后所有修改的数据区-所以是积累性质的(译者注：比如说在期间你对用一个数据区进行多次修改，差异备份的大小不会变)。只有日志是增长式的。虽然很多人认为差异备份是积累性质的，但实际不是。

30-22)当备份完成时，你就可以删除前一个备份了
No. No. No.
如果当你还原时发现完整备份已经损坏，此时你就该束手无策了吧。如果此时你没有前一个完整备份，你还是赶紧去招聘网站更新简历吧。你需要按照策略多留几个备份，这样就能有备无患了。

30-23)可以备份镜像数据库
错误，镜像(Mirror)只能通过数据库快照访问。对其也不能进行备份。

30-24)你可以单独备份一个表
错误，如果凑巧这个单独表在一个文件组上，那么你可以通过备份文件组来达到这个目的，但没有所谓的:BACKUP TABLE。

30-25)备份数据需要关闭SQL Server
这个，我真不知道这个谣言从哪来的。(编辑:显然从Oracle来的，因为我们都知道和SQL Server比起来Oracle要强很多:-)。

30-26)正在执行的事务只要在备份完成之前提交就一定会包含在这个备份中
错误，只有在备份的数据读取阶段完成之前提交并写入磁盘的事务才会包含在备份之。详情请看:Search Engine Q&A #6: Using fn_dblog to tell if a transaction is contained in a backup。

30-27)在备份之前收缩数据库可以减少备份的大小
错误，收缩仅仅是移动页，并不会引起备份大小的改变。详情请看:Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup。除此之外，还有一篇博文:SQL Server误区30日谈-Day9-数据库文件收缩不会影响性能。不但如此，还有人提醒我说，如果在完整备份之后进行了数据库收缩，则即使数据没有改变，下一次差异备份也会变得巨大。

30-28)从备份进行恢复是当灾难发生时最好的办法
错误，只有当0数据损失时，备份才是灾难恢复最好的办法。但要减少DownTime由备份进行还原并不是一个好办法，如果业务允许，故障转移或允许一些数据损失会更好。

30-29)不需要备份master, msdb, model...等几个系统数据库

错误，这几个系统数据库是需要进行备份的。Master数据库包含了安全信息以及实例上存在哪些数据库。MSDB数据库包含了SSIS的包，代理任务，备份历史。Model数据库包含了新建数据库的模版。不要仅仅只备份用户数据库，否则从头开始配置实例将会非常痛苦。

30-30)你需要一个好的备份策略

错误

我猜想你一定会说”什么”?你需要的是一个好的还原计划，而不是备份计划。根据业务需求和技术限制来决定什么时间还原什么，再根据还原来决定应该什么时间备份什么。请看下面两篇文章:

• Importance of having the right backups
  
• Planning a backup strategy - where to start?
  

很多人都做了一个备份策略，但不测试也不想怎么还原。当灾难发生时导致无法还原，希望你不是这样。