ZLib decompression error

kermi · August 23, 2006 9:38AM

I've been getting the following error while trying to restore a database.

Thread 0 error:
Data decompression error: ZLib decompressionerror: buffer error

Server: Msg 3031
RESTORE DATABASE is terminating abnormally.
Server: Msg 3203
Read on 'SQLBACKUP_AB98BBB3-D06E-4813-BD04-A840F5565AEO' failed,
status = 995. See the Sql Server error log for more details.

SQL error code: 3203

Any ideas why I'm receiveing this error. It's beginning to happen more and more.

Thanks
Jon

petey · August 23, 2006 11:38AM

Could you pls compare the original backup file with the one that you are restoring from? Are the sizes the same? If they are, can you also generate a checksum for both files, to see if the contents are identical? You can download a simple md5 generator from http://www.yohz.com/downloads/md5x.zip.

kermi · August 23, 2006 12:27PM

We're actually breaking the backup into 4 files via command line, but they are the same size. Even if I try to restore via the GUI interface it is telling me that I have valid files. However, here's what I've generated from the md5 generator.

MD5: F63F443902C3C2FAAA4FB2A0BDA7A370 > DATA01.sqb
MD5: A60DF2B22A5D3BE79AF329B3355355C8 > DATA02.sqb
MD5: BD779D8C2C5749E20163A28504659CAF > DATA03.sqb
MD5: 48BAECB601A51064025C910F4069B0EC > DATA04.sqb

petey · August 23, 2006 12:50PM

Are you restoring from the original set of backup files, or from copies of the original set? If using copies, could you pls compare the md5 values generated for both the original set and the copies?

In the GUI, the restore wizard checks only the header (1KB) of each of the backup files, to ensure that they are SQL Backup files. It does not check the entire contents of the files.

If the files are not too large, do you think you can send me copies of the files?

kermi · August 24, 2006 1:37PM

Yes, the md5 values are different. I'm guessing that something is getting messed up during the file transfer process. I'm not too sure that there is anything that can be done about that.

petey · August 25, 2006 4:48AM

If the file transfer was performed using SQL Backup's COPYTO option, could you pls check the SQL Backup log file for that backup, if any warnings were raised for the failed copy process? Thanks.

kermi · September 6, 2006 8:58AM

Sorry for the delay in my post.

The situation that we're running into is not the fact that we're copying data from machine A to machine B within our network. The problem occurs when we receive a backup of our customer's data to host on our website. The encrypted backups are sent to us across the internet via SSH. When we recieve the data the file size is the same but the checksum for one of the files is off. SQL Backup does not recognize this and starts restoring the data but never finishes and leaves the database in the "Loading" state. This problem is getting worse as we bring more customers on. Is there some way we can escalate this issue that we are running into, because I can only see this issue getting worse as we convert more of our customers over to our new data structure.

petey · September 6, 2006 12:29PM

From your description, it appears that the various components are working as designed. You want to perform a restore, SQL Backup tries to pass the data to SQL Server, at some point it fails due to data corruption, leaving SQL Server with an incomplete database.

The problem is with the incorrect backup file. Some suggestions:

- if running SQL 2005, create the backup using CHECKSUM option. When you receive the backup file, run RESTORE VERIFYONLY using SQL Backup on the files. Only if there were no errors do you run the actual restore. Cost: time to perform the verification.

- generate a checksum of the backup file on the source machine. When the file is copied over, generate another checksum for comparison. Compare before performing the restore. Cost: time to perform the checksum computation.

- before the restore, make a backup of the database. If the restore fails, restore using this backup. Cost: storage to hold the backup file.

- run a restore but to a staging database. If the restore is successful, drop the existing database, and rename the staging database. Cost: storage to hold the staging database.

- compress the backup file using a 3rd-party compression app e.g. winrar. The file will fail to decompress if there were any errors during the file transfer. Cost: time and storage to hold another copy of the compressed file.

kermi · September 6, 2006 12:44PM

We've already considered points 2, 3 & 4. I'll look at the other 2 options to see if they provide a working solution for us.

Thanks

petey · September 7, 2006 10:35AM

I should have clarified why winrar came to mind. It is because winrar allows you to add recovery records to an archive, so that if the archive isn't too badly damaged, you can still recover the archive, saving you the trouble of getting a new copy of the file.

And no, I don't own stocks in rarlabs.

ZLib decompression error

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk