让我们回首上半年IT领域数据相关的几个事件，对数据备份的重要性重新加深一下认识：

2017年1月 MongoDB黑客赎金事件，发现了一些在互联网上用户的MongoDB没有任何的保护措施，被攻击者把数据库删除了，并留下了一个叫 WARNING 的数据库。“老子把你的MongoDB里的数据库给转走了，如果你要你的数据的话，给我0.2个的比特币（大约USD200）。”

2017年2月 GitLab一名疲惫不堪的系统管理员在荷兰工作到深夜，他在令人沮丧的数据库复制过程中不小心删除了一台不该删除的服务器上的目录：他彻底删除了一个含有300GB活动生产数据的文件夹。更为悲剧的是定时备份和云端的备份都无效。

2017年4月 云托管服务提供商Digital Ocean重蹈GitLab在2个月前的覆辙：因粗心大意而出乱子，删除了一个生产级数据库，结果引发了持续五个小时的故障。

 

2017年6月 位于荷兰海牙的一家云主机商 verelox.com，一名前任管理员删光了该公司所有客户的数据，并且擦除了大多数服务器上面的内容，客户数据恢复希望渺茫。

 

对于这些频繁发生的事件，让我们更为深刻的认识到了DBA 守则的第一条：有效的备份重于一切。

 

深感急迫需要改进和完善备份工作，DBA对于备份做如下优化：

1.备份删除优化     以前的删除是根据时间一刀切，删除30天前的所有文件。     现在，根据SQL Server备份恢复的原理，数据库还原要基于完备，我们将删除策略调整为删除30天前最近的一次完备之前的所有文件。

2.备份连续性验证     读取当前时间之前最近的一次完备及之后的所有日志备份，判断LSN的连续性。

完备的LastLSN在接下来的日志备份的FirstLSN和LastLSN之间；日志备份的FirstLSN与上一个日志备份的LastLSN一致。

 

3.备份可用性验证    

轮训近一天的所有备份文件，RESTORE VERIFYONLY验证备份文件的可用性。

4.备份恢复验证     考虑到资源不足，将一次验证一个库，数据库按队列验证，读取当前时间之前最近的一次完备及之后的所有日志备份，做备份恢复操作。最后RECOVERY恢复出数据库，判断状态，并DBCC CHECKDB检查。

恢复验证的数据远程UNC路径挂载在远端，验证完一个库后，立即清理，避免空间占用。

5.备份历史和作业历史自动清理     可配置不同粒度定期清理存储在msdb里的备份历史和作业历史数据，减少msdb的IO瓶颈。

 

基于以上5点，打造完整的数据备份体系，为数据的有效使用保驾护航。

-------------------------------------------------------------------------------------------

二期计划：

1. 各数据库日志备份空间占用、比对前一日日志备份空间占用增长百分比，发送日报邮件。

2. 日志备份后增加步骤，以下条件发告警邮件：

   1. 当前日志备份文件大于100MB，并且相比前一个日志备份文件的增长百分比大于20%；

   2. 当前日志备份文件大于300MB。

3. 可选自动化恢复数据库到某个时间点，可作为搭建离线环境或历史数据查询。

4. 恢复验证数据库到某个时间点，可作为自助定制验证。

-------------------------------------------------------------------------------------------

备份策略及备份验证体系：