数据备份概述#

数据备份的范围可以是整个数据库、部分数据库或一组文件或文件组。对于每种备份，SQL Server^TM都支持完整备份和差异备份。整个数据库的完整备份表示完成时备份的是整个数据库。差异备份仅包含自每个文件的最新数据库备份以来修改的数据范围。

每个数据备份都包含事务日志的部分，因此可以将备份恢复到备份结束时。在第一次数据备份之后，在完全恢复模式或批量日志恢复模式下，需要定期进行事务日志备份（或日志备份）。每个日志备份涵盖创建备份时处于活动状态的事务日志部分，日志备份包括以前日志备份中未备份的所有日志记录。

数据库备份#

数据库备份很容易，建议在数据库大小允许的情况下进行备份。SQL Server支持以下类型的数据库备份。

Table: 数据库完整备份的类型

部分备份#

部分备份和差额部分备份旨在为在简单恢复模型下备份包含一些只读文件组的数据库提供更大的灵活性。但是，所有恢复模型都支持这些备份。

SQL Server^TM支持以下类型的文件备份。

Table: 数据库部分备份的类型

文件备份#

数据库中的文件可以单独备份和还原。使用文件备份可以提高恢复速度，只恢复损坏的文件，而不恢复数据库的其余部分。

例如，如果一个数据库由位于不同磁盘上的多个文件组成，并且一个磁盘出现故障，则只需恢复故障磁盘上的文件。然而，规划和恢复文件备份可能很复杂；因此，仅当文件备份明显能为您的恢复计划增加价值时，才应使用文件备份。

SQL Server^TM 支持以下类型的文件备份。

备份类型	描述
文件备份	一个或多个文件或文件组中所有数据的完整备份 在简单恢复模型下，文件备份基本上仅限于只读辅助文件组。您可以为读/写文件组创建文件备份，但在恢复读/写文件备份之前，必须将文件组设置为只读并进行差异只读文件备份。
差额文件备份	一个或多个文件的备份，其中包含自每个文件的最近一次完全备份以来更改的数据范围 在简单恢复模型下，这假设自完全备份后数据已更改为只读

Table: 文件备份的类型

请参阅文章 备份概述 (SQL Server) ⧉ 以获得详细信息。

数据恢复概述#

恢复模型概述#

恢复模型旨在控制事务日志维护。存在三种恢复模型：简单、完整和批量日志。通常，数据库使用完全恢复模型或简单恢复模型。

下表总结了这些恢复模型。

Table: 恢复模型

请参阅恢复模型概述 ⧉ 以获得更多信息。

恢复的一般假设#

本文档中描述的恢复过程假设如下：

• 凯睿德制造的实时、ODS和DWH数据库与完全恢复模式一起安装。最终用户可以将此配置更改为简单或批量记录，但只有在日志备份分别包含批量更改时，数据库才能恢复到最近的备份或事务日志备份的末尾。为了在最广泛的故障场景中防止数据丢失，建议关键制造的恢复模型为完全恢复模型。请参阅完全恢复模式下的备份 ⧉以获得更多信息。
• 所有凯睿德制造数据库（实时、ODS和DWH）都有备份/恢复策略。所有备份作业（完整、差额和批量日志）都能运行无误。建议的备份间隔为：
  • 完整备份：每周一次
  • 差异备份：每天两次
  • 差异备份：每天两次
• 完整、差额和批量日志备份文件存储在安全位置并可访问

尾部日志备份#

在数据库崩溃的情况下，为了将其恢复到崩溃前的最后一个事务，有必要备份当前数据库日志。这称为尾日志备份，它将捕获所有尚未备份的日志记录。这是恢复过程的第一步。

如果数据库可用且在线，则使用以下命令进行尾部日志备份：

BACKUP LOG database_name TO <backup_device> WITH NORECOVERY

如果数据库脱机且未启动，也可以尝试以下命令：

