Backup copy job

Job layout and object selection

Copy job options

In Veeam Backup & Replication v10, a new copy job mode was added called immediate copy. As the name suggests, this mode immediately starts the backup copy job as soon as restore points appear in the repository. It also provides the ability to copy SQL and Oracle log backups which is not possible with traditional periodic backup copy.

Also, with immediate copy, all restore points will be copied from source to destination. This is unlike periodic copy which will only copy the most recent restore point in the repository. This may happen if there was a network outage between two sites. It also provides ease of configuration up as the copy job can be set up as part of the backup job wizard.

However, areas to consider before using immediately copy are; ‘select from job’ is the only source object container option, so if you require more granularity in what needs to be copied then Periodic is likely more appropriate. Immediate copy also does not support all backup types see Backup Copy Modes for full details. Finally, the backup reports for immediate mode only include the last backup metrics.

Source object container

Note that most of these apply to periodic copy only.

Select from infrastructure: This selects specific VMs or containers from the virtual infrastructure. The scheduler will look for the most recent restore point containing the VMs within the synchronization interval, and it will look for restore points in all existing backups, regardless of which job generated the restore point. If the restore point is locked (e.g., the backup job creating it is running), the backup copy job waits for the restore point to be unlocked and then starts copying the state of the VM restore point according to its defined schedule.
Select from job: This method of selection is very useful if you have multiple backup jobs protecting the same VMs. In this case, you can bind the backup copy job to specific job(s) to be the source of the backup copy. The job container will protect all the VMs in the selected source job(s).
Select from backup: This method is equivalent to the select from infrastructure method, but allows for selecting specific VMs inside specific backups. This is helpful when only certain critical VMs should be copied offsite.

Backup copy and tags

As you can select any VM to be copied from multiple backups, you can plan for policy-based configurations. For instance, you may not want to apply GFS retention on some VMs like web servers, DHCP, etc. In this situation, you can use VMware tags to simplify the management of backup copy processing. Tags can be easily defined according to the desired backup copy configuration, using VMware vSphere or Veeam ONE Business View to apply tags.

Initial synchronization

When creating the initial copy to the secondary repository, backup seeding is possible (see Creating Seed for Backup Copy Job) if the available bandwidth is too small.

While backup copy jobs were designed for WAN resiliency, the initial copy is more error prone, as it is typically transferring data outside the datacenter using less reliable links (high latency or packet loss). Another issue that can be solved by seeding is when the full backup is larger than the amount of data that can be transferred in an interval. Even if the interval can be extended to accommodate the initial transfer, this may lead to upload times of even multiple days. Seeding can speed up the initial sync by removing the need for the sync.

Note: The seed for the backup copy job must be in the same mode as the mode that will be used for the job, so either ‘immediate’ or ‘periodic’. It is not possible to synchronize between backup copy job types.

Additional options

Restore point lookup

With periodic copy, by default, after a restart of the job interval (the “Copy every” setting), a backup copy job analyzes the VM list it has to protect and searches backwards in time for newer restore point states. If the state of the restore point in the target repository is older than the state in the source repository, the new state is transferred.

To change this behavior, it is possible to use the BackupCopyLookForward registry key as described below. Reevaluating the example above, using this registry key, the backup copy job will still start searching at 10:00 p.m., but will now wait for a new restore point state created after this point in time.


Path	`HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication`
Key	`BackupCopyLookForward`
Type	REG_DWORD (32-bit)
Value	`1` = enable the option