A small virtualization shop runs a backup server that can only write its backup files to mounted shares; the product offers no plug-in or appliance integration of any kind. The new Data Domain must serve as the target anyway. What has to exist on the appliance side for this backup connectivity?

Target-side deduplication happens when data is ingested into the filesystem, independent of the protocol that delivered it, so a backup application with no integration support can still benefit from the appliance through a plain file share. The connectivity design is concrete: create a dedicated MTree for this consumer, enable the CIFS or NFS service, create a least-privilege user scoped to that path, and have the backup server mount it, with client-side persistence configured so the mount survives reboots. The honest trade-off is that all data crosses the network in full and single-session file protocol limits apply, but the appliance still stores only unique segments. The claim that file mode stores every byte verbatim fails by mechanism, since ingest deduplication is protocol-agnostic; what file mode forfeits is only the source-side elimination that Boost-class integrations provide. The optimized-endpoint requirement reverses the situation: integration endpoints exist for applications that support them, and an application without plug-in support simply cannot use that path. Virtual tape presents SCSI tape devices, not a filesystem, so a product designed to write files has no way to address drives as disks. Exam caveat: restrict which clients may mount the share rather than opening the path to the subnet. Operational check: mount the share, run a test backup, and confirm the MTree's deduped logical-versus-physical usage before accepting.