Best way to handle a external usb hdisk repository

[max.fontana]

Hello this is Max from Italy.
Ive been using Veeam b&r 10 with two repository:
The first one is local storage of the physical server where veeam is installed. The second one is a linux nas repository populated via a backup copy job. I have a bunch of vm's that are backed up daily at night using the reverse incremental technique. I'm now testing a third repository which is an external usb disk connected directly to the veeam server. My goal is to get a third backup copy on this device updated weekly on Friday (I know it does not sound that great but we cannot afford a cloud backup and I'd like to have an air gap copy in case of disaster even though not updated).
I tried to create a new backup (using a production vm with a 1,8 TB vdisk) job specyfing the external usb as backup repository and it worked creating a full backup but somehow this job influenced the other reverse incremental job which runs daily. In fact it took nearly 4 hours to complete when usually the needed time is between 4 and 6 minutes. The transfeered amount of data was not that big (2-4 GB as usual ) but data read was nearly 1,8 TB . Usually data read is not bigger than 5-6 GB.....
Should I instead use a backup copy job to populate my usb hdisk or even better use an external third part software with delta copy features?
I opened a support case number 04415306.
thanks in advance and best regards.
Max

[foggy]

Hi Massimiliano, indeed, you'd better use a backup copy job for this scenario, to avoid touching production VMs twice. But that said, the second backup job shouldn't affect the first one in any way, so what you're seeing is not expected - chances are caused by some external reasons (looks like CBT issue). Thanks for opening a case to investigate.

[max.fontana]

Hi and thanks for your answer. I got a reply from support and here is what they said: " According to the VMware recommendations and to avoid CBT data corruption we have recently enabled CBT reset on each active full run. This means that when the second job did its initial run the CBT was reset which led to big read for the main job too. So your initial assumption was correct. It is because of the second job. It is currently expected behavior."
I'll then go with the backup copy option.
thanks again.
Regards,
Max

[foggy]

Ah, right, this was introduced as a workaround to CBT issues (caused by vSphere API bug) on earlier ESXi versions that didn't receive corresponding patches from VMware (ESXi 5.5). You can disable automatic CBT reset during active fulls in the job settings.

[max.fontana]

Yes but as you correctly pointed out, better not to stress the production vm's with a double backup job.

[foggy]

Right, that would be a recommended approach.