Note: The description in the article is based on Veeam Backup & Replication 12, licensed using Veeam Universal License (VUL), similar to Enterprise Plus.
Backup Chain Formats
In Veeam Backup & Replication 11, two formats of backup chain files (Backup Chain) are used, which determine how backup files are stored.
- Single-file backup - the backup job stores data in a single file (creating one write stream) and creates one metadata file, the default format in version 11
- Per-machine backup file - the backup job stores data in a separate file for each VM (Workload) and creates one common metadata file, all backup files created during one session are considered as one restore point
In Veeam Backup & Replication 12, the backup files for individual machines (Per-machine backup file) have been modified.
- Per-Machine Backup with Single Metadata File - the original version, where we have a common metadata file, cannot be created in version 12, but the original backups still work the same
- Per-Machine Backup with Separate Metadata Files - the new (and default) version, stores data in a separate file and creates a separate metadata file for each VM (Workload), thus each VM (Workload) has an independent Backup Chain
Veeam recommends using Per-Machine Backup with Separate Metadata Files. Compared to the older version, it allows new operations such as move backup or run Full Backup for individual Workload. Agent backups (Veeam Agent Backup Job) ignore the settings and (simplified) create separate backup files for each machine.
Backup Chain Format Settings
The configuration of how backup files are stored is done on the Backup Repository using the checkbox Use per-machine backup files. If we change the additional settings, the change will not apply to existing jobs.
If we upgraded Veeam Backup & Replication to version 12, the backup jobs still store backups in the original way. As for Per-Machine Backup with Single Metadata File, we can easily change the format to Per-Machine Backup with Separate Metadata Files.
But be careful if you use Backup Copy Jobs. The source objects (backups) must be in the same format as the Backup Copy Job. If we upgrade the backups for the Backup Job used in the Backup Copy, we must also upgrade the Backup Copy Job. If we upgrade the Backup Copy Job, we must upgrade all backups copied by it.
If the Backup Copy Job is not upgraded, and the source backups are, the job will return an error:
Legacy backup copy jobs do not support new backup chain format of the source backup. Please recreate a backup copy job and map your existing backup files to the new job.
Upgrade Backup Chain Format for Backup Job
Upgrading the original Per-Machine Backup with Single Metadata File to the new Per-Machine Backup with Separate Metadata Files is simple and quick. But it cannot be reversed. Using the Veeam Backup & Replication Console, we perform:
- Home - Backups (or Disk)
- right-click on the job
- select Upgrade backup chain format
- after confirmation, the progress is displayed, the actual upgrade takes a few seconds and separate VBM files are created on the file system
- finally, we need to enable the Backup Job that creates the backup (it was turned off at the beginning of the operation)
Note: Completed upgrades can be found in the history section under System.
Move backup - moving backups
Newly, Veeam Backup & Replication allows moving backups using the console (instead of the original more complex procedure). We can move all backups of a certain backup job to another repository or a certain object (workload), and its backups, to another job. In various places, the term VeeaMover is used, but not in Veeam documentation.
If we want to move backups of a certain VM to another Backup Job, the backups must be Per-Machine Backup with Separate Metadata Files. The implementation is simple. Maybe not as efficient as if we did the move manually on the file system, because the data is always copied.
- Home - Backups
- expand the corresponding backup
- right-click on the object (we can select multiple objects at once)
- select Move backup
- select the target job to which you want to move the backed-up object
- at the beginning, the source and target job are turned off
- the backup files are moved, which are copied (possibly newly created), it takes time depending on the speed of the repository, if possible, Fast clone is used
- records in the configuration DB are modified, the object is removed from the original job and added to the new one
- the original files are deleted
- the jobs are turned back on
Backup Copy Job
Backup Copy Jobs are a special type of job and usually copy backups created by a backup job. They are therefore dependent on them.
Changes in version 12
Veeam Backup & Replication 12 (in my opinion) significantly changed the Backup Copy Job. There are minor changes that are nice and Veeam advertises them.
- original jobs (after upgrading Veeam) are marked as Legacy Backup Copy Job and work as before (we can edit them, but not create new ones)
- new jobs are no longer platform-dependent (we can combine VMware, Hyper-V, agent) and are divided into Image-level backup and Application-level backup
- we can change the Copy Mode (Immediate or Periodic) after creating the job
- always creates Per-Machine Backup with Separate Metadata Files
- Periodic Copy jobs no longer run continuously (Continuous), but are triggered by a scheduler (so Backup Copy Intervals are no longer used), we set a standard Schedule (we can also set a Backup Window)
But the options for what objects (workloads) we can include in the job in periodic copy mode to copy their restore points to the target repository have fundamentally changed. The options are now the same for both Copy Mode (Immediate or Periodic). The only description is in the documentation Step 3. Select Workloads to Process (I have not come across any notice of this change).
We can no longer select individual VMs. Which was previously possible using the From backups option (from backup) or From Infrastructure (from infrastructure).
The source types available are:
- From jobs - we select a specific job, it copies all Restore Points created by that job (all objects contained in the job)
- From repositories - we select a specific backup repository, it copies all Restore Points stored in that repository
Note: The documentation still mentions the From backups option, but there is a (subtle) note that it is only available for Amazon EC2 instances, Microsoft Azure, and Google Cloud backups.
One argument is that we can use Exclusions. But if we remove all VMs that we do not want to copy, then when adding a new VM to the backup job, we must also remember to remove it here. We can work with VM tags here.
Upgrade Backup Chain Format for Backup Copy Job
For Periodic Copy Mode, we can upgrade the original Per-Machine Backup with Single Metadata File to the new Per-Machine Backup with Separate Metadata Files only by creating a new job and mapping the backups. Before we start, we need to have all source backups upgraded.
If we previously selected VMs for copying from different jobs (perhaps because different backup parameters were used), we have a problem. The only option is to split the original Backup Job into two. And have backup jobs that contain only the VMs we want to copy. The procedure is quite simple, but it disrupts the prepared backup concept.
Splitting the backup job into two:
- Home - Jobs - Backup
- right-click on the job
- select Clone
- in the newly created job, select Edit
- edit the name and remove all VMs except one, set the scheduler
- move the backups of the VMs that should be in the new job, Move backup (described above)
Creating a new job with file mapping:
When we have prepared the backup sources for the new Backup Copy job, we create it and map (upgrade) the files of the original job.
- turn off the original Backup Copy Job that we want to upgrade
- create a new Backup Copy of the Image-level backup type
We use the same settings as in the original job. The main items for migration are:
- Objects - select the sources (we should ensure that all objects from the original job are included)
- Target - select the same Backup Repository, click on Map backup and select the original copy job
- we get a message that it is a Legacy Backup Copy Job, so a new Full Backup will be created from the last Restore Points in the target repository (it does not transfer data from the source) and will continue incrementally, the original Backup Chain will be disconnected (we will see it under Disk (Orphaned)), confirm with Yes
- complete the settings up to Finish (probably do not check to start the job immediately)
The job is created. Immediately, a check of the objects in the backup (Checking objects in backup) and then Backup chain format upgrade will start. An export of VMs specified as the source and found in the original backup copy will be performed. If possible, Fast clone is used. There must be enough space in the repository to store the full backup.
When the upgrade is complete, turn on the job and set the scheduler.
Note: If we forgot to add any VMs to the sources, after adding them, a complete copy to the target will be performed (new mapping cannot be done to synthesize a Full Backup from the data in the repository). During the first test, I chose to start the job immediately after creation. The upgrade did not occur, but a complete backup copy started.
There are no comments yet.