title: MSSQL-最佳实践-数据库备份链
在SQL Server备份专题分享中，前两期我们分享了三种常见的备份以及备份策略的制定，在第三期分享中，我们将要分享SQL Server的数据库备份链。完整的数据库备份链是保证数据库能够实现灾难恢复的基础，如果备份链条被打断或者备份链条上的文件损坏，势必会导致数据恢复不完整或者不能满足预期，而造成数据丢失，危害数据完整性生命线，后果非常严重。所以，理解SQL Server数据库备份链非常重要。
<a href="http://mysql.taobao.org/monthly/2017/11/03/">MSSQL· 最佳实践· SQL Server三种常见备份</a>
<a href="http://mysql.taobao.org/monthly/2017/12/05/">MSSQL · 最佳实践 · SQL Server备份策略</a>
在开始今天关于SQL Server数据库备份链的分享之前，我们还是以上一期SQL Server备份策略分享的场景引入。假设我们存在如下图所示的备份文件列表，为什么我们就可以使用“全备 + 差备 + 日志备份”来实现快速的数据库还原操作呢？我们又是如何快速的查找到TestDR数据库的备份链条，并以此来还原的呢？这两个话题是我们今天要解答和解决的。
TestDR数据库备份文件列表如下图所示：
在解决今天的问题之前，我需要首先介绍一个非常重要的概念：LSN。SQL Server的每一个事务日志都有自己的唯一标识号Log Sequence Number(简写为LSN)。LSN会随着时间的推移和事务日志的产生而不断增大。那么在SQL Server中如何查看以及有几种类型的LSN呢？
在SQL Server中，查看备份的LSN非常简单，我们可以使用RESTORE HEADERONLY命令跟上备份文件路径，即可查看。
执行的展示结果如下：
从以上截图红色方框中我们可以看出来，SQL Server的LSN分为以下四类：
FirstLSN：备份集中第一个事务日志的LSN；
LastLSN：备份集中最后一个事务日志的下一个LSN；
CheckpointLSN：最后一个Checkpoint发生时的LSN；
DatabaseBackupLSN：最后一个FULL Backup备份的LSN。
LSN是查找SQL Server 数据库备份链不可或缺的神一般存在的关键信息。我们可以利用前面讲到的四类LSN，使用如下五步骤来实现SQL Server备份链的查找。
获取Full Backup: 查找最新一个FULL Backup文件，拿到对应CheckpointLSN；
获取Diff Backup：查找Diff Backup文件，Diff Backup文件的DatabaseBackupLSN等于第一步中的CheckpointLSN，如果有多个Diff Backup文件，取FirstLSN最大者，然后拿到相应LastLSN；
获取第一个Log Backup：查找第二步中的LastLSN位于Log Backup文件的FirstLSN和LastLSN之间的Log Backup，并获取相应的LastLSN；
获取下一个Log Backup: 下一个Log Backup文件的FirstLSN等于第三步中获取到额LastLSN；
获取第N个Log Backup：按照步骤四中的方法查找，直到所有日志文件查找完毕后，一个完整的备份链条查找完毕。
以上的理论解释稍显枯燥，我们用具体的示例来解释，就显得更为丰满和易于理解。我们把“场景引入”中的十五个备份文件，参照“备份文件LSN”中的方法来获取到LSN，如下面的截图所示：
那么，TestDR数据库的备份链可以通过如下的方法来查找：
获取Full Backup: 查找最新一个FULL Backup（BackType=1）文件，拿到CheckpointLSN：24000000012800197，图中红色方框标示；
获取Diff Backup：查找Diff Backup（BackType=5）文件，Diff Backup文件的DatabaseBackupLSN等于第一步中的CheckpointLSN:24000000012800197，图中黄色方框标示，取FirstLSN最大者: 24000000037600007，然后拿到LastLSN: 24000000039200001；
获取第一个Log Backup：查找第二步中的LastLSN（24000000039200001）位于Log Backup（BackType=5）的FirstLSN（24000000036800001）与LastLSN（24000000040000001）之间的Log Backup，如图中绿色方框标示，并获取到LastLSN：24000000040000001；
获取下一个Log Backup: 下一个Log Backup文件的FirstLSN（24000000040000001）应该等于上一步获取到额LastLSN，如图中粉红色标示；
获取第N个Log Backup：按照步骤四中的方法查找，直到所有日志文件查找完毕。
所以，我们最终获取到的TestDR数据库的最简单，快速恢复的备份链是：C:TempTestDR_20171217@00:00_FULL.bak => C:TempTestDR_20171217@12:00_DIFF.bak => C:TempTestDR_20171217@13:00_LOG.trn => C:TempTestDR_20171217@14:00_LOG.trn。这个链条和我们上一期分享的数据库备份文件还原操作是完全吻合的。
在“备份链原理”章节中，我们找出备份链是通过“用眼睛看”的查找方式来实现的。但是现实中如果数据库实例众多，数据库纷繁复杂，用眼睛看的方法就显得低效而准确率不高。那么，如何实现数据库备份链的自动查找呢？不着急，我已经为大家写好了，你只需要把相同数据库的多个备份文件路径放入输入参数中，我们就非常轻松、快捷的查找到数据库的备份链，并以此为依据来还原数据库。还是以TestDR的十五个备份文件为例来查找备份链条，代码如下：
备份链结果截图展示如下：
从这个截图中，restore_order和Backup_file字段可以很清楚的看到数据库还原的顺序，以及相应的备份文件路径。所有备份文件的LSN分布如下截图：
从备份链条我们发现，12:00的这个差异备份C:TempTestDR_20171217@12:00_DIFF.bak非常关键，假设现实中，我们发现这个文件恰恰损坏掉了，那么我们的可以实现应用的数据库还原吗？答案是肯定的，我们把刚才的脚本输入参数修改如下：
得到如下备份还原链条：
从这个结果，我们可以看到，系统选择了06:00这个差异备份文件，然后一步步使用接下来的事务日志备份文件进行还原。
本期是SQL Server备份专题的第三期，在前两期基础上分享了如何通过备份文件查找SQL Server数据库备份链，并以此来还原数据库的理论方法和具体实现，可以帮助用户实现简单、快速查找数据库备份还原链条。