NFS Backup Repository

[krullje04]

Before my Linux admin will let me use her NFS storage as a backup repository I need to explain to her what Veeam does and wants to see. Why does it need to be root? What does it install if anything. If someone could point me to the right documentation or explain it that would be great.

Thanks,

Jason

[Vitaliy S.]

Jason, please review our sticky F.A.Q. and Veeam B&R User Guide (starting from page 80) for more information about backup repositories. Thanks!

[krullje04]

Thank you for pointing me to the FAQ and the User guide. I re-read over those and still have questions. Unless I missed something it doesn't explain why you need to log in as root or an sudo user. Will veeam try to install something on the NFS server? It mentions the need for perl, but doesn't say what for.

Thanks

[Sethbartlett]

I believe the agents/services we run require elevated permissions, which would be why we need root password. So we will SSH over the normal communication and then sudo to run the agent.

[tsightler]

So there seems to be some confusion in this thread. Using a Linux system as a repository, and using an NFS server is not really the same thing. NFS is a file sharing technology similar to CIFS, used primarily by Unix and Linux systems. It is technically possible for Windows to access an NFS fileshare directly via the "Client for NFS" feature for Windows 2008/2008R2. You cannot install Client for NFS and Veeam PowerNFS service on the same server, however, with V6 you can install Client for NFS on a different server from the main Veeam server, mount the NFS share, and add that Windows system as a repository.

On the other hand, Veeam can also use pretty much any Linux system as a repository. When using a Linux system as a repository you can write the backups to any Linux mount point, which includes local disks on the Linux system, or NFS shares mounted on the Linux system. When we use a Linux system as a repository we do use a run-time agent on the system during the backups. We leverage and SSH login to the system and execute this small agent while the backup is running. This agent reads the backup stream and performs all of the I/O local to the Linux system. This small agent has a dependency on perl simply because there is a small, perl based wrapper script that executes the agent.

The agent does not require root access, you can choose to use root, but I wouldn't suggest this. As long as the user account that is provided can login via SSH, execute a small perl script and binary agent, and has read/write permissions to the selected path to store the backups, that is all that is required.

[krullje04]

Thank you for the information. I will pass it along to our Linux admin.

[krullje04]

Ok, now our Linux admin is asking how the agent get's installed. Could someone please explain that part to me?

[foggy]

This happens automatically in the run-time, so don't worry about that. The agent is installed via SSH. It is very small, auto-deployed as needed and auto-removed immediately after data transfer process finishes.

[rawtaz]

We leverage and SSH login to the system and execute this small agent while the backup is running. This agent reads the backup stream and performs all of the I/O local to the Linux system. This small agent has a dependency on perl simply because there is a small, perl based wrapper script that executes the agent.

The agent does not require root access, you can choose to use root, but I wouldn't suggest this. As long as the user account that is provided can login via SSH, execute a small perl script and binary agent, and has read/write permissions to the selected path to store the backups, that is all that is required.

Hi Tom!

Can you or someone else please answer the following questions?

- If the agent doesn't need root privileges (like you say), then why all the talk about root and sudo (if not supplying root credentials) on page 72 in the user guide (under the heading "Step 3. Specify Credentials and SSH port" in the chapter about adding a Linux server)? This sure seems to indicate that we need to supply either root credentials, or credentials for a user that must have sudo access to elevate to root privs.

- I am also concerned about the field "Root password" under the "Non-root account" part of "SSH Connection" in the "New Linux Server" dialog. What I want to know is first of all; Is this password saved? It seems like it, based on the default text in the field ("To change the saved password, click here"). If it is saved, why? As I understand it this would be used to set up the sudoers file so that a non-root user can elevate privileges, which seems to be something that should only need to be done once (presumably when adding the server), hence not saving the root password here.

I simply don't fancy saving the root password of my Linux backup repositories on the Veeam controller. Nor do i fancy the thought of running the agent with high privileges, just like the OP probably doesn't.

If the case is that Veeam installs the agent and then removes it every time a backup is run, what is the rationale behind that instead of installing it once and for all so that we don't need to keep privileged credentials around?

Thanks a lot, hoping to have this cleared up!

[Vitaliy S.]

Hi Leo,

What I want to know is first of all; Is this password saved? It seems like it, based on the default text in the field ("To change the saved password, click here"). If it is saved, why?

Yes, it is saved, because these credentials are used every time the backup/replication job runs.

If the case is that Veeam installs the agent and then removes it every time a backup is run, what is the rationale behind that instead of installing it once and for all so that we don't need to keep privileged credentials around?

Every job requires its own agent and the number of active agents depends on the number of backup jobs targeted to this Linux repository, meaning that you cannot really predict how many agents you need to deploy to this box.

Hope this helps!

[rawtaz]

Yes, it is saved, because these credentials are used every time the backup/replication job runs.

Are you referring to the regular user's password, or the password under the "Elevate specified account to root"? The latter is what I was curious about, as I imagined that the "Add account to the sudoers file automatically" would only happen once/the first time Veeam connects. If so, I would assume that this root password wouldn't need to be saved for more than one use. But maybe the situation is that the user is added (and removed) to(/from) the sudoers file once every time Veeam connects to login with this user? If so, Veeam needs to use the root password every time of course, given that design.

Every job requires its own agent and the number of active agents depends on the number of backup jobs targeted to this Linux repository, meaning that you cannot really predict how many agents you need to deploy to this box.

Hope this helps!

I think it did, especially the latter part clarfied the agent stuff, makes sense. I also noticed that if all you're using the/a server for is to act as a backup repository, you need only provide the regular user credentials, you don't need to supply the root password to have it added to the sudoers file and stuff. That is good.

[Vitaliy S.]

But maybe the situation is that the user is added (and removed) to(/from) the sudoers file once every time Veeam connects to login with this user? If so, Veeam needs to use the root password every time of course, given that design.

The user is added and removed every time when the corresponding access is required, that is why this password is also stored in the database. If you want to avoid that, you can manually add your user to sudoers group.

[rawtaz]

Agree. Ok, thanks!

[tsightler]

Sorry, I didn't see this thread earlier. You do not have to enter anything in the "elevate to root" option and users do not need to be in sudoers either. That option is there for clients that do not allow direct root login via SSH (generally a default security option) but rather require elevation to root.

However, our target Linux agent has no specific requirements for root. Many customers seem to choose to use root simply because they have limited understanding of how Linux permissions work, however, any regular user can be used for our agent and you can simply leave the "elevate to root" options unselected. I use this exact configuration at home, and at many of the largest customers that I work with. As long as the account has permissions to SSH, execute programs (admittedly from /tmp, which may require root based on the security settings of the host), and write to the required directory, it will work fine.