常用数据备份模式和组合方式

1、数据备份的主要方式：

完全备份

完全备份（full backup）」，每个档案都会被写进备份档去。如上所述，如果两个时间点备份之间，数据没有任何更动，那么所有备份数据都是一样的。

这问题出自备份系统不会检查自上次备份后，档案有没有被更动过；它只是机械性地将每个档案读出、写入，不管档案有没有被修改过。备份全部选中的文件及文件夹，并不依赖文件的存盘属性来确定备份哪些文件。

（在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份，换言之，清除存盘属性）。

这是我们不会一味采取完全备份的原因 — 每个档案都会被写到备份装置上。这表示即使所有档案都没有变动，还是会占据许多存储空间。如果每天变动的档案只有 10 MB，每晚却要花费 100 GB 的存储空间做备份，这绝对不是个好方法；这也就是推出「增量备份（incremental backups） 的主要原因。

增量备份

跟完全备份不同，增量备份备份上一次的完全备份后发生变化的所有文件，档案的最后修改时间是否比上次备份的时间来得晚。如果不是的话，那表示自上次备份后，这档案并没有被更动过，所以这次不需要备份。换句话说，如果修改日期「的确」比上次更动的日期来得晚，那么档案就被更动过，需要备份。 

增量备份常常跟完全备份合用（例如每个星期做完全备份，每天做增量备份）差异备份是针对完全备份：备份上一次的完全备份后发生变化的所有文件。

（差异备份过程中，只备份有标记的那些选中的文件和文件夹。它不清除标记，既：备份后不标记为已备份文件，换言之，不清除存盘属性）。

使用增量备份最大的好处在于备份速度：它的速度比完整备份快上许多，同时由于增量备份在做备份前会自动判断备份时间点及文件是否已作改动，所以相对于完全备份其对于节省存储空间也大有益处。增量备份的不足之处在于数据还原的时间较长，效率相对较低，例如，如果您要还原一个备份档案，您必须把所有增量备份的磁盘都找一遍，直到找到为止，如果您要复原整个档案系统，那就得先复原最近一次的完整备份，然后复原一个又一个的增量备份。

要避免复原一个又一个的递增数据，提升数据的复原的效率，把做法稍微改变一下，就变成了「差异备份（differential backup）」。

差异备份

差异备份与增量备份一样，差异备份是针对完全备份。但前者的备份是「累积（cumulative）」的—— 一个档案只要自上次完整备份后，曾被更新过，那么接下来每次做差异备份时，这个档案都会被备份（当然，直到下一次完整备份为止）。

这表示差异备份中的档案，都是自上次完全备份之后，曾被改变的档案。如果要复原整个系统，那么您只要先复原完全备份，再复原最后一次的差异备份即可。增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。

（增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存盘属性。）

跟增量备份所使用的策略一样，您平时只要定期做一次完全备份，再定时做差异备份即可。

所以，差异备份的大小，会随着时间过去而不断增加（假设在完全备份间，每天修改的档案都不一样）。以备份空间与速度来说，差异备份介于递增备份与完全备份之间；但不管是复原一个档案或是整个系统，速度通常比完全备份、增量备份快（因为要搜寻 / 复原的磁盘数目比较少）。

基于这些特点，差异备份是值得考虑的方案，增量备份与差异备份技术在部分中高端的网络附加存储设备如IBM、HP、及自由遁等品牌的部分产品的附带软件中已内置。

事务日志备份： 在特定事务日志备份之前执行的完整数据库备份和上次差异备份（如果有）。在完整数据库备份之后执行的所有事务日志备份或在特定事务日志备份之前执行的差异备份（如果您还原了差异备份）。如果你设置了恢复模式为【简单】，你将无法使用【事务日志】备份。SQL Server 2000 和 SQL Server 2005： 创建事务日志备份，您必须使用完整恢复或大容量日志记录恢复模型。

部分备份： 通过指定 READ_WRITE_FILEGROUPS 创建的备份称为“部分备份”。在简单恢复模式下，只允许对只读文件组执行文件组备份。还原的数据备份类型：数据库备份、部分备份或文件备份。对于数据库备份或部分备份，日志备份序列必须从数据库备份或部分备份的结尾处开始延续。对于一组文件备份，日志备份序列必须从整组文件备份的开头开始延续。

文件备份： “文件备份”包含一个或多个文件（或文件组）中的所有数据。

