The DR plan requires a replicated copy of a new Data Domain system at a site 800 km away, and the survey measured 200 ms round-trip latency on a constrained WAN link. What determines whether this replication design is feasible?
Select an answer to reveal the explanation.
Short Explanation
Don't let that 200 ms scare you—Data Domain replication is asynchronous and sends only the unique, compressed, already-deduplicated bits, never the whole data set. What you really stress-test is the daily change rate against the bandwidth the customer can actually give you. Latency stretches the schedule; a starved pipe kills the design.
Full Explanation
Data Domain replication is an asynchronous, dedupe-aware copy of the storage pool: only unique compressed segments that exist on the source but not on the target cross the link, so the quantity the WAN must carry each cycle is the daily unique change, not the front-end data set. Feasibility is therefore evaluated by comparing that change rate against bandwidth actually available within the replication window, with latency factored into throughput tuning rather than into a yes-or-no verdict. Declaring the design impossible because replication is synchronous misstates the mechanism—the asynchronous queue exists precisely so high-latency long-distance links work. Requiring the full front-end volume nightly fails because source-side deduplication removes repeated data before transfer. Tying feasibility to matching rack hardware at each site is a category error, because enclosures at the two ends are independent and the replicated object is the logical pool. Exam caveat: a bandwidth-starved link can still succeed with scheduling changes or added capacity, so 'not enough bandwidth today' is a design input rather than a rejection. Operational check: measure daily unique change from a comparable existing system, divide it by the available replication window, and confirm the required rate fits with headroom.