Can you include the output of DBCC CHECKDB following the rebuild index step you performed?

@Elementzero, did you checked through the Tsql command (restore headeronly from disk) to verify your backup. Is it really has corruption or not.

@ElementZero so when you enabled checksum and ran checkdb and backup both gave error or both executed successfully ?. Also please add the output of select @@version in the question

@Dan I cannot give the full output of the CHECKDB as it would give table names which would be against the company privacy policy. However I can tell you that it is just a normal clean CHECKDB - where each table just states the rows and pages and then at the end it gives "CHECKDB found 0 allocation errors and 0 consistency errors in database 'MyDatabase'." There is no errors or anything abnormal in the output.

@Md Haidar Ali Khan I cannot verify the backup as the backup does not complete

@Shanky Added @@version to the question. As I said before the results for the backup and checkdb are the same - updated the question to be more specific.

1. Try backup .. with FORMAT, INIT or just use a new file. if 1st does not work, do a hex dump with style 2 PAGE ('MyDatabase',1,745345, 2);. Try restoring that page which has corruption. see this blogs.msdn.microsoft.com/sqlserverstorageengine/2007/01/17/…

The m_type=2 which means it is index page and since GAM (1:511232) = ALLOCATED SGAM (1:511233) = NOT ALLOCATED page is allocated in GAM but not in SGAM it seems some corruption. It is strange why checkdb is missing it. I hope you are running complete checkdb with no options ?

@Shanky Yes I'm just running "DBCC CheckDB('MyDatabase')", no other options

Couple questions: What happens when you back up the database to a different drive? Have you tried running a deeper form of checkdb? DBCC CHECKDB(Crap) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, EXTENDED_LOGICAL_CHECKS;

@sp_BlitzErik that was a good idea - I forgot about the DATA_PURITY. Unfortunately I attempted that and it still came be with 0 errors. Updated the question with the output. Also I tried backing up to a different drive and even a different SAN - it just gives the same error message.

Check windows event logs to see if there is any corruption or not.

@Kin I unfortunately cannot do a page level restore because the backups were set to delete after three months and the last "good" backup was taken in April. I checked the Windows event logs but they show no errors in the system log. The Application log only goes back one day due to us having auditing on the user logins and the log was only set to hold 20MB. I did check the SQL Server logs since the last backup but there is nothing about corruption or errors (save for failed backups reporting that corruption).

@Shanky Still errors, same error message. At this point I'm looking to copy the database meta and then import the data from the current DB to the new DB and see what happens (i.e. if data transfer fails on a specific table or what not).

@ElementZero Please let us know how you go with that process.

I scripted out the database, created a new database and then used the Import/Export Wizard to copy over data for all tables. I had no error with any of it. The new database has no issues backing up and no issues with CHECKDB. The only thing I notice is that after running DBCC UPDATEUSAGE and sp_updatestats incorrect row counts are listed in sys.partitions. A count(*) on each table though matches with the new database. I suppose this resolved the issue, although I still would have preferred a better resolution and why CHECKDB does not work. Is it possible that it was all on de-allocated pages?

I don't have the query handy, but there is a way to figure out the table name or names from the page number. After that you can simply drop and recreate all indexes which may fix the corruption. It will fix some, but not all. You can't do alter index, you have to drop and recreate either the known corrupted index or all indexes. Once or twice I had corruption with months of bad backups and DBCC couldn't fix it. Recreating the index was able to fix it.