The customer's backup administrator states that nightly backups of 40 TB of front-end data must complete inside a six-hour window. The new Data Domain appliance looks comfortable on capacity alone. What does that backup window tell the engineer during the pre-deployment review?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal: capacity says how much you keep, but a backup window says how fast it has to arrive. Forty terabytes in six hours is nearly 2 GB/s flowing nonstop, so you must prove the appliance and the network can actually absorb that rate. Size only for capacity and you still miss the window.
Full Explanation
A backup window is a throughput requirement in disguise: 40 TB of front-end data landing within six hours demands an average ingest of roughly 1.9 GB/s sustained across the window, before peaks, retries, or verification overhead. During pre-deployment review that number constrains the platform tier, network speed and interface bonding, protocol choice, and the number of concurrent backup streams, because a design that satisfies capacity alone can still miss the window. Tying the window to replication bandwidth fails because replication is a separate design input sized from the daily change rate and follows the backup rather than gating it. Claiming protocols alone decide ingest fails because a protocol sets behavior, but the window forces the whole path—appliance, network, and application concurrency—to be validated against the number. Treating the window as a dedupe target fails by concept because dedupe reduces what is stored, not the rate at which data must arrive. Exam caveat: front-end rate and appliance ingest rate differ, and DD Boost shifts some dedupe work to the client, changing what the appliance itself ingests. Operational check: divide the protected data set by the approved window, compare the result with the platform's published ingest capability, and record the margin before ordering.