Performance of directory stg pool vs file stg pool

[Silapen]

Hi,
Just like to share my expirience with performance of container stg pools (TSM v7.1.4 on Win2008R2). I'm using TDP for Vmware to backup vms directly to disk (have separate pools for data and vmctl). Server has 32GB RAM, 12 disks in RAID5 for stg pool. While using directory container stg pool, 50GB vm is backed up in 972 seconds (FULL backup):


21, 13:28:57 ANE4977I (Session: 19720, Node: PRODUCTION) Total number of bytes inspected: 50.00 GB (SESSION: 19720)
2016-03-21, 13:28:57 ANE4961I (Session: 19720, Node: PRODUCTION) Total number of bytes transferred: 25.14 GB (SESSION: 19720)
2016-03-21, 13:28:57 ANE4963I (Session: 19720, Node: PRODUCTION) Data transfer time: 972.34 sec (SESSION: 19720)
2016-03-21, 13:28:57 ANE4966I (Session: 19720, Node: PRODUCTION) Network data transfer rate: 27,100.01 KB/sec (SESSION: 19720)
2016-03-21, 13:28:57 ANE4967I (Session: 19720, Node: PRODUCTION) Aggregate data transfer rate: 16,175.72 KB/sec (SESSION: 19720)

After I changed the backup destination to non-dedup file based stg pool (same server, same volumes, same disks, same client options) backup of the same vm finished almost 50% faster.

21, 15:59:24 ANE4977I (Session: 174, Node: PRODUCTION) Total number of bytes inspected: 50.00 GB (SESSION: 174)
2016-03-21, 15:59:24 ANE4961I (Session: 174, Node: PRODUCTION) Total number of bytes transferred: 25.15 GB (SESSION: 174)
2016-03-21, 15:59:24 ANE4963I (Session: 174, Node: PRODUCTION) Data transfer time: 423.00 sec (SESSION: 174)
2016-03-21, 15:59:24 ANE4966I (Session: 174, Node: PRODUCTION) Network data transfer rate: 62,311.72 KB/sec (SESSION: 174)
2016-03-21, 15:59:24 ANE4967I (Session: 174, Node: PRODUCTION) Aggregate data transfer rate: 21,528.23 KB/sec (SESSION: 174)

In my case container stg pool does well on dedup (80% stg space savings containing 100+ Linux and Windows vms), but backup and restore performance is not that good.

Feel free to comment.

 

[marclant]

Keep in mind that the "Network Data Transfer" rate is the speed at which the data was transferred the network and has nothing to do with the write to disk and it was faster. You should do multiple tests to make sure the results are conclusive.

There's a cost too to inline dedup, it does have to dedup the data while writing it, there's the overhead of deduping the data. Note that the backups will go quicker as you backup more and more dedupable data, because duplicate chunks do not get backed up.

 

[DanGiles]

Especially if you move the deduplication to the client.
I look at the whole process of from start of backup to off-site protected. With container pools, the individual backups may take longer, but you do not have to dedupe and reclaim, so the overall process is considerably less.