如果你是一位DBA老手，在看完我的文章后，如果发现有错误之处，欢迎批评指正。
如果你做DBA时间不长，对数据库的备份有些担心，希望能找到一种让你放心的备份方案，那么本文绝对适合你。
关于数据库的备份恢复原理，大家多少都比较熟悉了。但是，你目前做的数据库备份有多可靠？你可以安心睡觉了吗？如果答案是肯定的，那就不用多花时间看下文了，如果觉得还不够安心，总担心数据库哪一天坏了修不好，那么请接着看：
[1] 我有RAID，还需要做数据库备份吗？需要。有了RAID，万一部份磁盘损坏，可以修复数据库，有的情况下数据库甚至可以继续使用。但是，如果哪一天，你的同事不小心删除了一条重要的记录，怎么办？RAID是无能为力的。你需要合适的备份策略，把那条被误删的数据恢复出来。所以有了RAID，仍需要做备份。
集群，磁盘镜像同理。
[2] 如果你只做全备份，那么受限于全备份的大小和备份时间，不可能常做。而且只有全备份，不能将数据库恢复至某个时间点。所以，我们需要全备份+日志备份。比如每天一个全备份，每隔1小时或若干分钟一个日志备份。说到差异备份，因为微软的差异备份记录的是上一次全备份以来发生的变化，所以，如果数据库的改动很频繁的话，没过多久，差异备份就会和全备份的大小接近，因此这种情况下就不合适了。因此，全备份+日志备份的方案适合绝大多数的用户。
[3] 如果你仅在数据库本地做备份，万一磁盘损坏，或者整个服务器硬件损坏，备份也就没了，就没法恢复数据库。因此，你需要把备份文件传送至另一个物理硬件上。大多数用户不用磁带机，因此不考虑。一般，我们需要另一台廉价的服务器或者PC来存放数据库的备份，来防止硬件损坏造成的备份丢失。
[4] 你可以在数据库服务器本地做完备份，然后使用某些方式将备份文件传送至备机。你是在备份完成后就马上穿送的吗？其实可以考虑将传送备份的脚本用T-SQL语句来写。
[5] 备份文件传送至备机后，就可以高枕无忧了吗？不。作为DBA的你还需要检查备机上的备份文件是否能将数据库恢复至最新，如果采用日志备份，会不会因为丢失某一个日志备份文件而导致数据库不能恢复至最新？如何检查日志备份文件之间存在断档？
[6] 为了将数据库尽可能的恢复到最新，你可能会每隔10分钟（甚至1分钟）执行一次日志备份，那么万一数据库坏了，在恢复的时候，手动恢复成百上千个日志文件，是不是不太现实？
[7] 如果你所在公司有很多的数据库服务器（就像我所在的公司），而且磁盘空间有限，那么你不得不经常登录服务器来删除旧的备份文件，如果哪天忘了，或者五一十一长假，磁盘空间用完了，就麻烦了。
[8] 数据库在备份的时候，并不会检查数据页面的完整性，如果数据页坏了，备份作业仍会执行，而且不会报错，等到你发现数据页有错误的时候，你也很可能已经因为磁盘空间不足，而删除了早期的备份，而此时剩下的那些备份可能都是包含损坏的数据页，如果损坏的数据页是某个表的表头的话，那这个表你就再也没办法恢复了。
[9] 所以你需要定期执行DBCC检查，来尽早发现数据库页面的完整性。在未作完DBCC检查之前，你不能删除旧的备份，以防止新的备份存在问题。所以，删除备份文件的工作变的有些麻烦。
[10] 你可能知道SQL Server提供了数据库维护计划。没错，使用它可以定期做备份，执行DBCC检查，但这一切仅限于本机操作。为了使数据库可靠，你还是需要自己把本地备份传送至备机。
综上，你的备份做好了吗？检查了吗？删除旧的备份是不是花去你很多时间，特别是在网络条件不好的时候？如果数据库备份文件的传送在某一时刻停止了，你多久才能发现？公司值晚班的同事有权限检查数据库的备份情况吗？
做为一名工作多年的 DBA，以前我自己写一些语句和工具来完成备份，现在我使用“爱数备份软件2007”来完成这些工作，2006年公司有过几次数据库灾难，每次都成功的救回了数据库。使用这么久，我发现它有几大特点：
-
完全备份＋日志备份整合非常优秀，实现了数据库小粒度的增量备份。
-
按时间点的恢复，我们不用考虑恢复到数据库崩溃前需要恢复哪些日志文件。
-
可以设置保留最新N个全备份的版本，自动删除老版本的备份数据。
-
每个全备份带有N个日志备份。恢复灵活性很大。
-
可以设置备用的备份目的地，这样就不用担心放假时备份空间被消耗掉。
-
可以将备份数据加密、压缩等。
-
可以将数据备份到异地，甚至远程的FTP服务器。
爱数备份软件2007还有其它许多优点，功能也非常的强大，比如文件和邮件的备份，以及服务器系统的在线备份。大家有时间可以去 down 一个下来体验体验。网址：www.eisoo.com。
