你的 SQL Server 备份做好了吗?可以安心睡觉了吗?

你的 SQL Server 备份做好了吗?可以安心睡觉了吗? - 故障解答 - 电脑教程网

你的 SQL Server 备份做好了吗?可以安心睡觉了吗?

日期:2006-10-10   荐:
如果你是一位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检查,但这一切仅限于本机操作。为了使数据库可靠,你还是需要自己把本地备份传送至备机。

综上,你的备份做好了吗?检查了吗?删除旧的备份是不是花去你很多时间,特别是在网络条件不好的时候?如果数据库备份文件的传送在某一时刻停止了,你多久才能发现?公司值晚班的同事有权限检查数据库的备份情况吗?

如果有兴趣的话,可以尝试使用我的解决方案,花一点小钱,帮你解决以上所有问题,让你安心睡觉。
本人多年从事MSSQL的管理和开发,曾在上海多个高校及培训中心讲授相关课程。对MSSQL有较好的认识和理解,以及较丰富的工作经验,N次的将数据库从灾难中恢复出来。
现在和朋友一起设计了一款针对MSSQL的备份恢复系统。该系统安全可靠,第一版本已经在我目前工作的公司运行了一年,近50台MSSQL服务器,已经历了多次的数据库灾难,每次都成功的救回了数据库。目前设计的第二版,采用第一版的核心技术,根据第一版的使用反馈,融入了很多更可靠、管理更轻松的理念,是我本人和一些同行都感到较为满意的一个产品。使用该产品:

[1] 你可以安心睡觉了。如果不放心的话,尽管测试,把各种可能的灾难都测试几遍,就放心了。
[2] 可靠安全。系统会检查备机上的备份文件,分析这些文件的内部信息,并报告可以将数据库恢复到什么时刻,如果可恢复时刻与数据库当前时刻的差达到预定义的值(比如某一时刻起网络故障导致备份文件无法传送至备机),就会报警,这样你就有尽可能多的时间来排除故障。
[3] 最大程度减少工作量。所有数据库服务器的备份信息和可恢复信息都集中在一台主控制机上显示,不用逐个登录检查。系统自动执行备份,自动执行检查,自动删除旧的备份,保证磁盘上剩下的备份文件能将数据库恢复至最新。所以,如果数据库备份正常,你不用做任何维护操作,只需有人看着主控制机显示器的报告信息,就足够了。
[4] 万一数据库坏了,主控制机会提供给你恢复数据库所需的脚本,用于将数据库恢复至最新/恢复至时间点/恢复成另一个数据库。你可以方便的将该脚本粘贴到备机的Terminal服务器上执行。如果你的恢复策略中需要执行上千个日志文件的恢复,没有问题,这些脚本都会由主控制机提供,不需要任何的改动,只需要运行就可以了。

我和公司的劳动合同马上要到期了,之后,打算暂时不找新的工作,推广我的备份恢复系统,希望给广大的朋友提供方便的同时,自己也能得到些许回报。
相信很多高手也有自己的备份方案,但相信也有很多入门不久的朋友,需要一个可靠的备份方案,数据库的备份恢复是个不算简单的问题,要保证可靠的话,需要投入很多的时间和精力去学习,还可能需要一些经验的积累。有的朋友可能也不是以数据库为主,也不打算在这方面花太多的时间,所以我的产品应该是有一定的市场的。但是我也不想打没有准备的仗,所以在此先提出这样的想法,想听听大家的意见和建议。

[1] 有兴趣使用我介绍的这款备份恢复系统吗?
[2] 你已经找到类似的替代品了吗?收费的还是免费的?
[3] 如果该产品能满足你的需求,你愿意承担的价位是?

如果有兴趣的话,可以发送邮件至 [email protected] 索取演示版,邮件中麻烦回答一下上述的3个问题。谢谢!另外,本人承接企业培训项目。
标签: