ZLib decompression error

kermikermi Posts: 47
edited September 7, 2006 10:35AM in SQL Backup Previous Versions
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

Comments

  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • 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
  • peteypetey Posts: 2,358 New member
    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?
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • 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.
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • 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.
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • 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
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
Sign In or Register to comment.