系统损坏sql数据库备份

A Database administrator’s key task is to keep the database healthy and available for the users. We are used to taking regular SQL backups depending upon the database criticality and the recovery model. We define the Recovery Point Objective (RPO) Recovery Time Objective (RTO) or the database system, and we should be able to recover the database in any scenario to meet the requirement.

数据库管理员的关键任务是保持数据库的健康并为用户使用。 我们习惯于根据数据库的重要性和恢复模型进行常规SQL备份。 我们定义了恢复点目标（RPO）恢复时间目标（RTO）或数据库系统，并且我们应该能够在任何情况下恢复数据库以满足要求。

We have the following backup types available in SQL Server.

SQL Server中有以下可用的备份类型。

• Simple Recovery Model: Full and differential backup 简单恢复模型：完整备份和差异备份
• Full Recovery model: Full, differential and log backup 完全恢复模式：完整，差异和日志备份

Consider a scenario in which we are taking regular database backups. Due to some unexpected issues such as database corruption, server or hard disk failure, the database is down. In this case, we want to restore the last full SQL backup to recover the database. You cannot restore the database backup because the backup file is corrupt. If we cannot restore the backup during such critical scenarios, there is no use of taking backups in the first place. If we do not have a valid database backup in a disaster scenario, we might lose data since the previous successful valid backup.

考虑一个我们要进行常规数据库备份的方案。 由于某些意外问题，例如数据库损坏，服务器或硬盘故障，数据库已关闭。 在这种情况下，我们要还原上一次完整SQL备份以恢复数据库。 您无法还原数据库备份，因为备份文件已损坏 。 如果在这样的关键情况下我们无法还原备份，那么首先就不用备份了。 如果在灾难情况下我们没有有效的数据库备份，则由于先前成功的有效备份，我们可能会丢失数据。

In this article, we will use a different way to identify and be sure that our backups are healthy. This way we can ensure that our environment will be able to recover in case of any unexpected downtime.

在本文中，我们将使用另一种方式来识别并确保备份运行状况良好。 这样，我们可以确保在发生意外停机时能够恢复我们的环境。

使用SQL Server Management Studio验证数据库备份 (Verify Database Backups using SQL Server Management Studio)

Let us look at the steps to take full backup using SSMS. Right click on the database -> Backups:

让我们看看使用SSMS进行完整备份的步骤。 右键单击数据库->备份：

In the first page, we define the SQL backup type and the backup file location:

在第一页中，我们定义SQL备份类型和备份文件位置：

In the ‘Media Options’ page, you can see a section for the ‘Reliability’:

在“媒体选项”页面中，您可以看到“可靠性”部分：

We have the following options under ‘Reliability’.

我们在“可靠性”下提供以下选项。

• Perform checksum before writing to the media: We can ensure a good SQL backup using this option. SQL Server internally calculates the checksum value for each page. This checksum value remains precisely the same for the same data in the page during the recalculation as well. SQL Server writes the CHECKSUM value for each page during the backup once we select this option. 在写入介质之前执行校验和：我们可以使用此选项确保SQL备份良好。 SQL Server在内部计算每个页面的校验和值。 在重新计算期间，对于页面中的相同数据，此校验和值也保持完全相同。 一旦选择此选项，SQL Server将在备份期间为每个页面写入CHECKSUM值。

  During the database restore process, SQL Server recalculates the CHECKSUM value for each page and matches with the CHECKSUM value written during the backup. If both values are similar, it shows that the database backup is valid.
  在数据库还原过程中，SQL Server为每个页面重新计算CHECKSUM值，并与备份期间写入的CHECKSUM值匹配。 如果两个值都相似，则表明数据库备份有效。

Let us put a checkbox against this option and generate the SQL backup database script:

让我们在此选项旁打一个复选框，并生成SQL备份数据库脚本：

It generates the below script. You can see a parameter CHECKSUM in the SQL backup database command.

它生成以下脚本。 您可以在SQL backup database命令中看到参数CHECKSUM。

BACKUP DATABASE [SQLShackDemo] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak'
WITH NOFORMAT, NOINIT,  NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM
GO

Once you have executed the backup, you can still verify whether the backup taken earlier consists of a CHECKSUM or not.

执行备份后，您仍然可以验证之前进行的备份是否包含CHECKSUM。

SELECT database_name,backup_finish_date,  has_backup_checksums FROM backupset
where database_name='SQLShackDemo'
GO

In the following screenshot, we can see the backup set has value 1 and 0.

在以下屏幕截图中，我们可以看到备份集的值为1和0。

• Value 1 for has_backup_checksum: It shows database backup performed with CHECKSUM has_backup_checksum的值1：显示使用CHECKSUM执行的数据库备份
• Value 0 for has_backup_checksum: It shows database backup did not consist of CHECKSUM informationhas_backup_checksum的值为0：它显示数据库备份不包含CHECKSUM信息
  