BACKUP LOG database_name TO <backup_device> WITH CONTINUE_AFTER_ERROR

如果数据库已损坏，例如，如果数据库未启动，则只有在日志文件未损坏、数据库处于支持尾部日志备份的状态且数据库不包含任何批量记录的更改时，尾部日志备份才会成功。如果日志文件已损坏并且无法创建尾日志备份，则必须在不使用尾日志备份的情况下还原数据库。且在最新日志备份之后提交的任何事务都将丢失。

尾日志备份可防止工作损失，并保持日志链完好无损。当您将数据库恢复到故障点时，尾日志备份是恢复计划中感兴趣的最后一次备份。如果无法备份日志的尾部，则只能将数据库恢复到故障之前创建的最后一次备份的末尾。

请参阅尾部日志备份(SQL Server) ⧉以获得更多信息。

恢复作业#

作为凯睿德制造备份/恢复解决方案的一部分，可以使用一个存储过程来浏览所有可用的完整、差额和批量日志备份集，以便重建正确的恢复链命令。存储过程可以按如下方式使用（在本例中，要恢复的数据库名称为cmMESODS)

DECLARE @RC int
DECLARE @databaseName sysname = 'cmMESODS'
EXECUTE @RC = [master].[dbo].[DatabaseRestoreScripts] @databaseName
GO

此存储过程对任何数据库恢复（实时、ODS、DWH、复制或其他）都有效，并且位于主数据库中。根据备份文件的位置，存储过程将输出以下命令（在本例中，我们将认为备份文件位于：

\\CMFDBSERVER\H\$\Databases-Backups\DBSERVER$ODS\

----------用于将cmMESODS数据库还原到Nov 10 2017 1:48PM的脚本
RESTORE DATABASE ProductionMESODS FROM DISK =
'\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS\ProductionMESODS\FULL\DBSERVER$ODS_cmMESODS_20171105_000029.bak' WITH FILE = 1, NORECOVERY
RESTORE DATABASE ProductionMESODS FROM DISK =
'\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS\ProductionMESODS\DIFF\DBSERVER$ODS_cmMESODS_20171110_120018.dif' WITH FILE = 1, NORECOVERY
RESTORE LOG ProductionMESODS FROM DISK = '\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS
\ProductionMESODS\LOG\DBSERVER$ODS_cmMESODS_20171110_120529.trn' WITH FILE = 1, NORECOVERY
RESTORE LOG ProductionMESODS FROM DISK = '\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS
\ProductionMESODS\LOG\DBSERVER$ODS_cmMESODS_20171110_121005.trn' WITH FILE = 1, NORECOVERY
(…)
RESTORE LOG ProductionMESODS FROM DISK = '\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS
\ProductionMESODS\LOG\DBSERVER$ODS_cmMESODS_20171110_134505.trn' WITH FILE = 1, NORECOVERY
RESTORE LOG ProductionMESODS FROM DISK = '\\CMF-DBSERVER\H$\DatabasesBackups\DBSERVER$ODS
\ProductionMESODS\LOG\DBSERVER$ODS_cmMESODS_20171110_1345Tail.trn' WITH FILE = 1, NORECOVERY
RESTORE DATABASE ProductionMESODS WITH RECOVERY

输出包含用户应发出的脚本，以便使用崩溃点之前使用的所有备份文件恢复数据库。正如在尾日志备份中所看到的那样，并非总是可以发布尾部日志备份。在这种情况下，存储过程的输出将不考虑尾部日志备份文件。还原数据库不需要存储过程。恢复链始终从最后一次完全备份开始，然后是最后一次差异备份，最后是应用最后一次差额备份之后进行的所有事务日志备份，直到数据库崩溃的时间点。

恢复场景#

根据崩溃的特定数据库和崩溃类型，作为一个高可用性应用程序，凯睿德制造的恢复操作需要用不同的方法。本节介绍了四种情况：

