We've been working our way out of a space problem (a lack thereof) by implementation of dedupe. This has caused a problem which I'll attempt to describe.
We were sent a document "TR-3958" which describes Compression and Dedupe best practices. A key paragraph is as follows:
"Transient and temporary data such as VM swap files, page files, and user and system temp directories do not compress or deduplicate well and potentially add significant performance pressure when compressed/deduplicated. Therefore NetApp recommends keeping this data on a separate VMDK and volume that are not compressed/deduplicated. For more information on page files refer to TR-3749, NetApp and VMware vSphere Storage Best Practices."
This fitted well into our environment going into the implementation of dedupe as we had already got an environment whereby temporary data and vm OSes/Apps were segregated on different datastores.
However, we use OnCommand for performing backups of these Datastores and this is where the problem comes in
: since an OnCommand Dataset contains both "Data" (our OS/Apps datastores) and "Spanned Entities" (the temporary data datastores) we are finding that the Protection Manager provisioning policy which describes the use of dedupe and underpins the dataset is causing a "non-compliance" issue on some of our temp datastores (which are in volumes > 25TB) and has forced other volumes which contain temporary data to be deduplicated.
I can't see a way out of this problem. We don't want to "select" the temporary areas for omission in the backup as - whilst the actual contents of them would never need to be restored, the ability to restore the *structure* they contain is useful in speeding up DR.
In addition, it's our (constantly frustrating) experience that spanned entities which are selected for omission in OC Datasets don't stay selected - we're constantly having to tidy-up snapshots and snapvaults which magically appear as switched off items switch themselves back on again.