Backup duration extended for compressed databases (4x)

epetro

We have been running 5 compressed databases since 8/1 .
Our weekly RedGate backup job used to process between 22 - 43 minutes. It now requires 140 - 204 minutes.

We are not running verify.
All disk configurations have remained the same.
No changes in database access (i.e. testing during backup window).

So...
Should I be switching this server to using HyperBac 5 rather than SQL Backup 6 ?

peter.peart

Thanks for your post.

It would be good to take a look at the SQL Backup logs to see what sort of throughput you were getting on the normal database when performing a backup versus what sort of throughput you are getting now.

If there's a significant drop from when you had the DB running normally to running under Storage Compress, we would probably have to do some testing here and then learn a bit more about your environment, i.e. was the DB also being updated during the backup being taken on the DB running under Storage Compress, and it would also be good to get an idea of I/O reads and writes from both the HyperBacSrv.exe and SQBCoreService.exe through Task Manager.

Of course, you could also try backing up using *.HBC file format to see if you experience a better or similar performance too, but it's not a known issue at the moment with that as a workaround.

Pete

epetro

We have purchased and installed SQL Storage Compress 6.0.0.320 on our QA server. I have 2 compressed databases on same disks as their non-compressed counterpart.
The backups are performing at a similar rate (132MB/sec to 136MB/sec).

I will post another update as we continue to convert existing databases to a compressed solution. Perhaps having 5 compressed databases found a bottleneck in the other server or unknown factors are to blame.