Hi, here we are again with our second episode of a total of 12, interesting regkeys for Veeam products.
This month we'll zoom in into the BackupCopyMirrorAll key...
Veeam Backup & Replication's Backup Copy jobs have two modes: Immediate copy (continuous) and Periodic copy (scheduled). By default, an immediate-mode backup copy job on its first run will only process the latest backup chain, not the entire history. In practice this means if your primary backup repository has older full/incremental chains (e.g. earlier monthly or yearly archives), those older restore points are skipped. In other words, the initial synchronization only grabs the newest full backup and its increments, leaving all previous chains behind. This behavior is documented by Veeam: "Backup copy job in the immediate copy mode processes only the latest backup file chain"helpcenter.veeam.com.
If you need to replicate the entire backup history for a job (for example, seeding an offsite repository or creating a full clone of past backups), this default behavior is a limitation. You would normally have to manually copy files or run complex scripts to migrate older points.
But with the BackupCopyMirrorAll you can do this in an automatic way.
Veeam provides a hidden registry setting named BackupCopyMirrorAll to override this limitation. When enabled for a given backup copy job, the job's first run will "mirror" all existing restore points from the source repository. Technically, this key forces the job to include every restore point in its initial sync instead of only the latest one
The registry key must be created on the backup server's registry (not on each repository).
Its details are:
-
Registry Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
-
Value Name: BackupCopyMirrorAll
-
Value Type: REG_MULTI_SZ (Multi-String Value)
-
Value Data: A list of backup copy job names (one per line) that should use full-chain mirroring.
Each entry in the multi-string value must exactly match the display name of a Backup Copy Job (including spaces and case). For example, if your jobs are named "Daily Offsite Copy" and "Monthly Archive Copy", the data should contain those names (each as a separate line). Crucially, this registry value must exist before you run the copy jobs for the first time - otherwise the older restore points will not be picked up.
Configuring the BackupCopyMirrorAll Key
To enable full-chain copying, create or update the registry value. For example, using PowerShell (run as Administrator) on the Veeam backup server:
# Example: Enable full-chain mirroring for two backup copy jobs
$jobs = @("Daily Offsite Copy","Monthly Archive Copy")
New-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication"
-Name "BackupCopyMirrorAll" -PropertyType MultiString -Value $jobs
This creates a REG_MULTI_SZ value under HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication named BackupCopyMirrorAll and populates it with the specified job names. You can verify it with:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication"
-Name BackupCopyMirrorAll
Alternatively, you can add the value using regedit or reg add, but PowerShell is often easier for multi-string data.
How the this key affects backup copy behavior
With BackupCopyMirrorAll in place, the backup copy job's logic is altered. On the first synchronization run, instead of grabbing just the newest chain, the job enumerates all restore points in the source repository. It essentially processes each existing restore point as if it were "new". In practice, the copy job reads each restore point and creates a new, independent backup chain on the target repository.
This mirroring does not simply copy files byte-for-byte; it rebuilds a valid Veeam backup chain. For example, if the copy job is in Mirror mode, each original full backup in the source will be turned into an incremental backup on the target chain. The end result is that the target repository ends up with a continuous chain containing all the data from the source history.
Important:
Once the data is copied, the backup copy job enforces its own retention policy on the new chain. It does not inherit the source job's GFS (Grandfather-Father-Son) flags or retention settings. In other words, any weekly or monthly flags on the original backups will not automatically appear on the copied backups. Only the copy job's configured retention (including any GFS schedules you set on the copy job) will apply. Therefore, after the mirror operation, ensure the copy job's retention/GFS configuration is set appropriately. Otherwise, Veeam may prune older points from the target chain during its next retention run.
Use Cases and Operational Benefits
Enabling BackupCopyMirrorAll is particularly useful in scenarios where you need a complete backup history on a secondary location:
-
Offsite or Cloud Seeding: When introducing a new offsite repository or cloud archive, you often want all existing backups transferred without manual copying. With this key, an immediate-mode copy job will seed the offsite store with the full backup chain in one synchronization, saving time and effort.
-
Compliance/Retention Requirements: For regulatory compliance, you may be required to retain a certain history of backups offsite. By mirroring all restore points to a copy job, you can ensure those historical points are preserved. You can then rely on the copy job's own GFS schedule to keep, say, one full per month/year, knowing that the source's older backups were captured.
-
Dev/Test Environments: Developers or testers often need a full production dataset. Using this registry key, you can copy the entire backup chain to a separate test repository. This provides a complete set of restore points for rapid restore or data seeding, without interfering with production jobs.
-
Repository Migration: If you're migrating backups to a new storage system or upgrading the repository (e.g. moving to faster storage), a backup copy job with this setting can move the entire chain seamlessly. This avoids manual file transfers and ensures the chain is rebuilt correctly in the new location.
-
Retention Considerations: Whenever using this key, remember that the copy job's retention still applies. For example, if the copy job is configured to keep only 2 fulls, after copying the whole chain it will later prune older fulls as needed. Configure the copy job's retention (including any GFS policy) before running it so that required historical points aren't removed unexpectedly.
In each of these scenarios, the BackupCopyMirrorAll key automates what would otherwise be a labor-intensive process of replicating every backup point. By preparing the registry value in advance, your immediate-mode copy jobs will effectively "mirror" the entire source history to the target repository.
