If you prefer a turn-key appliance, you might want to check out the Fujitsu ETERNUS CS800 - which is cheaper and faster than the EMC DD boxes.
But if you prefer a DIY solution, what's wrong with windows native dedup? It's free and included in every 2012 R2 server you buy. Just switch it on.
Microsoft officially supports dedup with their own product DPM, provided you follow these tweaking guidelines:https://technet.microsoft.com/en-us/lib ... 91438.aspx
In short, they tell you to split your backup repository across multiple volumes that are between 5-7 TB in size, change dedup operation so it is better suited to very large container files and setup scheduling so that dedup doesn't collide with your data protection jobs.
As matte pointed out, most windows dedup limitations have been addressed in server 2016:http://blogs.technet.com/b/filecab/arch ... iew-2.aspx
I am evaluating that as I write this - with great results so far.
Personally, I agree with hans_lenze's warning: windows dedup is offline, and the target must always have enough free space to be able to ingest a full backup. And if for some reason, dedup can't finish processing all data before the next dump - the problem is vastly exacerbated.
The DD and CS appliances don't have that issue. they dedup in memory, before anything hits the drives. So you don't need to worry about free disk space. Or at least not until much much later than any offline dedup scheme.
Also, a full backup of 40TB will be... a challenge for any target. So get something that performs well! In three to five years, those 40TB will easily swell to 80TB...
At the end of the day, evaluating windows dedup is only going to cost you some time and a bunch of TB to scratch around on. Spin up a windows server VM, and test dedup on a volume of your choice. Since dedup doesn't depend on storage spaces or hyper-v, you can run it comfortably inside a VM, for testing and production purposes. In fact, my current test setup is a ~1.5 TB VHDX residing on a qnap NAS box, which I mounted on my laptop, that has been passed through client hyper-v to my server 2016 test VM. No, it's not fast.
but I am more interested in compression rates than performance right now.