We can enable the trace flag 3023 to take all backups using CHECKSUM. If we enable this trace flag at a global level, we do not need to specify this option explicitly while taking the SQL backup.

我们可以启用跟踪标志3023，以使用CHECKSUM进行所有备份。 如果我们在全局级别启用此跟踪标志，则在进行SQL备份时不需要显式指定此选项。

Command to enable trace flag at a global level.

用于在全局级别启用跟踪标志的命令。

  DBCC Traceon (3023,-1)

In SQL Server 2014 or later, we need to enable backup checksum default in the sp_configure configuration options. Execute the below query in SSMS.

在SQL Server 2014或更高版本中，我们需要在sp_configure配置选项中启用默认的备份校验和 。 在SSMS中执行以下查询。

USE master;
GO
EXEC sp_configure 'show advanced option', '1';
Go
RECONFIGURE with OVERRIDE;
Go
EXEC sp_configure;

You get the option ‘backup checksum default’ in the sp_configure command output:

您在sp_configure命令输出中获得“备份校验和默认值”选项：

We have the following configuration options.

我们有以下配置选项。

• 1: Value ‘1’ shows that SQL backups with CHECKSUM is enabled at the instance level 1：值“ 1”表明在实例级别启用了具有CHECKSUMSQL备份
• 0: Value ‘0’ shows that this setting is not active. It is the default configuration 0：值“ 0”表示此设置无效。 这是默认配置

Use the below command to enable this setting at the instance level.

使用以下命令在实例级别启用此设置。

EXEC sp_configure ' backup checksum default', '1';
Go
RECONFIGURE with OVERRIDE;
Go

In the following screenshot, you can see that the ‘backup checksum default’ option is enabled at the instance level using the sp_configure command:

在以下屏幕快照中，您可以看到使用sp_configure命令在实例级别启用了“ backup checksum default”选项：

完成后验证SQL备份 (Verifying the SQL backup when finished)

We have another option ‘Verify backup when finished’ in the backup wizard of SSMS. It checks for the following parameters.

在SSMS的备份向导中，我们还有另一个选项“完成后验证备份”。 它检查以下参数。

• It checks whether a SQL backup file is accessible or not 它检查SQL备份文件是否可访问
• It reads the header information in the SQL backup set and validates the information 它读取SQL备份集中的标头信息并验证该信息

It does not restore the database but instead validates the metadata. Therefore, let us put a check in front of ‘Verify backup when finished’:

它不会还原数据库，而是会验证元数据。 因此，让我们在“完成后验证备份”之前进行检查：

You get the below command once you script out using SSMS script actions window:

使用SSMS脚本操作窗口编写脚本后，将获得以下命令：

BACKUP DATABASE [SQLShackDemo] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH NOFORMAT, NOINIT,
NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'SQLShackDemo' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'SQLShackDemo' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''SQLShackDemo'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

This time the database backup command is divided into two parts.

这次，数据库备份命令分为两个部分。

1. BACKUP DATABASE [SQLShackDemo] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH NOFORMAT, NOINIT,
   NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
   GO
   

2. declare @backupSetId as int
   select @backupSetId = position from msdb..backupset where database_name=N'SQLShackDemo' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'SQLShackDemo' )
   if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''SQLShackDemo'' not found.', 16, 1) end
   RESTORE VERIFYONLY FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
   GO
   

SQL Server takes the backup in the Microsoft Tape Format (MTF). If we take the database backup with only ‘verify backup when finished’ option, it only performs the few checks on the backup set blocks in MTF. It does not check for the actual data blocks. Therefore, as per best practice, we should combine both the option together as per the following image and execute the backup:

SQL Server以Microsoft磁带格式（MTF）进行备份。 如果我们仅使用“完成后验证备份”选项进行数据库备份，则它仅对MTF中的备份集块执行少量检查。 它不检查实际的数据块。 因此，按照最佳实践，我们应按照下图将这两个选项组合在一起并执行备份：

We can see the below script with the CHECKSUM in backup command and RESTORE VERIFYONLY in the verification command.

我们可以在备份命令中看到带有CHECKSUM的以下脚本，在验证命令中看到具有RESTORE VERIFYONLY的脚本。

BACKUP DATABASE [SQLShackDemo] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH NOFORMAT, NOINIT,  NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'SQLShackDemo' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'SQLShackDemo' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''SQLShackDemo'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQL2019\MSSQL\Backup\SQLShackDemo.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

Once you execute the backup, in the output, you get a message stating backup file is valid or not:

执行备份后，在输出中，您将收到一条消息，指出备份文件是否有效：

翻译自: https://www.sqlshack.com/how-to-recognize-corrupted-sql-backup-files/

系统损坏sql数据库备份