Dell Data Domain Replication in Veeam

If you run Dell Data Domain at both production and DR, Veeam Backup & Replication v13 gives you a cleaner way to keep that secondary copy in sync: Managed File Replication (MFR) through the new Storage Copy Job.

Instead of pushing data through the regular backup copy path, MFR uses DD Boost to move backup files server-side between Data Domain systems. Files land on the target exactly as they’re stored on the source: no transformation, and no staging through the Veeam gateway server for processing.

How it works

On its first run, the job copies all existing supported backup files. After that, it’s event-driven: a new backup file appearing on the source triggers the copy.

Before you start: design checks

A few rules will save you a failed wizard or a messy topology later:

• Source and target must be supported Data Domain repositories, or scale-out repositories made up only of Data Domain extents.
• For scale-out repositories, set the placement policy to Data locality.
• No data-flow loops between repositories.
• Don’t reuse the same source → target pair across multiple Storage Copy Jobs.
• The originating backup jobs must live on the same VBR server as the Storage Copy Job.

Step-by-step configuration

1. Launch the wizard

In the VBR console, start the New Storage Copy Job wizard.

2. Name the job

Use a name that shows the direction of data movement at a glance:

• Name: DD-MFR-Primary-to-DR
• Description: Storage copy from Production Data Domain to DR Data Domain

3. Map source and target repositories

At Storage Mapping, click Add, then pick the source and target Data Domain repositories. Unsupported repositories simply won’t show up in the lists, which is a handy sanity check. {Note it is an entire Repository}

4. Set the minimum secondary-copy retention

Open Advanced → Maintenance and configure Keep secondary copies for a minimum of.
 

This is the setting people most often misread, so here’s the logic:

1. The clock starts when the file is copied to the target.
2. When the file is deleted from the source, Veeam keeps the target copy until that minimum age is reached.
3. If the minimum age has already passed at the moment of source deletion, the target copy is removed immediately.

Example: minimum set to 30 days:

Day	Event
0	Backup file copied to target
15	File deleted from source by source retention
15–30	Target keeps the file for 15 more days
30	Target copy becomes eligible for deletion

⚠️ Data Domain note: the health-check option on this same tab applies to HPE StoreOnce only. Data Domain repositories don’t support it, so plan your integrity verification another way.

5. Define the copy window

Set when the job is allowed to move files, for example outside production backup windows or during off-peak WAN hours.

6. Review and finish

Double-check the job name, source and target, retention, copy window and replication direction, then finish the wizard.

MFR Storage Copy Job vs. regular Backup Copy Job

	MFR Storage Copy Job	Regular Backup Copy Job
Scope	Per repository: maps a source repo to a target repo and copies all supported backups on it	Per job: you choose which backup jobs or workloads to copy
Primary use	DD↔DD (or StoreOnce↔StoreOnce) secondary copies	General backup-copy workflows, any supported repository
Data movement	Storage-side via DD Boost	Standard Veeam data path
File handling	Files copied as stored, no transformation	Creates backup files per job configuration
Gateway processing	No intermediate staging for processing	Uses Veeam data-processing components
Retention	Follows the source job’s retention, with a configurable minimum age for target copies	Can have its own independent retention, including GFS
Best fit	Data Domain–standardized prod + DR	Mixed targets or broader retention needs

What you gain

• Storage-native efficiency: DD Boost handles the movement between Data Domain systems.
• Exact copies: the target holds the same files as the source.
• Simpler DR architecture: one Veeam-managed workflow for the secondary copy.
• Deletion safety net: minimum retention keeps target copies from disappearing the moment the source ages them out.

Gotchas to plan for

• Not every backup type is supported: transaction-log backups are not copied.
• Imported and orphaned backups are out of scope.
• Backup Copy Job sources need GFS: to copy backups created by regular Backup Copy Jobs, those jobs must have GFS retention enabled.
• Same-server requirement: source jobs and the Storage Copy Job must be on one VBR server.
• No health check on Data Domain.
• Topology discipline: no loops, no duplicate source→target pairs.

Bottom line

If you’re already standardized on Data Domain at both sites, MFR is the more storage-native way to keep a DR copy: DD Boost does the heavy lifting, files arrive untouched, and the minimum retention setting gives you a buffer against premature deletion. Before rollout, check which backup types you need covered (especially log backups), confirm repository compatibility, and pick a minimum retention that matches your recovery and deletion policies.

Reference: Storage Copy Job – Maintenance Settings (VBR v13 User Guide)