V12 Move Backup To new Repo is resending all data to backup copy job

[galbitz]

Hi, Case # 05901565

We just upgraded to veeam 12. The actual upgrade went fine. Jobs appear to run as expected.

We tried using the new move function to move a backup jobs repo (just the job, not the backup copy job). We are moving from 1 immutable xfs repo to another. The move itself went without a hitch, the old backups were not deleted due to being immutable but they were flagged as such and we can address that.

What we didn't expect, and is concerning us, is that it immediately triggered the Backup copy job to run. It appears to be running a job one after another for every restore point we have. This was not expected, at least not from our perspective. The whole point of moving the backup with the new functionality was to try and ensure we didn't need to reseed the remote side containing the backup copy job.

Is this expected? We did run the upgrade backup chain on the copy job earlier today, that completed in about a minute or so. Perhaps the combination of these 2 functions was a problem. My next step on the new repo was to disconnect the files from the job so that we could do a new active full and switch to the new per VM backup disk chains. To be clear we have not performed that step, that is just the direction we were heading. I was concerned that might cause a full backup copy job to reseed the data, I wasn't expecting it to happen immediately after the initial backup job move.

I should mention the new repo we moved to is set to per VM files and the old one was set to per backup files if that makes a difference. Our jobs are 1 VM per job. I have only moved one backup job as a test but it has spent the last hour or so going through the restore points, throwing rpo violations for restore points that are 86 days old etc.

[galbitz]

So just to restate this a little simpler:

Attempting to move a backup job from one repo to another. The job contains just 1 vm. There is an associated backup copy job for that one vm, its an immediate job.

repo 1: current xfs immutable (was set to single mode backup file) we have since changed this to per vm but fulls have not been run on anything other than a test.
repo 2: new xfs immutable (set to per vm backup files)

move completes successfully, but the associated backup copy job is resending the entire backup chain one after another for the past few hours. the remote repo where the backup copy job is targeting is also xfs immutable.


We need help validating the approach, the primary goal is the backup copy job shouldn't think all files need to be resent. we cannot reseed all backup copy jobs over the wan. (its a couple hundred tb).

[Gostev]

Hello, I would do the same. Please investigate with Support why the new backup copy job is sending fulls despite being mapped into valid existing backups (assuming you did map it). Thanks!

[galbitz]

gostev, i did not remap anything. perhaps that is the issue but I don't see a case where mapping would be necessary.

if I select any backup job (remember our backup jobs are single vms but currently the backup chain is a single image format) and I choose edit the job and choose the new repo I then am prompted to move the data. It disabled the backup job and the backup copy job briefly and the move indicates its remapped both jobs. Post move a backup copy job is immediately triggered and all data is duplicated. Though I will say its not 1:1 duplicated. example below, but I don't see why or when I would need to remap the copy job:

you can see all the files with yesterdays date are the ones it recopied. we are doing grt and every repo involved is xfs immutable.

Code: Select all

