Here is a scenario:
-- A machine running server 2012 r2 already has a volume drive letter "Z:\"
-- On said server, the volume drive letter "Z:\" is 930 GB in size
-- On said server, the volume drive letter "Z:\" is already regularly deduplicated/scrubbed/garbagecleaned according MS recommendations
-- On said server, the volume drive letter "Z:\" (930 GB physical) holds a reyhdrated storage usage of 1.9 TB
-- On said server, the volume drive letter "Z:\" (930 GB physical) dedup optimized has saved space of 617 GB... free space of 244 GB
According to MS:
-- A backup that is NOT "server 2012 dedupe optimized" will require a full rehydration of chunkstore and 1.9 TB of space on destination.
-- A backup that IS "server 2012 dedupe optimized" will NOT require a full rehydration of chunkstore and ONLY require 762 GB of space on destination.
-- If VEB is used to backup the volume in scenario above (where said volume is already "server 2012 deduped")
-- Will VEB require full rehydration or will VEB recognize the existing data deduplication?
VEB does a fabulous job already, although I didn't read anywhere if it is "server 2012 dedup optimized". Granted VEB will not likely require 1:1 destination storage the way wbadmin does, this makes it hard for me to ascertain if VEB is/not "server 2012 dedup optimize".
(FYI I am *not* asking if VEB backup files will dedupe -they do, nicely- I *am* asking if VEB backup technology will recognize the existing server 2012 deduped volume in it's existing optimized state.)
P.S.: Intellectually curious, a follow up question: If VEB is "2012 dedup optimized" does this change anything in VEB approach to incremental methodology? Perhaps it is merely incremental backups of changes to the chunkstore + files.