Testing the Linux agents - some issues

[JaySt]

Hi,

Together with a customer, i'm testing the Linux agent quite extensively. We're using the latest version of the agent supplied by 9.5 update4b installation of VBR. VBR server is running fine.

We came up with a list off questions/issues and i'd like to discuss some of them here and see if anyone has feedback/explanations or perhaps even fixes.

1.) we're also using a cloud connect partner for bringing backups offsite. We use encryption for the backupcopyjobs (from primary onpremise repo) to the provider. Using the CLI on the server with VAL, restores from the provider can be initiated if required. However, when encryption is used, the CLI does not accept encryption passwords. Is this correct? we have to set it first using the veeamconfig TUI it seems.

2.) installing the VAL accepts a username used for running the software. The installer puts "ALL:ALL" as permissions in the sudoers file for that account. Removing the software does not revert that change. Is this as designed?

3.) Installing the VAL on a RHEL host with LVM, we can see a device mapping being created as a 100GB "backup" device . I cannot explain that. Where does this come from? it's a dm-# device visible in the lvm config.

[PTide]

Hi,

1) Which mode do yo use (managed by VBR, managed by agent, or standalone)? Also what kind of restore are you trying to perform (file-level or volume level)?

2) No, that is not by design. Please contact support directly so they can grab logs. After that, please post your case ID here.

3) Which RHEL is that, 7 or 8? Do you see that device during installation, or during backup sessions?

Thanks!

[JaySt]

1.) mode used is "managed by agent". Restore will be file-level in most cases.
2.) to be clear: your saying that the fact that VAL uninstall process does not revert the sudoers change is not by design, right?
3.) RHEL 7. the device is visible after installation.

[JaySt]

regarding the cli-restore:
when we use the command:
veeamconfig backup mount --id <id of backup> --mountdir /mnt/veeam_restore/
the command fails. It only works when we set the encryption password first using the TUI.
There seems to be no option to set the password using cli.

[PTide]

2.) to be clear: your saying that the fact that VAL uninstall process does not revert the sudoers change is not by design, right?

Right. The described behaviour is not exactly how we wanted the product to behave.

3.) This one also should be addressed by support team, it's hard to troubleshoot such issues via forum.

Regarding Restores from cloud copies:

I need to clarify something with the team, but first please tell me - did you specify the same encryption pass that you had in BCJ? If so, then what happens if you try to set another password? Have you tried to run veeamconfig cloud resync? I have some suspicions that it must have something to do with the way CC stores encryption keys.

Thanks!

[JaySt]

i'll see what i can do together with support on points 2 and 3.

starting restores from data out of the BCJ with cli on the agent itself did not work due to missing encryption key in the first place. We had to set it to the same key as used in the copy job. When this was set, restores were OK. It seems logical you have to set the key during restores on the agent itself, as the agent itself has never seen/used the key. It's only used on the BCJ. It's more about the ability to set a key on the agent used for restores of data from the BCJ generated cloud copy. i can only set the key by using the TUI it seems.