![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 38%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJM%3C/text%3E%3C/svg%3E)
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
14,494 questions
Unfortunately, this sounds like your backup file is damaged. Alternatively, the I/O subsystem on the server you are restoring to is munging the bytes while reading the file.
Assuming that this is a backup from a production server, this is a serious situation, because not having a clean backup of a production database when something goes south means you have total data loss.
So you need to investigate where in the chain things goes wrong. Is the backup faulty already when taken? Was it damaged when it was copied to the other server? Attempt to restore the backup on different machines, including the source server (under a different name, of course.) For a quick, initial, check, you can use RESTORE VERIFYONLY, but keep in mind that because it completes without error, does not mean that the backup is OK. To fully verify a backup, you need to restore it and run DBCC CHECKDB on it.
Also, this worked a few months ago after numerous attempts
Are you saying that when you did the same restore operation a couple of months back, you got the same error, but you were eventually able to load the backup? That suggests that the error is with reading the backup on the target. Which would be good news, but there is no reason to jump to conclusion. Getting an error when reading a backup is not an error to take lightly, but you need to prove that your backups are good.