• 整个数据库群集崩溃 (实时 + ODS)
• 实时数据库崩溃
• ODS数据库崩溃
• 恢复ODS数据库事务

恢复操作高度依赖于导致系统崩溃的首要原因。本节总结了将凯睿德制造恢复实时数据库所需的步骤，并考虑了最可能的情况。此处描述的所有操作都基于Microsoft文档，并在强制崩溃条件下进行了测试。

凯睿德制造的备份/恢复解决方案的目的是在系统/数据库崩溃时最大限度地减少数据丢失。如前所述，总是有可能丢失事务数据（如果无法进行在线尾部日志备份）。我们的想法是始终将这种风险降至最低，并在发生事故时将丢失的数据量降至最低。因此，我们建议事务日志备份间隔为5分钟。在这种情况下，在最坏的情况下，数据丢失将始终为5分钟。

多种因素出现也可能影响完整系统恢复（例如，不可用或已损坏的备份文件），但这些情况对于任何依赖数据库的应用程序来说都是常见的。有多种解决方案可以保证所有备份文件的高可用性。这完全取决于最终用户所做的数据丢失风险评估应对。

有关数据库备份和恢复的更多信息，请参阅以下链接：

• 恢复和恢复概述(SQL Server) ⧉
• 完全恢复模式下的备份 ⧉
• 尾部日志备份(SQL Server) ⧉
• 逐段恢复(SQL Server) ⧉
• SQL Server备份、完整性检查、索引和统计维护 ⧉

整个数据库群集崩溃 (实时 + ODS)#

这是最坏的情况。硬件恢复后，系统管理员必须首先集中精力恢复实时数据库。这将允许将凯睿德制造的主机、凯睿德制造GUI和其他相关系统联机，并使用户能够开始对系统进行操作。

实时数据库崩溃#

根据设计，实时数据库将只包含当前对象状态及其最近的活动历史，从而实现快速恢复操作。根据崩溃后数据库的状态，可能无法提供尾部日志备份，因此会丢失自上次事务日志备份以来进行的所有事务。这就是我们建议每5分钟提供一次事务日志备份的原因（请参阅恢复一般假设），以便将这种情况的影响降至最低。

实时数据库恢复后，系统管理员现在可以开始使用凯睿德制造。并专注于恢复ODS数据库（如果是这种情况）。

请注意，复制作业将从ODS数据库运行。一旦ODS和复制数据库被恢复，复制作业将从ODS数据库中已应用的最新LSN（日志序列号）恢复。

ODS数据库崩溃#

根据最终用户的要求，ODS数据库可以包含几年的历史数据。只要SQL Server的数据库版本支持，凯睿德制造使用SQL Server分区技术来处理如此大量的数据。请参阅SQL Server文档发行说明 ⧉以比较所有可用的SQL Server版本及其功能，例如可扩展性和性能下的表和索引分区。

在SQL Server分区可用的情况下，我们建议使用逐段还原，从而启用文件组的部分还原，从主文件组开始，然后是当前分区文件组，最后是其余缺失的分区文件。此操作将使ODS数据库分区及时联机，而不依赖于单个耗时的恢复操作。请参阅逐段恢复(SQL Server) ⧉ 以获得更多信息。

如果SQL Server数据库不允许表和索引分区场景，则采用与联机还原操作类似的方式执行还原操作。

如果无法提供尾部日志备份，最后的ODS数据库事务将丢失。但是，在这种情况下，正如我们将在下面看到的那样，可以从实时数据库中恢复这些事务。

恢复ODS数据库事务#

