如果你做DBA时间不长对数据库的备份有些担心希望能找到一种让你放心的备份方案那么本文绝对适合你
关于数据库的备份恢复原理大家多少都比较熟悉了但是你目前做的数据库备份有多可靠?你可以安心睡觉了吗?如果答案是肯定的那就不用多花时间看下文了如果觉得还不够安心总担心数据库哪一天坏了修不好那么请接着看
我有RAID还需要做数据库备份吗?需要有了RAID万一部份磁盘损坏可以修复数据库有的情况下数据库甚至可以继续使用但是如果哪一天你的同事不小心删除了一条重要的记录怎么办?RAID是无能为力的你需要合适的备份策略把那条被误删的数据恢复出来所以有了RAID仍需要做备份集群磁盘镜像同理
如果你只做全备份那么受限于全备份的大小和备份时间不可能常做而且只有全备份不能将数据库恢复至某个时间点所以我们需要全备份+日志备份比如每天一个全备份每隔小时或若干分钟一个日志备份说到差异备份因为微软的差异备份记录的是上一次全备份以来发生的变化所以如果数据库的改动很频繁的话没过多久差异备份就会和全备份的大小接近因此这种情况下就不合适了因此全备份+日志备份的方案适合绝大多数的用户
如果你仅在数据库本地做备份万一磁盘损坏或者整个服务器硬件损坏备份也就没了就没法恢复数据库因此你需要把备份文件传送至另一个物理硬件上大多数用户不用磁带机因此不考虑一般我们需要另一台廉价的服务器或者PC来存放数据库的备份来防止硬件损坏造成的备份丢失
你可以在数据库服务器本地做完备份然后使用某些方式将备份文件传送至备机你是在备份完成后就马上穿送的吗?其实可以考虑将传送备份的脚本用TSQL语句来写
备份文件传送至备机后就可以高枕无忧了吗?不作为DBA的你还需要检查备机上的备份文件是否能将数据库恢复至最新如果采用日志备份会不会因为丢失某一个日志备份文件而导致数据库不能恢复至最新?如何检查日志备份文件之间存在断档?
为了将数据库尽可能的恢复到最新你可能会每隔分钟(甚至分钟)执行一次日志备份那么万一数据库坏了在恢复的时候手动恢复成百上千个日志文件是不是不太现实?
如果你所在公司有很多的数据库服务器(就像我所在的公司)而且磁盘空间有限那么你不得不经常登录服务器来删除旧的备份文件如果哪天忘了或者五一十一长假磁盘空间用完了就麻烦了
数据库在备份的时候并不会检查数据页面的完整性如果数据页坏了备份作业仍会执行而且不会报错等到你发现数据页有错误的时候你也很可能已经因为磁盘空间不足而删除了早期的备份而此时剩下的那些备份可能都是包含损坏的数据页如果损坏的数据页是某个表的表头的话那这个表你就再也没办法恢复了
所以你需要定期执行DBCC检查来尽早发现数据库页面的完整性在未作完DBCC检查之前你不能删除旧的备份以防止新的备份存在问题所以删除备份文件的工作变的有些麻烦
你可能知道SQL Server提供了数据库维护计划没错使用它可以定期做备份执行DBCC检查但这一切仅限于本机操作为了使数据库可靠你还是需要自己把本地备份传送至备机
综上你的备份做好了吗?检查了吗?删除旧的备份是不是花去你很多时间特别是在网络条件不好的时候?如果数据库备份文件的传送在某一时刻停止了你多久才能发现?公司值晚班的同事有权限检查数据库的备份情况吗?
