ZLib Decompression Error (5.3.0.178)

howarthcd

Yesterday we experienced what I would consider to be a serious error that has made us lose confidence in SQL Backup.

We take a full database backup every night, followed by regular log backups during the day - all backups are made directly to a network share.

As a test we restored the full database backup, no problem, however when restoring the first log backup a 'ZLib Decompression Error' was returned. When restoring the second log backup an error was returned that the first LSN in the (second) log file was too recent to be applied to the database.



I'm guessing that there was a brief network outage whilst the compressed file was being written to the share, and that SQL Server had already received notification from the SQL Backup service that the log backup had been completed and duly truncated the database's log.



This seems to be pretty serious to me as none of our subsequent log backups were restorable due to the error that occurred when taking the first log backup. If we lost the database during the day we would not have been able to restore to a point in time close to the failure.

Is this a known issue with SQL Backup? Is there a workaround? We have now reverted to native backups as we can't afford to lose our data.

Thanks
Chris

ChrisAVWood

I am wondering why there has been no response to this question?

Chris

howarthcd

I ended up raising this directly with Red-Gate as I was looking for a rapid response, which was as follows:

Red-Gate's response:

This shouldn't happen as the SQL Backup failure to write the file should be reported back to SQL Server so the whole process is a failure.

It may be that the last data block was retrieved from the VDI and then SQL Server truncated the log. The failure could have then happened writing the last few blocks or something similar.

The outcome is the same as a corrupted log backup file which is always a risk when backing up straight to a network share. Transferring more data and using Native backup will increase this risk.

I am communicating with a developer to see if he can track down an occasion where SQL Backup reports to SQL Server that it is complete before the final data blocks have been written.

<Reply sent by me included the failed backup's log file>

Red-Gate's response:

Thank you for the log file, after discussing this with the development team it seems there is one rare occasion where this can occur.

There can be a delay between SQL Backup receiving the data, compressing it and writing it to disk.

This delay is caused because the compressed data can not be written to disk before it reaches a specific size, for efficiency and OS requirement issues.

SQL Server does not inform SQL Backup that it is sending the last block so when SQL Backup acknowledges it has received that block SQL Server automatically assumes all data has been received/written so SQL Server will perform the truncation.

If the last accumulated block of compressed data then then has a problem, it renders the whole backup file incomplete.

This is something we are hoping to improve but it may take a lot of work with regards to logic and finding a way to know which block is the last from SQL Server.

So it seems that the issue is being caused by an inadequacy inherent in SQL Server's VDI and that most, if not all, 3rd party compression products that rely on the VDI (there is at least one that doesn't) may be open to the same issue.

In order to help mitigate the risk I think that we may move to SQL Server 2008's native compression feature when we upgrade. This is unfortunate for Red-Gate as their product is otherwise superb, but we can't afford to risk this happening again.

Chris

ChrisAVWood

Thanks for the reply.

That's not the best news to hear.

Chris

Nigel Morse

Hi,
Sorry you've had this problem. We've done some digging into the VDI and we think we found a way to fix this. We're locking down version 5.5 in a few days time and so if it works we will put this in before then.

howarthcd

Hi Nigel

Thanks for the update - this does sound promising. We're looking forward to seeing this fixed in a future release.

Thanks
Chris