Error Message

Restore Set Detail Information 
Monday, December 12, 2022 6:54:39 AM - Error writing file data.

Database Recovery and Consistency Checks 
Monday, December 12, 2022 6:54:47 AM - SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 3:16; actual 0:0). It occurred during a read of page (3:16) in database ID 6 at offset 0x00000000020000 in file 'T:\restore\restoreDBfile2.ndf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused 
Monday, December 12, 2022 6:54:47 AM - V-79-57344-38051 - An error occurred while attempting to recover the database. Refer to the Event Viewer on the SQL Server for details.

Job Completion Status
Final error: 0xe000fe2d - One or more items could not be read correctly during the backup. This may be due to corruption of the file system, controller, or disk, or if a portion of a file is locked. Review the Windows Event Logs, run the appropriate Windows diagnostic tool, and then try running the backup again.
Final error category: Resource Errors
For additional information regarding this error refer to link V-79-57344-65069

- or -
Final error: 0xe0008443 - One or more SQL Database consistency checks have failed.
Final error category: Resource Errors
For additional information regarding this error refer to link V-79-57344-33859

Backup Exec block-level incremental or block-level differential backups protect only the used blocks within the database files. However, the database consistency check (dbcc checkdb) reports the page header errors or index errors because it checks unused blocks in addition to used blocks.

This issue is resolved in Backup Exec 22.2.

Please refer to the following articles for design changes in Backup Exec 22.2:

Block Level-Incremental\Differential backup of SQL database switches to Copy-Full backup

Possible workaround for new backups:

1. Disable software compression

2. Disable Advanced Open File Option (AOFO) or Snapshot technology

Note1: A full backup is required after disabling AOFO.

Note2: Full, differential and log backups can be used without AOFO.

If AOFO is mandatory for any reason, use a combination of the full backups with AOFO enabled and the log backups. The differential (non-block level) backups can be used with the full and log backups.

Possible workaround with existing backup sets:

1. Restore from log backups if the log backups are available.

Select 'To an individual backup set that I select from all available backup set for this database' in the restore wizard. (Figure 1)

Figure 1.

Hold down the control key and select the full backup and subsequent log backups. (Figure 2)

Click 'Next' to run the restore job.

Figure 2.

2. Free up unused space in the database files if the log backups are not available.

Execute the following query:

'dbname' is the database name which need to repair.

USE [dbname]
GO

DBCC SHRINDATABASE(N'dbname')
GO

3. Check the database files to make sure no errors are reported.

USE [dbname]
GO

DBCC CHECKDB(N'dbname');
GO

4. Repair other the database files if the checkdb still reports errors.

USE [master]
GO

ALTER DATABASE [dbname]
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB(N'dbname', REPAIR_REBUILD);
GO

ALTER DATABASE [dbname]
SET MULTI_USER;
GO

5. Check the database files again to make sure no errors are reported.

USE [dbname]
GO

DBCC CHECKDB(N'dbname');
GO

6. (optional) Expand the database files size as expected size if required

USE [dbname]
GO

ALTER DATABASE [dbname]
MODIFY FILE (NAME = [dbfilename1], SIZE = 100GB, MAXSIZE = 100GB);
GO

ALTER DATABASE [dbname]
MODIFY FILE (NAME = [dbfilename2], SIZE = 100GB, MAXSIZE = 100GB);
GO

ALTER DATABASE [dbname]
MODIFY FILE (NAME = [dbfilenameN], SIZE = 100GB, MAXSIZE = 100GB);
GO