Note: The description in this article is based on Veeam Backup & Replication 12.1, licensed with Veeam Universal License (VUL), which is similar to Enterprise Plus.
Backup Copy
The functioning of Backup Copy Job in Veeam Backup & Replication 11 was described in the article Veeam Backup & Replication - Backup Copy Job and WAN acceleration. The article also describes the same practical situation, i.e., creating a Backup Copy Job with offline transfer of the initial full backup. However, in Veeam Backup & Replication 12, there have been quite significant changes, which this article covers.
Changes to the backup chain format, new features in Backup Copy Job, and upgrade options are described in the article Veeam Backup & Replication 12 - Backup Chain and Backup Copy format upgrade.
Briefly About Backup Copy Job
To create backup copies, Veeam Backup & Replication offers the Backup Copy task. It allows the creation of multiple instances of the same backup data in different locations, either in the same locality or elsewhere. Backup copies have the same format as backups created using Backup Job. Simply put, data is copied (synchronized) from one storage to another according to defined rules.
For a backup copy, we define our own retention policy to maintain the desired number of restore points. Optionally, we can also define GFS retention (long-term retention policy) for storing full backups for archiving purposes, as well as other backup parameters.
Basic Features
- Tasks are divided into
Image-level backup
andApplication-level backup
- Different platforms (VMware, Hyper-V, Agent, etc.) can be combined in Image-level backup
- The copy mode can be either
Periodic copy
(periodic copy, common usage) orImmediate copy
(immediate copy, mirroring); the mode can be changed later - For VM Backup Copy Job, it connects to virtualization servers and gathers information about VMs whose restore points we want to copy
- The transfer uses source and destination Veeam Data Mover, possibly along with WAN Accelerator
- The first run always creates a Full Backup (we can use Seeding and Mapping for the initial copy), subsequent runs are incremental, utilizing Forever Forward Incremental
- A Per-Machine Backup with Separate Metadata Files is always created (even if the storage is set up differently)
- For tasks in Periodic copy mode, a scheduler (Schedule) is typically set up to determine when the task should run (previously, it ran continuously); this is a major improvement in the new version
Objects That Can Be Included in the Task (Copied)
We can copy backups of VMs (VMware, Hyper-V, Azure, etc.), backups using Agents, backups using Plug-ins (enterprise applications), and backups of file servers.
In a Backup Copy Job, we select objects (workload) whose restore points we want to copy to the target storage. We can choose from source types:
From jobs
- we select a specific task, copying all Restore Points created by that task (all objects contained within the task)From repositories
- we select a specific backup repository, copying all Restore Points stored in that repository
Note: In the older version, it was possible to select individual VMs for copying. This is no longer possible.
Note: Transaction logs can only be copied in Immediate copy mode.
Therefore, in a Backup Copy Job, (for example) all VMs that are backed up by a specific task or that are stored in a specific repository are included.
To apply restrictions, we can use exclusions with Exclusions
. These are only available for VMs. We select the added object (Backup Job, Repository) and click the Exclusions button. We can select individual VMs or objects from the virtual hierarchy (servers, clusters, datastores, tags). For repositories, we can also select specific Backup Jobs.
Upgrading Backup Copy Job to Version 12
If we have a Backup Copy Job created before version 12, it operates in the old mode (Legacy). We can upgrade it. The process is described in the official documentation and was briefly covered in Veeam Backup & Replication 12 - Backup Chain and Backup Copy format upgrade. Here is a small addition.
First, we need to upgrade the Backup Chain format for source backups to Per-Machine Backup with Separate Metadata Files. This is simple and quick because it only generates new VBM files.
For Backup Copy Job in Periodic copy mode, the only upgrade option is to create a new job and map the backup files. When mapping, information will be displayed that it is a backup created using Legacy Backup Copy Job. In the current version of Veeam, it is not possible to set the job to run immediately after completing the editing (which is good, as the upgrade wouldn't take place). After completion, the backup objects are checked, and the Backup chain format upgrade is performed.
During the upgrade, a new folder is always created, and a full backup is synthesized (VMs are exported from selected/mapped backups in the target repository). The original files are never used as in standard mapping, so there must be enough space on the repository for another Full Backup. After completion, the original backups are detached and found under Disk (Orphaned).
I have never utilized Fast clone, so the process for large backups takes a long time and consumes a lot of space. Therefore, instead of upgrading, I performed a new data transfer to an external disk (Seeding), as described below.
New Backup Copy Job and transfer of the initial full backup to an external disk (Seeding)
A real situation I've dealt with twice. I found that in Veeam Backup & Replication 12, it must be done differently than I did the first time.
This is a backup of a file server running as a VM on VMware vSphere, and its size is about 6 TB. We want to copy it to a remote location that is connected to the headquarters by a 200 Mbps link. The initial full backup copy (initial synchronization) would take quite a long time, so I decided to transfer it offline on an external USB disk. This is known as Seeding.
Subsequently, the task is mapped to the transferred backup. This backup is used as the starting point (Seed) for further backup copies. Subsequent runs of the copy job will copy only the incremental changes and store them as new restore points alongside the starting backup. The folder with the mapped backup is used for storing data.
Note: A general tip: If you are doing something more complex, such as traveling to a remote location, it's a good idea to thoroughly test everything in advance. During testing, I found that there was a change in the possible source for mapping, so the exported backup I used last time cannot be used.
Steps for creating a Backup Copy Job with a mapped backup
The official procedure for creating a Backup Copy Job, where the initial data copy (Full Backup) is not transferred over the network but in another way, and then mapped to the job.
- Create the Backup Copy Job - add the objects you want to copy, and as the target repository, select a local Backup Repository where the files for transfer will be prepared (it cannot be the same repository where the source backups are located)
- Run the Backup Copy Job to create the file with the Full Backup
- Move the backup folder (VBK, VBM files) to the target repository
- Rescan the target repository (Rescan)
- Map the backup file to the Backup Copy Job
Limitations for Backup Copy Job
One limitation (I would say unnecessary) is that the target repository cannot be the same as the source (where the copied backups are stored). So, we cannot copy backups to the same repository from which they are retrieved. If we only have one in the location, that’s a problem.
Another new limitation in Veeam Backup & Replication 12 concerns mapping backup files. The Backup Copy Job can only be mapped to backups created by Backup Copy Job. Previously, we could also map to backups created by Backup Job. We could take the latest full backup directly, transfer it to the target repository, and map the copy job. Or use the export of the backup. Now, such backups are not offered at all. Yet it should only be data in the VBM file (the VBK should be the same). The only information is in Limitations for Mapping.
Using an External USB Disk
The last time I dealt with this situation, I had 2 external SSD disks (4 TB) available. So, I needed to split the Full Backup file. I used Export Backup, which, thanks to Fast Clone, was quick and didn’t take up space. The resulting VBK was split and stored on external disks using Total Commander.
Note: This time, I also tried exporting initially and encountered a problem. On the Scale-Out Backup Repository, the export was always saved to a different Extent than where the backup was stored, so Fast Clone was not used. Then I found that the files created by the export could not be used for the new Backup Copy Job, so I didn't investigate further.
Currently, I had a larger external rotational disk (8 TB) available, so the issue of splitting the backup was eliminated. I used NTFS with a block size of 2 MB (I also tried ReFS with 64 kB, and copying ran at the same speed). Copying to SSD disks was faster (averaging 280 MB/s), but the rotational disk is also sufficient (averaging 165 MB/s).
Since we have to create a full backup file using Backup Copy Job (and we can't use a single repository), it seems best to create a new Backup Repository from the external disk. When creating the initial Full Backup, it will be saved directly to the external disk, eliminating the need for additional copying.
Veeam Backup & Replication runs on a physical HPE server (connected to disk array spaces, so there is also a Repository) to which I connected the external disk via a USB 3.0 port. At the branch office, the target Repository is in a VM on VMware ESXi. I connected the disk to the USB 3.0 port of the physical server and added a USB device in the VM configuration (Add USB Devices from an ESXi Host to a Virtual Machine).
My Steps for Creating Backup Copy Job with Mapped Backup
- Connect the external disk and create a Backup Repository from it
- Create a Backup Copy Job - add the objects you want to copy, and as the target repository, select the newly created Repository (external disk), direct transfer (no WAN acceleration), no scheduler
- Run the Backup Copy Job, so the Full Backup is created and stored directly on the external disk
- Disconnect the external disk and transport it to the target location
- In the VM, connect the external disk via USB passthrough (or alternatively connect it to another physical server)
- Add the external disk as a Backup Repository
- Rescan the Repository, check that everything was found correctly
- Disconnect the disk and assign the correct Repository (target)
- Run the Backup Copy Job and check that the backup is mapped (check that it does not generate a new Full Backup)
Creating a Backup Repository
Adding Microsoft Windows Repositories
- Backup Infrastructure - Backup Repositories - Add Repository
- select Direct Attached Storage - Microsoft Windows
- Server - select the Repository server, click Populate, and choose a disk (connected external disk)
- Repository - specify a folder for file storage, manage load balancing, under Advanced you can adjust special parameters; if the disk is not formatted with ReFS, you will receive a notification
Creating a Backup Copy Job
Creating Backup Copy Jobs for VMs and Physical Machines
- Home - Backup Copy Job - Image-level backup copy
- Job - enter a unique name, Copy mode: Periodic copy
- Objects - add the objects you want to copy
- Target - select the target Repository, Retention Policy, and Advanced parameters (scheduled file maintenance (Defragment and compact full backup file creates a temporary full backup, so it requires space), data reduction, notifications, scripts)
- Data Transfer - choose Direct or Through built-in WAN accelerators
- Schedule - you can schedule automatic job execution
Starting the Backup Copy Job
- Home - Backup Copy Job
- right-click on the job and select Start
Rescanning the Backup Repository
- Backup Infrastructure - Backup Repositories
- right-click on the repository and select Rescan
Note: The backup that was transferred will appear under Home - Backups - Disk (Imported).
Mapping the Backup File
- Home - Jobs - Backup Copy
- right-click on your job and select Edit
- Target - change the repository to the remote location, click Map backup
- select the backup that was transferred to the remote location
- Data Transfer - if used, switch to Through built-in WAN accelerators
WAN Acceleration and Creating Fingerprints
In Veeam Backup & Replication 11, I encountered an issue. When using WAN acceleration, during the first job run, Fingerprints (Digests) are created for all copied disks. This process took a long time and did not finish within the copy interval.
In Veeam Backup & Replication 12, the issue is resolved. Since you can manually start the job, there is no issue with the copy interval.
There are no comments yet.