New in VBR v12: True per-machine backup files

Posted: June 13, 2022/Under: Veeam/By: vNote42

Veeam Backup&Replication (VBR) v12 is coming soon. So its time to get to know its new features and improvements. And there are a lot of them! I already started a blog series about smaller features and improvements. This post is about a new feature that helps manage a machine more individually within and between backup jobs. Project title: True per-machine backup files.

With it you can:

Move machines between backup jobs.
Trigger active full and retry on machine instead of job layer.
Run health check separate from job

True per-machine backup files

The per-machine backup files feature is available for some time now. With it each machine in a job gets its own backup files. It is a repository setting.

Since there are more advantages (more parallel processing, smaller files to handle, …) than disadvantages (worse deduplication rates), I always recommend this setting. New in v12: per-machine backup files is set by default when adding a new repository.

On closer inspection, you may have noticed that the metadata for the machines in the backup has not been saved for each machine separately. Description file (.vbm) was saved per job as you can see in the screenshot.

Two VMs in a job but just one .vbm-file. For true per-machine backup files it is necessary to save metadata per VM individually. This was done in v12! Each VM gets its own .vbm-file.

What is it for

Move machine between backup jobs

With true per-machine backup files it is possible to move machines between backup jobs. Before v12 you can remove a machine from a job and add it to another one. But files stay where they are and next backup will be a full for this machine. With v12 and true per-machine backup files this can easily be done in the console. VBR also moves (respectively – in case of immutable backups – copies) the files for you. Next backup is either incremental or full, depending on target job settings. File transfer is done by another new feature in v12. It allows to move backup chains between repositories without losing fast-cloning space efficiency. I will cover this feature in another blog post.

So how does it work? First select the machine in the disk backup you like to move. Right click and select Move backup… Then choose the the backup job.

The following tasks are done by VBR:

Disable the target job.
Remove machine from source job.
Moves the data.
Add machine to target job.
(if not immutable) Remove data in source job repository directory.
Enable the target job.

After the transfer is completed backup data is moved to target job.

In case, backup files are immutable, VBR cannot move these files. So they will only be copied. Source files will still be visible beneath Disk (Orphaned).

Additional notes

If you move a machine from a Linux Hardened Repository to another repository and back again, you will get a error like this: Error: Agent failed to process method {Stg.RemoveFile}. This is because files still exists is the directory of the formally source job. Remove the files there, rescan the repository. Afterwards Move Backup will work.
For the history of backup move jobs, there is s a separate section in History.

Full backup/retry for a single machine

With v12 and true per-machine backup files you can start a Active Full and/or a Retry task of a individual machine within a backup job. Simply right-click the machine of choice in job history and select right action.

Run health check separate from job

With v12 it will be possible to run Storage-level corruption guard separate from job schedule.

Up to now health check started immediately after the job was finished.

How to get true per-machine backup files

A new job created in v12 will automatically create a description file per machine. But what happens when older backups are imported? You can easily upgrade the backup chain format to the new true per-machine backup files. I guess this will also be the way to upgrade existing backup chains after upgrading to v12.

My example shows imported backups on a ReFS Repository. One .vbm-file for the whole backup job.

To upgrade the chain format, select the backup job beneath Disk (Imported). Either right-click or select the button Upgrade Backup Chain Format in the ribbon menu.

A window shows the status of the upgrade task.

Afterwards each machine in the job has its own .vbm-file. Old .vbm-file remains as a backup.

Limitation

Unfortunately this upgrade does not work with immutable backup files – at least in beta version! Which is a great pity because Linux Hardened Repository backup files cannot be updated this way!