Unable to set up Debian-based server with BnR

[thenewguy]

Case #04635456

I am trying to set up a backup of a Debian-based OpenMediaVault server. Two of them, actually. They running on two Windows Server 2019 Hyper-V.

Method 1. I tried setting it up from the BnR server side, but I would get.
2021-02-09 08:56:14 :: Unable to install backup agent: cannot connect to awesomeserver Error: Failed to get path for 'veeaminstaller' utility for OS platform 'Unknown'

Method 2. Then I tried to set it up from the Linux side with the agent, but the destination page of the job, when I select BnR and proceed to log in, it would get stuck with an "info" dialog that says "please wait". I can Ctrl-c out of it and start over.

Method 2.1 I also tried backing up to a local folder using the agent, but then it immediately fails to create a snapshot.

The same VM worked perfectly with VM backup job before I added pass-through disks to it.

I tried the 1st method with another OpenMediaVault server on another machine, but result is the same:
2021-02-09 11:50:00 :: Unable to install backup agent: cannot connect to anotherawesomeserver Error: Failed to get path for 'veeaminstaller' utility for OS platform 'Unknown'

Both VMs have a virtual disk with ext4 for boot and btrfs raid1 with multiple passed-through disks for data. The change is the passed-through disks.

I tried removing the disks, but method 1 still fails.

What am I doing wrong?

[thenewguy]

Did some more testing. If I switch to file level backup without snapshot, local agent can to a backup to a local target. File level with snapshot, the snapshot fails.

[thenewguy]

More testing. I am not sure why I could not connect to the BnR server when I tried the default port, so I tried 9392 and that caused it to get stuck with "please wait". Not I tried again with default 10006 and it works. The job it running, it appears on BnR console and job log.

[PTide]

Hi,

OVM is not officially supported, and we've seen folks having problems with VAL installed on OVM. Please check this thread.

Thanks!

[thenewguy]

Thanks, I will check it out. Any idea what the

Code: Select all

... Failed to get path for 'veeaminstaller' utility for OS platform 'Unknown'

could mean? I did some searching but could not find anything useful.

[PTide]

Most likely it means that /etc/os-release file on your machine does not contain enough info for BnR to decide on how to proceed. Would you post the contect of it, please? Example:

Code: Select all

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Thanks!

[thenewguy]

Code: Select all

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[thenewguy]

Is there anything in os-release that explains the behavior?

[PTide]

Well, the os-release content looks valid. It seems that VBR cannot even reach /etc/os-release for some reason:

Code: Select all

2021-02-09 11:50:00 :: Unable to install backup agent: cannot connect to anotherawesomeserver 

It might be either a ssh connectivity issue, or authentication, for example.

If the agent is installed manually, it should be possible to point VBR server to it (once it discovers the agent it won't attempt to install it again). Please keep in mind that even in this case OVM is not a supported, so use it on your own risk.

Thanks!

[thenewguy]

Digging in /var/log/auth.log I see two commands coming from the server:

Code: Select all

whoami
mkdir -p /opt/veeam

I'm hopeless when it comes to this level of Linux complexity. Looks like I will have to let go OMV and get my shares some other way. Some supported way, this time.

[PTide]

Did it succeed? I mean, is /opt/veeam there?

As for shares - if you would like to back up fileshares, you might want to check our NAS backup.

Thanks!

[thenewguy]

It succeeds, the folder appears after attempting to scan the server.
Found a solution:

Code: Select all

sudo mkhomedir_helper username

I have seen this in multiple issues, but didn't think of trying it before now. Seems that sometimes the homedir is not created for the user (random example here that got my attention) and that causes all kinds of issues.

This fixed the problem on OVM 4 and OMV 5 running Debian x64 4.19.0.0 and Debian x64 5.7.0.0 respectively. Also fixed the issue in the random example that I also had. Magic.

Thank you for your kind support, PTide.
I hope this helps anyone stumbling on this issue in the future.