Stuff about backups
Veeam Agent for Linux User Guide
Veeam Agent for Linux 6.0 Release Notes
1 Updates[edit | edit source]
1.1 2/16/2023[edit | edit source]
Veeam version 12 was released 2/14 and Veeam Agent for Linux v6 along with it. This version was supposed to address the snapshot kernel mod problem and allow us all to advance to the newer version of RHEL compatible kernels. Unfortunately, once the auto-upgrade was applied, backups failed. LSS, the Veeam backup was refusing to load the snapshot module at the start of the backup when executing the python script /usr/sbin/veeamsnap-loader . It turns out that this scrpt is very picky about the data it pulls up from /etc/os-release
NAME="Rocky Linux"
VERSION="8.7 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.7 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
ROCKY_SUPPORT_PRODUCT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"
The problem python code is in two places:
def dist_os_release():
d = {}
with open("/etc/os-release") as file:
for line in file:
stripped = line.rstrip()
if stripped:
key, val = stripped.split("=")
d[key] = val
return d["ID"].strip("\""), d["VERSION_ID"].strip("\"")
and one of the sections that uses this information in the main module:
if not distName in ["oracle", "ol", "redhat", "rhel", "centos"]:
raise RuntimeError("Found unsupported distribution [{0}]".format(distName) )
One way to hack around this is to add to the list on the distName check to allow "rocky". However, you'd have to add "alma" and others if you wanted to go down this path. Arguably a better option would be to use the ID_LIKE value, which identifies the release family, instead. That way, no explicit coding for specific distros in this family need be maintained. That said, whether this is a bug or a feature depends on your point of view (and which side of the vendor relationship you sit).
So I cam up with a patch that updates the logic to work off of ID_KEY. The patch file that generated the final file is on wort int eh KitsNet repo, along with the resulting file with the name veeamsnap-loader.distro_family To deploy across KitsNet, use the following sequence:
cd /usr/sbin
ls -al veeamsnap*
mv veeamsnap-loader veeamsnap-loader.AS_SHIPPED
wget http://wort/KitsNet/veeamsnap-loader.distro_family -O veeamsnap-loader
chmod u+x veeamsnap-loader
After running a backup test, it should be possible to revert the default boot selection in grub
