If you have read all the comments carefully, you should also have noticed that we are not running backups and tape storage the according to the “best practices”.
We still use client compression on the majority of our systems.
This is due to chargebacks, based on the network traffic to our TSM servers. When we disable client compression, the amount of network traffic suddenly increased bigtime, and the chargeback also.
We are doing the changes gradually now, and the factoring rate is increasing.

Based on our policies and retentions, we were promissed 10:1 factoring. I believe we will exceed this a bit, in about a couple of months.

So, 4:1 – not as good as the promised 25:1 that would sell this to management….

• What is the retention period?
• How many versions of backup data do you keep?
• How is your backup cycle configured. Daily full, incrementals, diff and so on.
• Is the data already compressed by the client?
• And some more….. 

We have it connected to our TSM servers. On the clients, we are not in the position to do uncompressed backups, because the network interfaces are not capable of doing high bandwith traffic. Please don't start on this, because i've been trying to get those server admins to upgrade or reconfigure to at least 1 gigE.
Go lanfree you think? Yeah sure, we would, if those damn servers would be running anything else than AIX4.3. Don't start on this either. I'll give you the legacy software excuse for this

When doing prelimenary tests, we would be backing up some Oracle instances multiple times, and the factoring did kick in and went up to 20:1.
But this was not a real-life situation at all. On a variety of files, filetypes, filesizes, factoring drops until it goes up again after several regular backup cycles.
We've started with the assumption (based on Diligent homework) with a factoring of 10:1. With the current data being client compressed already, we manage to get a factoring of 4:1, which is still good from my point of view.

The image below shows the current ratio. Only a bit data is stored, in client compressed form, so this isn't really a good reference. But thought you'd like to see some information.
The curves in the graph indicates the fluctuation when brand new data is stored, and later multiple versions are stored.

If the image resizing made it too blurry for your eyes, check this life-size version right here. 

Id really be keen to know if you get anywhere near the 25:1 claims being made about this solution. Obviously it will be a while befire you will know but please keep us posted.

Im also really interested to know how they guarantee 100% data integrity? A couple of years ago a company I worked for had a little think about using a HP product called RISS which did a form of single instance storage that applied hashes against data being saved. I remember at the time being worried about the slight chances of two different sets of data generating the same hash and being mistaken for the same data. Do diligent provide other safety features?

Also when you start getting close to the 25:1 ratio Id be interested to know how much of an impact this has on restore time? Are you backing off to tape at all?

There seem to be lots of claims out there about de-duping prodcuts but I really dont know what to believe – “there are lies, damned lies and marketing materials”

I am glad your interested. We’re taking the Diligent machine into production right now. I’ll post some stats on it after a couple of weeks.

It wasn't a smooth path from the beginning though. In the beginning there were several issues with failover on backend disks, due to the fact that the multipath software wasn't really incorperated into the "blackbox" concept we though it would be. We experimented with device-mapper-multipath packages, RDAC en default kernel failover. The ProtecTier runs Redhat EL 4 update 2 under the hood. New configuration concepts in the DS4300 in combination with RDAC eventually did the trick.  

Another issue was raised when we did a path-fail test without multipath failover enabled. The ext3 filesystems were corrupted. The journalling in ext3 and fsck commands fixed the filesystems, but within the ProtecTier software, the metadata corruption couldn't be fixed. A patch to the software fixed this incorrect reporting of corruption.

In the meanwhile all problems seem fixed, as all tests went fine after applying patch 1.2.1.9.

As a side note i have to address is the fact that the Diligent support was fenominal and open. I recieved notification of all ticket updates made. Including comments and remarks from the development folks. This isn't common to my knowledge.

I think you HDS people are interested in all information about the Diligent VTF stuff, since HDS has a partnership with Diligent, right?