On day one a customer studies the raw capacity figures and openly doubts the deduplication marketing. During bring-up testing, what is a legitimate way to answer that doubt?
Select an answer to reveal the explanation.
Short Explanation
Marketing claims don't end arguments - demonstrations do. Copy the same chunk of data twice, then look at what the system actually stored; you already know the right answer, so the report grades itself. Bring-up testing exists for exactly this kind of proof.
Full Explanation
A deduplication proof at bring-up is a controlled experiment: write data whose duplicate content you know, then compare the logical size you sent against the physical space the appliance reports consuming. Variable-length segment deduplication and compression work on everything written, so obvious redundancy must come back as a visible gap between those numbers - and because you authored the data, the expected outcome is known in advance, giving the report a pass condition instead of a marketing rerun. Retreating to the sizing calculator answers doubt with estimates; the calculator models other people's workloads and cannot show that this box, in this rack, is doing the job. Postponing to the first production cycle confuses two different claims: steady-state efficiency ratios need real workloads, but functional proof that reduction operates needs only a duplicate data set today, and the customer asked about the function. There is no upward efficiency dial that manufactures real space savings - efficiency behavior is a property of how data is stored, and massaging reported figures to flatter day one is misrepresentation, not configuration. Exam caveat: set expectations honestly - a synthetic test file shows a different ratio than a real backup stream will; the bring-up test proves function, not final ratios. Operational check: duplicate data written, logical-versus-physical figures captured from the appliance's own reports, and the evidence attached to the acceptance record.