概述
昨天下午突然看到，《炉石传说》游戏数据库发生宕机并引发数据丢失事故的新闻。刚看到时，满满的不可思议。暴雪啊，网易啊。
都是很牛叉的公司。他们出的游戏我都是很喜欢的。
当我看到，第一时间着手抢修，重启服务器，并尝试数据恢复时，我的想法是他们的高可用方案呢？为什么不马上切换？
当我看到相关备份数据库也出现故障时，就更无语了。其实这样的事情在我们的客户每年都会遇到很多。前不久就有一个医院， 数据库和备份都同时损坏，而且没有高可用的方案。
虽然最终帮他们修复了好数据库，但还是丢失部分数据，而且中间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 去备份的作业会马上失败。这可以让我们第一时间发现数据库页损坏的问题。
总结
不好的备份策略，可能导致灾难性的后果。 相反好的备份策略可以让我们高枕无忧。看到这里的小伙伴们赶紧去检查下，自家的备份做好了吗？否则请自习下面武功秘籍：
