A shared Data Domain receives backup data from Finance, HR, and Sales. Finance asks which department consumed the most appliance capacity this month. Which design decision must already exist for per-department capacity reporting to be meaningful?
Select an answer to reveal the explanation.
Short Explanation
Think of MTrees like separate filing cabinets: if Finance, HR, and Sales all dump into one pile, you can’t cleanly bill or report one department’s footprint. The trap is assuming a backup job tag or Boost setting will magically split capacity. Put each consumer in its own MTree, then capacity reporting has a path to measure.
Full Explanation
Data Domain capacity reporting is most reliable when each consumer writes to its own MTree, because an MTree is a managed namespace with its own storage accounting, quotas, and reporting boundaries. When backup software is configured to send a department or application to a dedicated MTree, the appliance can attribute logical and physical capacity changes to that path. The alternative is a shared namespace where deduplication, compression, and shared blocks make it impossible to cleanly separate one department’s consumption from another’s. Enabling DD Boost improves backup performance and offload but does not create separate accounting boundaries if all clients write to the same MTree. A single root MTree with global retention preserves a common namespace and policy, but it intentionally collapses consumers into one reporting pool. Adding department names to backup job tags may help application-side job searches, yet the Data Domain capacity view is based on stored paths and MTrees, not backup application metadata. Exam caveat: if the question asks for per-consumer capacity on Data Domain, look for MTree separation first. Operational check: confirm each department’s backup path resolves to a unique MTree and compare MTree capacity reports before and after a controlled backup.