显然，人们仍然没有认识到SQL Server数据库备份事实上是运行SQL Server数据库最重要需求之一。最近，Twitter上面有一个讨论，关于他们从未备份过的数据库崩溃了。

　　有些人看起来并不理解服务器硬件失效并不是关于一个硬件是否会失效的问题，而是何时失效的问题。如果您没有(已经验证有效的)备份，那么您仍然没有做好足够的应对硬件失效的善后措施。如果您目前已经使用SQL Server一段时间了，而且一直以来都没碰上硬件失效，那么请记住一个简单的事情……硬件失效将不期而至，而且当它来临时，您将深受其害。

　　但是我在一个小型公司工作，我们无法负担备份。

　　如果您在一个小型公司工作，那么进行备份更加重要。如果您的公司是一个小型公司，那么它能够承担得起SQL Server数据库丢失数据的损失吗?公司重建所有的数据将需要多少费用?如果您丢失了数据库中存储所有的合同，那么公司又该损失多少?如果数据库中的数据丢失了，那么您所所在的公司仍然能够开展业务吗?如果数据库中的数据丢失了，作为系统管理员或者DBA的您能够逃脱被开除的命运吗?

　　对于大多数的问题，我无法给您答案，但是最后一个例外。如果我是您的经理，而且您对于我们所进行的业务没有进行备份，而系统又失效了，那么您必将羞愧地被开除。而作为您的经理，毫无疑问我也将在一个小时之后与您一样流落街头，因为我没有确认您已经对公司运行的数据进行备份。

　　但是我不知道如何备份。

　　建立备份并不是总是很难或很复杂。对于只有几台数据库服务器的公司，您并不需要很大型的复杂备份解决方案，或者编写复杂的脚本。使用数据库维护计划向导就可以很好地实现数据库备份。大型公司的员工并不喜欢使用它，我本人以及其他的MVP也对此方法颇有微词，因为它无法扩展到大量服务器的环境上。但是，只要它们能够实现备份，对您而就足够了。

　　假设您需要尽可能少地丢失数据，那么您希望将您的数据库转变成完全恢复模式(不是系统数据库，而只是您的用户数据库)。那么，每天或每周定期使用事务日志来建立完全备份。这种情况下，您需要请示您的经理或公司老板，您可以容许多少数据丢失。您可以根据这一点来确定建立事务日志备份的频率。