ODS数据库依赖于复制机制，以便持续接收在线数据库中执行的数据操作。换句话说，实时数据库中所做的所有修改将以完全相同的顺序应用于ODS数据库。 如前所述，对于性能问题，实时数据库必须仅包含当前在制品和最近的活动历史记录。这是通过凯睿德制造的特定维护作业来实现的，这些维护作业将从实时数据库上清除旧数据，并将这些相同的数据保留在ODS中（删除操作仅对ODS中某些表进行复制和处理，而对其他表则忽略）。 清除作业仅从实时数据库中交叉检查与ODS中是否找到完全相同的记录后清除特定记录，例如该事务已在ODS中复制和应用。该机制还保证删除的记录遵循时间顺序 (更旧的优先)，并且只会删除已找到在特定时间范围内的记录。这将保证即使ODS的尾部日志不可用，我们仍然会在实时数据库上有完全相同的记录。

复制机制体系确保了ODS中尚未找到的最新实时数据库记录的收敛。因此，它将从ODS中已存在的上次成功复制操作后恢复数据移动。

备份和系统维护建议#

默认情况下，凯睿德键制造安装程序将安装基本的数据库维护任务。这些步骤执行建议的备份策略和维护任务。如下：

1. 数据库备份
2. 索引维护
3. 统计信息刷新
4. 数据库完整性检查

所有数据库脚本都基于Ola Hallengren发布和维护的SQL Server维护解决方案。在 这里 ⧉).。每个任务由一个特定的过程、配置和执行时间表组成。这些任务作为作业直接安装在SQL Server Agent下的数据库中。

1. DatabaseBackup - SYSTEM_DATABASES - FULL 该作业负责所有系统数据库（master、model和msdb）的完整备份。每周运行时间：周日04:00。

2. DatabaseBackup - USER_DATABASES - FULL 该作业负责当前SQL Server实例中所有用户数据库的完整备份。每周运行时间：周日05:00。

3. DatabaseBackup - USER_DATABASES - DIFF 该作业负责当前SQL Server实例中所有用户数据库的差异备份。每天运行时间：00:00和12:10

4. DatabaseBackup - USER_DATABASES - LOG 此作业负责当前SQL Server实例中所有用户数据库的日志备份。每天每5分钟运行一次。

5. DatabaseIntegrityCheck - SYSTEM_DATABASES 对系统数据库（master、model和msdb）运行数据库完整性检查（CHECKDB）。每周运行时间：周六 01:00。

6. DatabaseIntegrityCheck - USER_DATABASES 对当前SQL Server实例中的用户数据库运行数据库完整性检查（CHECKDB）。每周运行时间: 周六 02:00。

7. IndexOptimize - USER_DATABASES 运行索引维护活动（根据碎片阈值重新组织或重建索引）。它还更新表统计信息。每周运行时间：周六 03:00。

8. sp_delete_backuphistory 删除超过30天的备份历史记录。这对于维护msdb数据库和避免备份瓶颈非常重要。每周运行时间：周六 00:30

9. sp_purge_jobhistory 删除超过30天的SQL Server作业历史记录。每周运行时间：周六 00:30

10. Output File Cleanup 30天后删除维护作业日志文件。每周运行时间：周六 00:30

11. CommandLog Cleanup 删除超过30天的命令日志表项。默认情况下，维护作业运行的每个命令都记录到master].[dbo].[CommandLog] 表格中. 每周运行时间：周六 00:30

默认情况下，只保留一个完整的数据库备份副本。这将允许恢复到最新的时间点（完整+差额+批量日志）。如果您有不同的恢复目标，可以在单个备份作业命令中更改@CleanupTime参数。如果未指定时间，则不会删除任何备份文件。请注意，数据库备份有一个检查，以验证比最近的完整或差额备份更新的事务日志备份没有被删除。

虽然这些脚本通常被认为是保持健康的SQL Server数据库的完整解决方案，但也有其他脚本做同样的工作。如果使用了其他解决方案，请禁用备份作业。

我们强烈建议您保持与此处所述相同的备份策略，同时重复执行每个作业。

还要注意，维护脚本会给磁盘和网络系统带来额外的压力。为了平衡磁盘和网络与其他运行系统的使用，您可以在任何情况下调整每个作业运行的时间，改变每个单独工作的优先级。