-rw-r--r-- 1 fakeaccount fakeaccount      217027 Feb 28 05:44 fakevm_3C789.vbm
-rw-r--r-- 1 fakeaccount fakeaccount 15691726848 Dec  4 23:16 fakevm.vm-24671D2022-12-04T181556_802A.vbk
-rw-r--r-- 1 fakeaccount fakeaccount 16404508672 Jan  1 23:14 fakevm.vm-24671D2023-01-01T181424_AC21.vbk
-rw-r--r-- 1 fakeaccount fakeaccount 15264645120 Feb  6 23:13 fakevm.vm-24671D2023-02-06T181347_EA00.vbk
-rw-r--r-- 1 fakeaccount fakeaccount 15878631424 Feb 12 23:14 fakevm.vm-24671D2023-02-12T181401_6D2D.vbk
-rw-r--r-- 1 fakeaccount fakeaccount 16123260928 Feb 20 23:16 fakevm.vm-24671D2023-02-20T181614_458C.vbk
-rw-r--r-- 1 fakeaccount fakeaccount 16542511104 Feb 26 23:21 fakevm.vm-24671D2023-02-26T182056_7832.vbk
-rw-r--r-- 1 fakeaccount fakeaccount  4085116928 Feb 27 21:44 fakevm.vm-24671D2023-02-27T163929_F532.vib
-rw-r--r-- 1 fakeaccount fakeaccount  1686511616 Feb 27 23:15 fakevm.vm-24671D2023-02-27T180517_F70E.vib
-rw-r--r-- 1 fakeaccount fakeaccount  6721568768 Feb 28 00:59 fakevm.vm-24671D2023-02-27T194939_A256.vib
-rw-r--r-- 1 fakeaccount fakeaccount  5244276736 Feb 28 01:09 fakevm.vm-24671D2023-02-27T200040_DAFE.vib
-rw-r--r-- 1 fakeaccount fakeaccount  4770930688 Feb 28 01:40 fakevm.vm-24671D2023-02-27T201143_A9D8.vib
-rw-r--r-- 1 fakeaccount fakeaccount  5816414208 Feb 28 01:57 fakevm.vm-24671D2023-02-27T204307_B3C9.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3018620928 Feb 28 02:05 fakevm.vm-24671D2023-02-27T205914_EC2F.vib
-rw-r--r-- 1 fakeaccount fakeaccount  5601484800 Feb 28 02:22 fakevm.vm-24671D2023-02-27T210709_7962.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3216949248 Feb 28 03:33 fakevm.vm-24671D2023-02-27T212413_40B4.vib
-rw-r--r-- 1 fakeaccount fakeaccount  5995728896 Feb 28 03:57 fakevm.vm-24671D2023-02-27T223334_F1D1.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3313299456 Feb 28 04:14 fakevm.vm-24671D2023-02-27T225852_2291.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3380719616 Feb 28 04:19 fakevm.vm-24671D2023-02-27T231550_9B60.vib
-rw-r--r-- 1 fakeaccount fakeaccount  4301189120 Feb 28 04:28 fakevm.vm-24671D2023-02-27T232057_8AD2.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3302871040 Feb 28 04:36 fakevm.vm-24671D2023-02-27T232959_7C1D.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3214413824 Feb 28 04:44 fakevm.vm-24671D2023-02-27T233754_1090.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3940659200 Feb 28 04:52 fakevm.vm-24671D2023-02-27T234609_8118.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3426050048 Feb 28 04:59 fakevm.vm-24671D2023-02-27T235402_4CE0.vib
-rw-r--r-- 1 fakeaccount fakeaccount  3655122944 Feb 28 05:09 fakevm.vm-24671D2023-02-28T000107_73E4.vib
-rw-r--r-- 1 fakeaccount fakeaccount  5050695680 Feb 28 05:23 fakevm.vm-24671D2023-02-28T001124_00C6.vib
-rw-r--r-- 1 fakeaccount fakeaccount  4085116928 Feb 28 05:35 fakevm.vm-24671D2023-02-28T002513_71AC.vib
-rw-r--r-- 1 fakeaccount fakeaccount  1686511616 Feb 28 05:43 fakevm.vm-24671D2023-02-28T003731_F866.vib

I am starting to wonder if its related to retention settings. the backup copy jobs are set to keep 7 retention points and then 4 weekly and 3 monthly. the source is 7 days instead of retention points, and then 4 weekly and 3 monthly. the source is also doing a synthetic full on saturdays.

[Gostev]

By mapping I meant this:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[galbitz]

Gostev, does moving the primary backup repo require I remap the backup copy job (we are changing the target repo for the normal backup, not the copy job's)? the old target and the new target arent changing for the copy job since I am not changing the target location, I am impacting the source repo but you don't actually pick the source. Also, the backup copy job is firing off immediately after I do the move, I don't seemingly have the ability to remap it before it starts.