How can we help you today? How can we help you today?

Backup Compression and Duration

After the comments about compression in the update email this morning, i thought it might be helpful to start a thread on the performance that has been achieved so far.
I have included stats from 2 existing production copies for reference.
Unfirtunately the test DBs for the prelease server are only DW data, so the data density is naturally lower and more compressable
Hopefully someobdy else can fill in the gaps with some OLTP DB stats?


SQL Backup V6 PreRelease (local DB backup to local non-RAID storage on single core 3.5GB Server )

DBSize DBType %Full Comp Lvl Comp % Duration
17.3GB DW 99 4 96 00:13:20
17.3GB DW 99 3 87 00:05:31

8GB DW 54 4 92 00:05:20
8GB DW 54 3 89 00:03:32



SQL backup V5.4 (local DB backup to SAN storage on 16-core 16GB monster Server)

DBSize DBType %Full Comp Lvl Comp % Duration
16GB DW 93 3 92 00:00:38
13.2GB DW 67 3 90 00:00:41


SQL backup V5.2 (remote DB backup to local SAN storage from 4-core 8GB Servers)

DBSize DBType %Full Comp Lvl Comp % Duration
183GB DW 99 3 79 02:16:07
101GB OLTP 80 3 76 01:40:00
andy hughes
0

Comments

4 comments

Sort by
  • DWolford1234
    Good Lord!

    16GB in 38seconds?!?

    How do you live with yourself? :)
    DWolford1234
    0
  • andy hughes
    That was pretty much our Customer's response too :-)

    It's a hosted DW solution.
    Being DW, the data is pretty compressable, but the hosting company's server is really impressive. If I remember correctly, the native backup for this DB to the same disk only used to take just over 3 minutes
    andy hughes
    0
  • RBA
    andy hughes wrote:
    SQL backup V5.4 (local DB backup to SAN storage on 16-core 16GB monster Server)

    :)

    I wonder how level 4 would compare, given this hardware? Did you experiment with thread count at all?
    RBA
    0
  • andy hughes
    Robin

    Unfortunately, we'll have to wait until v6 is released before I can try level 4 compression on the production server.
    However, I ran a few small trials with differeing thread counts on v5.4.

    The default of 15 threads took 00:04:10
    Cutting this to 7 threads 00:04:13
    Raising it to 22 threads 00:04:16

    It's difficult with such a small total duration to see whether these are actual changes or just caused by prevailing resource conditions on the server during the working day.

    I guess we'll have to wait a while for the DB sizes to start increasing or for more customers to transfer operations into the hosted environment before we can see a substantial increase in duration.

    Feels really surreal to be wishing for backups to take longer ;-)

    Regards
    Andy
    andy hughes
    0

Add comment

Please sign in to leave a comment.