Linux repo accounts

[theviking84]

If I have a Linux Ubuntu 20.04 vm and it already has the perl and other requirements... when I first add it to veeam as a repository it will want to add it as a "managed server" first.

My question is, does the account I use need to have any permissions at all beyond ownership and rights on the folder I want to use for the backups?

I have seen conflicting info googling around. Some say it must be a member of sudoers file, some say only rights to the folder.

If it was a member of sudoers, wouldn't that mean it could do anything to the server? I want this to be more hardened. Also wondering what kind of changes will happen when immutable repo for Linux comes out.

[tsightler]

For current versions, when used as a repository, you do not need any permissions other than the ability to login and permissions on the folder. No sudo is required and has never been required. For use as a proxy, sudo is required (mounting/unmounting disks are elevated functions).

Hardened repository changes things a little bit. When adding a hardened repository you will need to enter a non-root account, but, to install the services, root is required temporarily. This can be dealt with two ways, you can temporarily give the user sudo (usually add them to a group) and then remove it after install, or you can provide the root password one-time, and it will use "su" to elevate.

Since hardened repos have no credentials saved on the Veeam server, during any upgrades you will have to either a) temporarily enable sudo again, or b) provide the root password again to elevate with su. From my perspective, the best option is to use su with a very strong root password, but if you use sudo, definitely remember to remove the account from sudo (either from sudoers file, or from the group) after the hardened repo is configured.

[theviking84]

Thank you. Great explanation!

One more quick question on the topic of Linux repo.

If this Linux repo is performance extent of a sobr and s3 bucket is capacity tier. When sobr offload happens, will it be able to start data mover on this repo and run data from it directly to s3? Or is some other server be required? Now but also going forward in v11 if the repo is going to be immutable.

It will not be a proxy. Only repo. As I understand in v11 immutable repo can not also be a proxy.

[tsightler]

It will be able to run directly on the server and send to S3 without any other servers, although you can also choose to use a gateway server if you prefer not to have the repos have direct access to the internet (this is configured when adding the object storage as a repo).

[theviking84]

Thank you. To make sure I understand it all... If I did use a separate gateway server, wouldn't this mean that all the backup files would have to travel across network to this second server, and then out to the internet? Like for example if you were going to use a gateway server, the only reason is "if the extent managed server can't get to the internet" correct?

I would worry of the scenario where lets say the veeam server is in datacenter a, and the repo/managed linux server is in datacenter b. If linux repo has no internet, then all the several TB of data has to travel over networking back to veeam server and then out to internet which is horribly inefficient.

So as long as my linux vm can reach s3 bucket it should be ok and know to use that route. Thank you!

[Gostev]

Your understanding is correct.

The reason for the gateway server functionality is that in some environments, only the specific servers are allowed to access the Internet. I would not say it is "horribly inefficient" though, considering that LAN is typically 10x faster than WAN anyway, so this extra hop on LAN will hardly have any impact.

[theviking84]

In my design, I have the veeam server in vmware cloud on aws environment. Then, the linux repo is an ec2 linux instance. So the veeam server has taken the backups and sent them as a proxy over to the ec2 vm.

To then have to come back across aws into vmware cloud and then out to the internet would not be ideal I'd think. So my setup is a little different than if two servers were on the same lan. But it is still pretty fast internal aws traffic overall as it comes across an so maybe not a huge deal.