Move-VBRBackup unsuported target job

[Seve CH]

Hello

We want to reorganize our jobs and apply a new naming convention. To do so, we want to move 400 VMs and spread them to 15 or so different backup jobs and their associated copy jobs (1 Backup job = 1 Copy job). All backups remain in the same origin repository. This should be just metadata shuffling.

I've created a lab and I have I have 2 backup jobs (VMware Backup) linked with a backup copy job each. All of them should be using per-VM metadata, files, etc.
The GFS settings and guest processing settings are different for the backup jobs. The copy jobs differ too: The first backup copy job is periodic, the second backup copy job is continuous.

BP2-BackupRepo1-01H0015-7D-BackupRepo2-30D-BC01 + Backup Copy Job 1 (backup copy job, periodic).
BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01 + BC01-ECHD2S002R01-12M10Y-P2-ECHD1S001R01-12H0015 (backup copy job, continuous).

I want to move WClient3, which is currently being managed by the first pair of jobs (BP2-BackupRepo1-01H0015-7D-BackupRepo2-30D-BC01), to the second one (BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01). All jobs are disabled.

Code: Select all

$vSourceJobName="BP2-BackupRepo1-01H0015-7D-BackupRepo2-30D-BC01"
$vTargetJobName="BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01"
$vSourceVM="WClient3"

$vBackups=get-vbrbackup -Name $vSourceJobName
$vTargetJob=Get-VBRJob -Name $vTargetJobName
Move-VBRBackup -Backup $vBackups -Job $vTargetJob -Name $vSourceVM  -Confirm:$false -Force -RunAsync

This throws the following error:

Code: Select all

Move-VBRBackup : Cannot choose Job 'BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01' as a destination for the specified 
backups.

These are the two variables:

Code: Select all

PS C:\Users\Administrator> $vBackups

Job Name                  Type            Creation Time               VM count
--------                  ----            -------------               --------
BP2-BackupRepo1-01H001... VMware Backup   1/30/2025 11:28:3...               1

PS C:\Users\Administrator> $vTargetJob

Job Name                  Type            State      Last Result  Description                                                                                                    
--------                  ----            -----      -----------  -----------                                                                                                    
BP2-ECHD1S001R01-12H00... VMware Backup   Stopped    Success      BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01               

If I execute the move via GUI, it works without any problem and then I can move back and forward WClient3 between both Jobs via PowerShell.

What are the conditions or properties I need to look at for being able to move VMs between jobs with PowerShell? Or what else is being done by the GUI that PowerShell is not doing?

Best regards
Seve
EDIT: VBR 12.3.0.310. Originally v11, updated to 12.0, then 12.3. DB was SQL server, then migrated to PostgreSQL.

[david.domask]

Hi Seve CH,

I ended up working through this scenario myself quick as I've not tried automating this before, and a few notes I'd like to document publicly. Excuse the wall of text:

1. With Backup Jobs, the cmdlet is "full service", that is, it works as described. Moving a backup/VM between jobs is as simple as:

#Assume we want to move a VM named "test-vm"
$origJob = Get-VBRJob -Name "Original Job"
$origBackup = Get-VBRBackup -Name "Original Job"
$newJob = Get-VBRJob -Name "New Job"
Move-VBRBackup -Backup $origBackup -Job $newJob -Name "test-vm"

The VM will be added to the new job, and its backups associated with the new job as expected.

2. With Backup Copies, the process is much the same, but the outcome is a little different. Backup Copies don't allow you to add individual machines, they're job/repository driven for which workloads are processed. (Backups option refers to adding backups made by the Veeam Backup for Public Cloud (AWS, Azure, GCP) products)

So the Move-VBRBackup will indeed associate the backup with the new backup copy job using the same steps above, however, it will not add the workload to the Backup Copy job itself for processing.

This might be a bit confusing, but it may help to understand we track all workloads in the database with a specific UUID for each unique workload (read: VM, physical machine, etc). So for example if you have several backup jobs that include the same VM, the backups themselves will have different BackupIds, but the actual thing being backed up (BObject) will have its own UUID, which each backup will reference.

I explain this because to properly migrate from an old Backup Copy to a new one, you not only will need to use Move-VBRBackup to move the backups to the new Backup Copy, but you will also need to add some job or repository to the new Backup Copy as a source for it to continue processing (Set-VBRBackupCopyJob). In the Backups > Disk (Copy) section of the UI, you will see after running Move-VBRBackup that the backups are associated with the new job, but you won't see the job process anything until you add a source job/repository that also processes the same workload. Make sense?

So, as for your error:

Code: Select all

Move-VBRBackup : Cannot choose Job 'BP2-ECHD1S001R01-12H0015-31D3M-ECHD2-12M10Y-BC01' as a destination for the specified backups.

I checked on the back-end for this, it looks like main concerns are that we don't have same source/target repository for the Backup Copy and backups it processes. That is, if the source job targets repository A, it's required that the Backup Copy target _any_ repository besides repository A. There are a few other considerations on JobIDs but I don't think that's what you're hitting here personally. I reproduced your scenario (including periodic vs immediate) and was able to move the backups without issue, so I would start with double-check the source/target repository for the source job/backup copy respectively.