码迷,mamicode.com
首页 > 数据库 > 详细

SQL SERVER 运维日记-数据库备份

时间:2017-04-18 20:03:28      阅读:231      评论:0      收藏:0      [点我收藏+]

标签:数据库备份   解决方案   数据恢复   服务器   小伙伴   

概述

 

昨天下午突然看到,《炉石传说》游戏数据库发生宕机并引发数据丢失事故的新闻。刚看到时,满满的不可思议。暴雪啊,网易啊。

都是很牛叉的公司。他们出的游戏我都是很喜欢的。

技术分享

 

 当我看到,第一时间着手抢修,重启服务器,并尝试数据恢复时,我的想法是他们的高可用方案呢?为什么不马上切换?

当我看到相关备份数据库也出现故障时,就更无语了。其实这样的事情在我们的客户每年都会遇到很多。前不久就有一个医院, 数据库和备份都同时损坏,而且没有高可用的方案。

虽然最终帮他们修复了好数据库,但还是丢失部分数据,而且中间1天时间,业务都是手动操作,严重影响业务。

对于炉石这样的大公司,对应的方案应该是做得很全的,本次事故也可能是有其他的原因。

 

分析

这个原因暂且不论,当遇到同样的问题时,相关的运维和DBA都是很绝望的。总结下上面的问题:

1.缺乏高可用方案

2.制定更好的备份的策略

 

解决

 有小伙伴提到高可用性,这里没有写。主要高可用 方案太多,在一篇文章难以说清楚,所以本文先给出备份的解决方案。

下面给出我之前给某外企制定的备份策略,可以解决上面提到的备份的问题。小伙伴们可以参考下:

备份的位置

1.本地的备份,放置于和数据库文件不同的物理磁盘

2.异机备份。使用自动同步软件实时把备份同步到专门的NAS

3.异地备份(可选)

 

 

备份方式

首先,恢复模式强烈建议使用完整模式。为了保证数据库损坏时,能最快速度恢复业务。

1.每周全备  

2.每天差异

3.每半小时日志

备份的频率根据具体的业务情况可自行调整。

 

备份的选项

到目前为止我们的备份策略看上去很完美了。可事实是这样的吗?答案是否定的。

我们做好了看似完美的备份。但是如果我们的数据库本身已经存在页损坏,那么我们的做再多备份也是徒劳。因为备份的文件也是损坏的。

那我们如何解决呢?最好的方法就是定期还原备份,然后立即运行DBCC CHECKDB。如果当时条件不允许持续还原和检查,那么使用RESTORE VERIFYONLY命令就是你另一个最好的选择了。但是RESTORE VERIFYONLY并不是单独使用的。它必须配合WITH CHECKSUM.意思就是,在BACKUP 的使用使用WITH CHECKSUM 参数,然后定期对备份的文件运行RESTORE VERIFYONLY 来验证备份文件的有效性。如果数据库中的某些页面损坏,使用WITH CHECKSUM 去备份的作业会马上失败。这可以让我们第一时间发现数据库页损坏的问题。

举个栗子:

BACKUP DATABASE AdventureWorks TO DISK = ‘G:/backups/AdventureWorks_full.bak‘ WITH CHECKSUM

假如你更改文件数据备份文件,然后在那个文件上运行RESTORE VERIFYONLY的话,会产生如下提示:

Server: Msg 3189, Level 16, State 1, Line 1 
Damage to the backup set was detected. 

Server: Msg 3013, Level 16, State 1, Line 1 
VERIFY DATABASE is terminating abnormally.

设备 ‘d:\tttttt.bak‘ 上的介质簇的结构不正确。SQL Server 无法处理此介质簇。

报警

备份有可能因为各种原因而失败,比如备份磁盘的空间满了,等数据库损坏的时候,突然发现备份任务失败了,再完美备份策略 百搭。所以对备份任务,增加邮件报警机制,如果备份失败了,可以第一时间知道并解决。


SQL SERVER 运维日记-数据库备份

标签:数据库备份   解决方案   数据恢复   服务器   小伙伴   

原文地址:http://zhangtaoze.blog.51cto.com/12776936/1917106

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!