EMC (DD) vs IBM (ProtecTIER) vs HPVLS

[djchopps0013]

Ok so i have beat the internet down looking for resources on this subject specifically in relation to how each play with TSM. I have found minimal answers and at best all speculation. I have posted several messages here but nobody wants to put their two cents in! So I said screw everybody else who doesnt want to help on this forum, I will do the damn thing myself and provide some feedback for other TSM users.

We will test the following:
IBM Protecteir
EMC DataDomain
HP VLS 9000

HP VLS 9000 (Week 4)
So far we started with a HP VLS 9000 with 80TB of raw capacity. We have been running this POC for a few weeks now and had some promising results. So far what I have seen in just SQL data and daily incremental's is around a 5:1 reduction rate.

This doesn't use a global deduplication so this could potentially be a handicap. It uses SEPATON's Delta Stor technology. This compares streams against one another and dedupes against previous streams. It uses background post processing so you dont have to schedule the dedupe like with others.

So here is the breakdown keep in mind the type of data.

1. Baclient daily incremental
2. SQL daily full with hourly logs
3. Oracle is writing to this same device, but havent had FORMAT changed in RMAN script, so the device is seeing every Oracle backup as a unique instance and therefor doesnt de dupe it. Oracle data is approximatly 40% of our data load, so the numbers are a bit skewed.

Logical Data 47.88
TB Used Capacity 10.15 TB
System Ratio 4.7:1
Space Savings 78.79%





We will be making Oracle RMAN script changes in next day or two and should see some additional results.

Some reductions in SQL data are over 10K:1 so base on these numbers I believe we will get good results from Oracle as well.

State Backup Name Policy Backup Time Type Logical Size* Physical Size* Dedupe Ratio*
STLDBCLUT_SQLCCMST_1256974769_207764106-1 DEFAULT 2009-10-31 03:26:35 - 320.93 GB 72.21 GB 4.4:1
STLDBCLUT_SQLCCMSRT_1256969059_207740051-1 DEFAULT 2009-10-31 02:13:45 - 320.89 GB 62.92 GB 5.1:1
STLDBCLUT_SQLCCMSRT_1256889373_207377548-1 DEFAULT 2009-10-30 05:49:45 - 320.89 GB 76.98 GB 4.2:1
STLDBCLUT_SQLCCMST_1256891209_207386899-1 DEFAULT 2009-10-30 05:18:05 - 320.93 GB 71.43 GB 4.5:1
STLDBCLUT_SQLCCMST_1256800150_205911884-1 DEFAULT 2009-10-29 03:28:44 - 320.93 GB 7.82 MB >10,000:1
STLDBCLUT_SQLCCMSRT_1256798414_205871064-1 DEFAULT 2009-10-29 01:47:04 - 320.89 GB 18.26 MB >10,000:1
STLDBCLUT_SQLCCMST_1256716336_205412759-1 DEFAULT 2009-10-28 03:15:04 - 320.93 GB 5.93 MB >10,000:1
STLDBCLUT_SQLCCMSRT_1256714403_205406313-1 DEFAULT 2009-10-28 02:33:19 - 320.89 GB 16.00 MB >10,000:1
STLDBCLUT_SQLCCMST_1256631447_204783355-1 DEFAULT 2009-10-27 03:51:04 - 320.93 GB 14.93 GB 21:1

 

[philfote]

I can tell you whatever you want to know about protectier vs dd with TSM. What would you like to know?

 

[djchopps0013]

I can tell you whatever you want to know about protectier vs dd with TSM. What would you like to know?

Anything you would like to share. Who did you pick in the end? what type of rates did you see? Better than we are seeing with HP so far?

 

[philfote]

It seems like overall DD gets better (~10:1) dedupe rates than PT (~4:1), however it depends on how aggressively you use TSM data reduction techniques before the data hits the VTL. DD and PT take very different approaches towards VTL; PT is from its heart a VTL, tape replacement. DD's strength is in its NAS functions and replication. VTL is more of an afterthought for DD. PT scales vertically, DD scales horizontally. I've worked with both, so it wasn't really a matter of picking one over the other. Each has strengths and weaknesses in different areas. Both solutions do true inline dedupe. PT's defrag processes run in the background and require no intervention or scheduling. DD does have a process that needs to run during a 'quiet' time which we all know is difficult to find with a properly sized TSM server (busy all the time! never idle!). PT is very VERY sensitive to backend disk performance. (it doesn't slow down, it goes off a cliff and starts failing writes) DD has a better handle on this since its an integrated system, but doesn't scale to the throughput heights that a properly laid out and utilized PT system can.

Hope this sheds some light for you. Let me know if you have other specific questions. I'll be interested in how your HP testing goes.

 

[djchopps0013]

So in your testing PT only got about a 4:1 reduction rate? Not too good. So in your opinion if your looking for scalability and performance you might lean towards the PT solution? If you are looking for better reduction rates and replication then the DD would have a favor?