Warnings when backing up Linux VMs

[pshute]

Our Windows servers are backing up ok, but each Linux machine gets this warning: "Unable to perform guest file system indexing: Guest credentials for the VM are not specified."

Can someone please explain the implications of this? Does it just mean restoring a single file is more difficult?

I tried to enter credentials, but the test is failing. I created a user called veeamuser on one Linux machine, and added it to the root group, then I set that user as the credentials for just that machine.

Now when I run the test, that machine fails with "Guest OS account has no root privileges". What have I done wrong? This is how I created the user:

Code: Select all

sudo adduser veeamuser
sudo usermod -aG root veeamuser

I don't know that much about Linux. Am I approaching this the right way?

[Mike Resseler]

Hi Peter,

Did you look at this page: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

Thanks
Mike

[pshute]

Yes. I assume my problem is with creating the user, and that it's Linux help I need, not Veeam help.

[Mike Resseler]

Hi Peter,

Have a look at this post: vmware-vsphere-f24/failed-to-run-comman ... ml#p144297 whether it can help you. @veenski has described it step by step

Hope it helps
Mike

[PTide]

Hi,

The implication is that it won't be possible to browse backups for FLR via Enterprise Manager without mounting the backup in console.
Regarding sudo problem - if you have Red Hat system then you can do the following:

Code: Select all

usermod -aG wheel username

[pshute]

Hi Peter,

Have a look at this post: vmware-vsphere-f24/failed-to-run-comman ... ml#p144297 whether it can help you. @veenski has described it step by step

Hope it helps
Mike

Thanks, I did miss the big pink warning box about adding NOPASSWD:ALL to the sudoers file at https://helpcenter.veeam.com/docs/backu ... tml?ver=95.

I've edited sudoers so now it looks like this:

Code: Select all

