A large virtualization estate requires roughly 2 GB/s of ingest overnight to fit its protection window. The proof-of-concept mounted a single CIFS share from the new Data Domain and a single job stream, and it managed only a small fraction of the target rate, so the administrator now suspects the appliance itself is simply too slow. What design change does this scenario actually drive?

Ingest-rate problems of this shape are access-path problems: one file-protocol session is bounded by its own per-session protocol behavior and one client NIC, and the proof of concept measured exactly that, not the appliance. The scaling levers are architectural: integrations built on DD Boost or OpenStorage drive multiple parallel streams from each media agent, concurrent jobs spread across clients, multiple network interfaces carry separate flows, and the appliance's ingest engine is designed for sustained multi-gigabyte rates when fed that way. Adding mounts behind the same single NIC does not create bandwidth that the interface cannot carry, and linear aggregation across mount points on one stream is simply not how the session limits stack; the real lever remains multi-streaming. Virtual tape reverses the intuition: emulated tape is the slow-pathing compatibility mode for legacy applications, not a performance upgrade over disk-based ingest. Declaring 2 GB/s unrealistic for the target concedes the requirement wrongly, since appliances in this class are positioned precisely for high-rate backup targets, and the failing piece here is the design. Exam caveat: check end-to-end path limits too, switch uplinks and interface speeds, before and after redesigning the access mode. Operational check: retest with the integration's multi-stream job and monitor per-interface throughput against the window requirement.