Having issues restoring a database in SSMS, error 38.

The databases are transferred up to google via their Drive API.

Download it on my side and has error.

If I transfer it through teamviewer from client PC I still get the same error.

Only happening on two clients the rest are fine.

I have tried backing up with FORMAT options and WITH CHECKSUM. Both succeed and backup is taking when verifying.

I have ran restore fileheaders only and get proper data except the physicalname path has a lowercase 'c' for the drive on the problem databases.

I have read this could be a corrupt database but I don't understand how the checksum and verify sql functions pass if so. Any insight would really help.

This is the backup command used in C#

"BACKUP DATABASE " + database + " TO DISK = '" 
+ database + "_" + dateTime.ToString("yyyy_MM_dd_HH") + 
"_CloudBackup.bak' WITH NAME = 'database', INIT, CHECKSUM"

EDIT: Running dbcc check on the database produced no errors. I have tried updated the physical name of the .mdf and .ldf it does not work still. Taking a backup from SSMS produces a valid backup file. It has something to do with the services I wrote.

EDIT 2: I am restoring through SSMS GUI. I have also tried RESTORE DATABASE db_name FROM 'backup_path'



On both computers, mine and the server PC yields "The backup set on file 1 is valid."


Have only test on my PC. Returns paths to mdf and ldf, no errors.

Both PCs have sql server 2012 (SP1)

  • 1
    Try running CHECKDB on the source server. – Alex Jul 24 '19 at 5:35
  • @Alex I will try this when the clients get in today. Thank you for the suggestion. – Austen Swanson Jul 24 '19 at 12:12
  • @Alex I have tried running checkdb and it produced no errors. Thank you for the suggestion though. – Austen Swanson Jul 26 '19 at 16:47
  • 1
    @AustenSwanson You don't show the code you're using to restore the database. If you load up SSMS on the "problem" server, or another server, and execute RESTORE VERIFYONLY FROM DISK='<Your backup name here>.bak' do you still get the same error? Also, are the backup and restore servers running the exact same version of SQL Server? – AlwaysLearning Jul 27 '19 at 10:13
  • @AlwaysLearning Thanks for the response. I added another edit to clarify some of your questions. – Austen Swanson Jul 29 '19 at 12:04

I removed all compression all together (zipping the .bak via ZipArchive library in .NET) and pass it up to google and it works fine now. Something must be going wrong in the compression. Thank you for the lead into looking at compression =)

Originally left in a comment by user Austen Swanson (the OP).

So rather than the database being corrupt, the backup was getting corrupted in the process of trying to compress (or decompress) it using third-party compression.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.