File Copy of Configuration Backup not working on v12.1 with 4 eyes authorization

[bct44]

Hello,

Our file copy jobs for configuration backup files have been blocked since 12.1 and 4 eyes authorization enabled, is it an attended behaviour?
07053127

We need to have multiple copies offsite.

[bct44]

Additional informations:
source / dest are repos on linux repo
File to tape jobs from same source are working properly

[Gostev]

No, it looks like collateral damage @Dima P.

[Dima P.]

bct44 thank you for the feedback, we are investigating the issue!

[bct44]

Great! Thank you guys, support team asked for logs. Do you really need it to troubleshoot? I'm pretty sure you can easily reproduce the behaviour on lab.

[Dima P.]

Not needed, thank you! We've confirmed the behavior in our lab. Looks like the overwrite part of the file copy job was blocked due to four-eyes authorization being enabled and that's why the job is failing. I am still discussing the issue with RnD folks and will follow up shortly.

[bct44]

Can i expect a workaround coming soon or i need to find one to sleep better for christmas holidays ?

[Dima P.]

Hello bct44,

Looks like the issue is related to overwrite functionality of the file copy job (which is used to store place a new file version to the same location): four-eyes blocks the file overwrite when you are at the file node of the B&R console and it's also propagated to the file copy job.

Right now you can:

1. Disable the four-eyes to get the overwrite functionality back
2. As a workaround you can use NAS backup job to copy the needed files.

We are discussing further steps with RnD folks.

[bct44]

Hello Dima,

We're doing configuration backup on hardened linux nodes, are you sure it will works? Only necessary network ports are opened.
I'm considering a third scenario to send configuration backup to an object storage.

[Dima P.]

bct44,

The overwrite at file copy target. Is that also hardened Linux repository? Thanks!

[bct44]

Hello Dima,

Sorry for the delay,
source and target are HLR.

[Dima P.]

Hello Bertrand,

Fabian has shared this info with me last year, thank you

We will add a 'registry key' workaround to the upcoming patch, so stay tuned for updates! Thank you for the feedback and Happy New Year!

[bct44]

Thanks to Fabian, indeed i was on holidays far from pro laptop but still keeping an eye on the forum. Best wishes for the new year!

Can i expect a workaround before CP1 or i need to find a temporary one (object storage...)?

[Dima P.]

There is no workaround for now unfortunately. Four-eyes blocks the overwrite functionality in B&R completely, so the only way is to disable four-eyes if need to keep your file copy with overwrite running.

[bct44]

Hello, i will update to CP1 tomorrow and apply the regkey sent by the support. I hope this will fixe the bug.

[dali@iae.nl]

Or is this maybe also fixed in current 12.1.1.56 version?

[bct44]

It is fixed with CP1 but you need to apply a regkey, you could ask to the support.
@Dima: Do you mind if i share the regkey and the procedure here?

[cpw2024]

Hello. If you are willing to share the registry fix for this, please do. I am getting errors but do not want to fully disable four eyes.

Thank you.

[Dima P.]

Hello folks,

Sure, this key you need to the backup server to allow overwrite: FourEyesEnableCopyJobOverwrite

Thank you!

[cpw2024]

Would you have the full path of the regkey please?

[bct44]

FourEyesEnableCopyJobOverwrite
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Type: REG_DWORD
Default value: 0 => 1

[bct44]

Hello,

Am i the only one who don't have stats like throughput and the column data filled? Unless my memory fails me, it was available before v12.1.
Not mandatory like it's working not with the regkey but could useful

[Dima P.]

I'll pass a word to QA however this functionality was not somehow changed by four-eyes, so possibly a side related UI glitch. Thank you Bertrand!

[Dynamic]

FourEyesEnableCopyJobOverwrite
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Type: REG_DWORD
Default value: 0 => 1

works like a charm, thanks <3

[bct44]

A quick update @Dima, it was not an UI issue related. Path change for configuration backup on linux repos, well linux is case sensitive. The directory with the name of the vbr changed from uppercase to lowercase with V12.1.

[Dima P.]

Got it, glad you nailed it and thank you for sharing. Will let QA team know!