日志链： 连续的日志备份序列称为“日志链”。日志链从数据库的完整备份开始。通常，仅当第一次备份数据库时，或者将恢复模式从简单恢复模式切换到完整恢复模式或大容量日志恢复模式之后，才会开始一个新的日志链。除非在创建完整数据库备份时选择覆盖现有备份集，否则现有的日志链将保持不变。在该日志链保持不变的情况下，便可从媒体集中的任何完整数据库备份还原数据库，然后再还原相应恢复点之前的所有后续日志备份。恢复点可以是上次日志备份的结尾，也可以是任何日志备份中的特定恢复点。

 

2、不同备份类型组合应用的示例

（1）、完全备份与差异备份

以每周数据备份计划为例，我们可以在星期一进行完全备份，在星期二至星期五进行差异备份。如果在星期五数据被破坏了，则你只需要还原星期一完全的备份和星期四的差异备份。这种策略备份数据需要较多的时间，但还原数据使用较少的时间。

（2）、完全备份与增量备份

还是以每周数据备份为例，在星期一进行完全备份，在星期二至星期五进行增量备份。如果在星期五数据被破坏了，则你需要还原星期一正常的备份和从星期二至星期五的所有增量备份。这种策略备份数据需要较多的时间，但还原数据使用较少的时间。

一个备份方案例子： 某个站点在星期天晚上执行完整数据库备份。在白天每隔 4 小时制作一个事务日志备份集，并用当天的备份重写头一天的备份。每晚则进行差异备份。如果数据库的某个数据磁盘在星期四上午 9:12 出现故障，则该站点可以：

1)     备份当前事务日志；（已经出现故障了，如何备份当前事务日志？）

2)     还原从星期天晚上开始的数据库备份；

3)     还原从星期三晚上开始的差异备份，将数据库前滚到这一时刻；

4)     还原从早上 4 点到 8 点的事务日志备份，以将数据库前滚到早上 8 点；

5)     还原故障之后的日志备份。这将使数据库前滚到故障发生的那一刻。

二、还原步骤

创建一个叫TestBackup的数据库，创建一张叫Table1的表，这个时候进行一次完整备份，备份文件为：TestBackupDB-full.bak；接着创建表Table2后进行差异备份，备份文件为：TestBackupDB-diff.bak；接着创建表Table3后进行事务日志备份（如果数据库设置了恢复模式为【简单】，那么在备份类型选项中将看不到【事务日志】），备份文件为：TestBackupDB-log.bak；

创建一个叫TestBackup2的数据库，用于测试TestBackup数据库的备份文件的还原。

（图1：创建库结构）

（图2：备份类型）

       下面我们就可以对三个备份文件：TestBackupDB-full.bak、TestBackupDB-diff.bak、TestBackupDB-log.bak进行还原：

       步骤1：还原完整备份文件TestBackupDB-full.bak，选项如图4、图5所示，还原成功后数据列表就会如图6所示，这是因为恢复状态选项：不对数据库执行任何操作，不回滚未提交的事务。可以还原其他事务日志。(RESTORE WITH NORECOVERY)

（图3：进入SSMS还原）

（图4：还原常规）

（图5：还原选项）

（图6：完整备份还原）

步骤2：还原差异备份文件TestBackupDB-diff.bak，操作如步骤1所示，这个时候的数据库还是跟图6的状态一样的。

步骤3：还原事务日志备份文件TestBackupDB-log.bak，如图7进入事务日志的还原操作界面；看图8的选项中有指定事务的时间进行还原（还原过程中的恢复状态都是默认为RESTORE WITH RECOVERY，所以这里没有提及这个选项）。还原后的TestBackup2数据库，还原之后的数据库TestBackup2如图9所示。

（图7：进入事务日志）

（图8：事务日志）

（图9：还原后的数据库）

 

三、升级

通常来说文章写到这里就应该结束了，但是很幸运，再给你介绍一下如何在对表进行分区后的还原操作，从上面的操作来看只包括了mdf和ldf文件，但如果多了几个ndf文件，这些还原又一样吗？所以我称这部分的内容为升级。

情景一：如果本来就有对应的分区文件的，只要在还原的时候修改【还原为】的文件名就可以进行还原了。

情景二：如果刚刚新建了分区文件组和文件，这个时候接着还原备份就会出现图10的错误（不知道是不是在SQL Server 2005的问题）；要解决这个问题有两个方法，第一个：重启数据库服务再还原；第二个：设置数据库的【限制访问】设置为【Single】；

 

（图10：错误）

转载于:https://www.cnblogs.com/become/p/4894191.html