An administrator enables deduplication and compression on an AOS container that stores guest-encrypted, already compressed database backups. What reduction should be expected?
Select an answer to reveal the explanation.
Short Explanation
Think of it like squeezing a sponge that's already dry: dedupe and compression need patterns to find. If your backups are already encrypted and compressed, they look like random noise, so your container won't shrink much. Don't expect AOS to magically undo entropy; plan capacity for the real post-reduction size.
Full Explanation
Nutanix AOS data reduction depends on finding repeated block patterns and compressing predictable byte sequences. When guest encryption or prior compression is applied before data reaches the container, the resulting ciphertext or compressed stream has high entropy and very little recognizable redundancy. Deduplication therefore matches few blocks, and compression algorithms achieve little additional shrinkage, so effective capacity approaches the original data size. A belief that encryption creates uniform ciphertext blocks is incorrect because properly implemented encryption is designed to produce pseudorandom output, not repeatable patterns. A belief that compression removes entropy from encrypted data is also incorrect because compression encodes existing redundancy; if entropy is already high, there is little structure left to encode. A belief that AOS disables data reduction for encrypted container data is likewise wrong: the data-reduction services can still process the blocks, but their measured benefit is expected to be low rather than absent by policy. Exam caveat: treat low data reduction on encrypted or compressed workloads as a capacity-planning observation, not as evidence that a feature has been administratively disabled. Operational check: measure container-level data reduction before and after enabling the feature, then size runway from measured effective capacity.