Compression Testing and Results

To test compression in the three products in this review, I used a 539GB real-world database loaned specifically for my testing. (A small database would not have yielded results showing how efficient a compression was.) The native backup file size that the 539GB backup generated was 440.53GB.

The server I used ran Windows Server 2003 Enterprise Edition x64 with 4GB of memory and had an AMD Opteron 144 1.8GHz single core processor. The disk configuration was two drives: one 250GB drive for the OS, and one 1TB Seagate Barracuda ES.2 SATA drive for the backups and the data to simulate many clients where the backups and data live on the same set of disks. I used SQL Server 2005 Enterprise Edition x64 with SQL Server 2005 Service Pack 2.

I generated all results by using default settings for the fastest time according to how each tool defines that time. All compression tools will add some amount of CPU overhead. This number will vary depending on your systems, but it’s an important measurement to consider. You should run any tool you evaluate on your systems against your databases to get an accurate idea of how it will work on your standard server configurations.

Table A shows the test results. The asterisk next to the native SQL Server times denotes that they are estimated. I restored the database for the test from an external USB drive to the 1TB drive. Making a full backup on the 1TB drive wasn’t possible because the actual database files took up about 540GB (formatted, the 1TB drive has 931GB of usable space).

To estimate the backup time, I backed up one of the 200GB files that made up the database, then restored it. The backup took 3:20:21, was 179.75GB, and had a throughput of 16.051MB/sec. The restore took 3:07:19 with a throughput of 17.167 MB/sec. To get the numbers listed in the table for the native timings, I extrapolated the data, knowing how large the entire backup file was. What I did underscores the reason behind most of these compression tools: There comes a point when the database gets so large that you don’t have enough space to make a full backup on your drive, so you get creative (e.g., by making file backups, shrinking data or log files, and so on).

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.