veeamuser ALL=(ALL) NOPASSWD: ALL
veeamuser ALL=(root) NOPASSWD: /bin/uname
veeamuser ALL=(root) NOPASSWD: /usr/bin/scp
veeamuser ALL=(root) NOPASSWD: /bin/arch
veeamuser ALL=(root) NOPASSWD: /bin/mount
veeamuser ALL=(root) NOPASSWD: /usr/bin/sh
veeamuser ALL=(root) NOPASSWD: /bin/rm
veeamuser ALL=(root) NOPASSWD: /tmp/*

But I'm still getting the error about the user not having root access. The system is Ubuntu 12.04.2.

[pshute]

Hi,

The implication is that it won't be possible to browse backups for FLR via Enterprise Manager without mounting the backup in console.

Thanks, that's what I was hoping.

Regarding sudo problem - if you have Red Hat system then you can do the following:

Code: Select all

usermod -aG wheel username

It's Ubuntu 12.04.2. Tried it anyway, group wheel does not exist.

[Mike Resseler]

Can you try to removal all those lines that you added in the sudoers besides veeamuser ALL=(ALL) NOPASSWD: ALL as a test?

[pshute]

Can you try to removal all those lines that you added in the sudoers besides veeamuser ALL=(ALL) NOPASSWD: ALL as a test?

I already tried that. I tried adding those lines because it didn't work.

[pshute]

Can you try to removal all those lines that you added in the sudoers besides veeamuser ALL=(ALL) NOPASSWD: ALL as a test?

And I removed them anyway to double check, but it's still failing the credentials test.

Can anyone suggest some diagnostics I can run on the Linux box to confirm it's set up correctly?

[nitramd]

Can you confirm what group the identity "veeamuser" is in? Change to the /etc directory then type "groups veeamuser".

The syntax to add a user to a group is: sudo usermod -a -G groupName userName so in your case it would look something like this: sudo usermod -a -G root veeamuser ; then run the groups command to verify that veeamuser is in the group "root"

I don't have a Linux box handy to check so I'm flying a little blind here.

-md

[sg_sc]

You should not need to make the user member of the root group or give it userid 0 if you plan to use sudo.

[pshute]

Can you confirm what group the identity "veeamuser" is in? Change to the /etc directory then type "groups veeamuser".

That command returns this:
veeamuser : veeamuser root sudo

[pshute]

You should not need to make the user member of the root group or give it userid 0 if you plan to use sudo.

Do you mean by ticking the "Elevate specified account to root" tick box? I would still need to enter the credentials of a root user. I decided it might be best to avoid that, as other IT staff "own" that box, and are likely to change the password without warning.

I did try ticking the box, still got the warning about root privileges.

[nd39475]

in short this worked for us: (note the !requiretty) (found solution in forum somewhere)

useradd veeamuser
passwd veeamuser

visudo (if you don't like vi, you can use "EDITOR=nano visudo" [assuming nano is installed, it's an easier text editor])
add

Code: Select all

Defaults:veeamuser !requiretty

below the existing "Defaults requiretty"

also add

Code: Select all

veeamuser   ALL = NOPASSWD: ALL

below the existing "root ALL=(ALL) ALL"

Your /etc/ssh/sshd_config probably isn't blocking users, but research to make sure (& restart sshd if modified).
Don't forget to install mlocate (specifically required for file indexing).

In Veeam, we do "Elevate specified account to root".

[pshute]

Still not working. I can certainly ssh to the command prompt on this machine as this user. However once logged in, if I type visudo, it says "Permission denied", and if I type sudo visudo, it prompts for the password. Is that an indication that I still don't have things set up properly?

[sg_sc]

Yes!

[pshute]

That's good because it means there's a reason why it's not working. But it's bad because I thought I'd followed the instructions to set that account up, so I don't know how to fix it. Can anyone suggest a way to diagnose where I've gone wrong?

[veremin]

May be it's time you open a ticket with our support team and let our engineer assist you with troubleshooting process.

[pshute]

May be it's time you open a ticket with our support team and let our engineer assist you with troubleshooting process.

OK, I'll do that. I assumed it was purely a Linux competence problem, and not their responsibility.

[pshute]

I called tech support today, and was told I'm wasting my time doing indexing anyway. He said indexing is only useful if you're using Enterprise Manager. I don't believe we have Enterprise Manager. We only have one backup server.

It would be nice to know why I couldn't get it it to work with the user account I created, but I'm going to abandon it and just untick the option.

The option says:
"Creates catalog of guest files to enable browsing, searching and 1-click restores of individual files.
Indexing is optional, and is not required to perform instant file level recoveries."

Somewhere along the line I read that and made the assumption that I needed it. Probably because I was new to VBR, and didn't know what an "instant file level recovery" or a "1-click restore" was. I assumed I would need to browse and click to restore individual files, so therefore I would need a catalog. I ticked it, set the credentials for a Windows machine, did a test backup, then successfully tested restoring one file, so assumed I'd done the right thing. Then later I added Linux machines to the backup, and started seeing errors about indexing. When I tried to test FLR on a Linux backup, it asked awkward questions about nodes, etc, so I assumed it was falling back to some other method of accessing the file system.

Can I suggest that this be reworded to make this all clearer? Perhaps mention Enterprise Manager in the option description.

Finally, do I now have catalogs on my Windows servers taking up space unnecessarily? If so, what can I do about them?

[pshute]

Finally, do I now have catalogs on my Windows servers taking up space unnecessarily? If so, what can I do about them?

On Friday when I posted that, I had about 800MB of files in C:\VBRCatalog\Index\Machines. Today there's only 300MB, and most of the machine folders disappeared some time late Sunday. So it looks like VBR does clean up the catalogs itself, but not immediately. Those that are left are very old, so I think they're from old test jobs that still have the indexing option enabled.

[pshute]

Those that are left are very old, so I think they're from old test jobs that still have the indexing option enabled.

I can't find matching jobs for these catalog files, so I think they may be orphaned. Only about 300MB on a server with 130Gb free, so not a problem at this stage.

[sg_sc]

For a Linux FLR, Veeam B&R will ask you some questions the first time. Veeam B&R will ask you were it can deploy a small VM called a Linux FLR helper VM or something like that. This VM will boot up in under a minute, will attach the backup and read its filesystem, after which you will get the familiar FLR restore window. I think this is because Windows can't read the Linux filesystem inside the backup files.