VAL on Arch Linux - does it work?

[DanH]

Hello Everyone,
Has anyone been able to get this working on Arch Linux?
From searching, it looks like a script debtap can be used to convert a .deb package to Arch Linux package.
Max

[PTide]

Hi,

Please check this. Please keep in mind that Arch is not a supported OS, although agent should work fine with it.

Thanks

[DanH]

It's working! Verified on Manjaro Linux 4.4.39-1
Thank you PTide!!!

[Mike Resseler]

Hi Maximus,

For other visitors on this forum. Did you used the link that PTide gave you to make it work? Did you also do a restore as a test? I'm sure many others would like to have this information

Thanks
Mike

[DanH]

Yes, follow instructions from PTide's link. Once installed, I did a full system backup and then a couple of hours later a full system restore. It worked flawlessly!!! I'm using an NAS with NFS to store my backups. I actually had to do the restore because I manually upgraded to latest available kernel (4.9) and could not log back in.

On my system, I had to install kernel headers and an older kernel in order to build the veeam agent. Here's the commands I used:

Install headers for my current kernel (4.4.39-1-MANJARO)

Code: Select all

sudo pacman -S linux44-headers

Install older kernel required by veeam agent

Code: Select all

sudo mhwd-kernel -l linux310

Follow PTide's link to install the agent: https://github.com/CodeImp/arch_packages

[TParticke]

Its working with 4.14.87-1-Manjaro
thanks for the info.

[diedmatrix]

Hi Veeam Team!

I am using Veeam since years now (Enterprise and on my private Computers) and just love the reliability and ease of use of it, which is critical for a backup solution in my opinion!

With the end of Win7 support, i am switching to linux, which would be Manjaro (ARCH) for the moment - and I (and I think many others!) would so love to see official support from veeam!

So can you give us some feedback af this might be on your roadmap or what is missing for that?

[PTide]

Hi @diedmatrix,

The next version of VAL (soon to be released) will support the latest possible kernel version (likely 5.4.0).

However, since VAL utilizes 'veeamsnap' kernel module (required to make snapshots) which needs to be updated almost every kernel update (in case of distros that do not provide stable kABI), it is quite challenging to keep up with the pace at which distros like Arch evolve.

There are basically two options to make it possible for us to support distros like Arch:

Option-A) We release a separate version of veeam agent that does not require veeamsnap kernel module to be installed

In this case it will be limited in its capabilities to file-level backup without snapshot. That is, backups will be crash-consistent which is probably not a big deal for tech-savvy users since many popular backup solutions (e.g. rsync, borg, urbackup, and others) do not offer snapshots at all. However, you can always take an advantage of pre/post-job script usage in order to trigger, for example, LVM snapshot.

Option-B) We put way more resources into developing and testing of the kernel module, and in this case we will need every single helping hand available including OSS community as they develop and change kernel somewhat faster than we adapt our module. You might also want to check experimental version for Arch here

Thanks!

[diedmatrix]

Hey, thanks for your quick and nice explanation

i am not very familar with linux, but how about making the veeamsnap module optional (with prompting about the pros and cons) when installing? Do you really have to do a seperate version?

Would veeamsnap also be required when using snaps via btrfs or zfs? Wouldnt this be an option, or is this the same?

Its really a chicken egg problem for me (and potential the rest). I would really like to switch to linux (and i think 99% of the users would) if you would not have to read 100 wikis, run commands via the commandline and so on to get everything you are used to get to run - if at all! But sure, what to expect if the market of desktops is to 99% in hold of MS - like i said, chicken egg problem >-<

I am aware of the veeamsnap module in the AUR - but the AUR should only be used if you have a clue what you are doing, which i dont and i dont think any other NORMAL user is.
I want to be able to rely on a backup to 100% and not on something a 3rd user build on his own and then suddenly AFTER a disaster i will notice that backups were corrupt or anything else because of a bug or error which i did not get informed of.

Maybe i have to stay in Windows 10 then and swollow the pill of MS and all his Sh### - really sad

[PTide]

Do you really have to do a separate version? how about making the veeamsnap module optional (with prompting about the pros and cons) when installing?

Most package managers (yum, apt, zypper) do not offer such feature as "promt to install optional packages". That is, we will have to prompt users on the first start of the program. That might be a good idea, however there are some pitfalls in mass-deployment scenarios when people simply don't actually configure things manually and will be simply unaware of the possibilities. Another option would be to create a separate "installer" package that can be started instead of a package manager to handle the installation, but that won't really eliminate the problem with mass deploy and will be in fact just a "discount-version" of a conventional package manager suited specifically for one piece of software.

Would veeamsnap also be required when using snaps via btrfs or zfs? Wouldnt this be an option, or is this the same?

No, it is not really required for those filesystems and it is totally possible to go with snapshot-less backup and use pre/post-job script to trigger a ZFS/BTRFS or an LVM snapshot (as I have mentioned in my previous post). Technically we can integrate snapshot-less version of the agent with native ZFS/BTRFS snapshots, it's just not being requested much so far.

On the bright side of things, Manjaro doesn't seem to update its kernel as often as Arch, hence supporting Manjaro in future doesn't sound fantastic to me.

Thanks!

[AveryFreeman]

Dear OP, if the source code is available for the kernel modules, why not try and make a dkms package for arch Linux?