Veeam Agent for Linux in v13: Managed Deployment and Server Hardening
What this covers
Veeam Agent for Linux covers physical servers, bare-metal machines, cloud instances, and VMs that are not backed up at the hypervisor level. If you are running Linux on hardware where a hypervisor-level backup is not possible or not practical, this is the tool. This guide covers the managed deployment path, meaning Veeam Backup and Replication pushes and controls the agent from a central console. It also covers the hardening steps you should apply to the protected Linux server itself before the agent runs its first job.
Standalone agent deployments, where the agent runs without any VBR connection, are a separate use case. The managed path described here gives you centralized visibility, job scheduling from the VBR console, and the ability to target a Veeam backup repository or a Hardened Repository for immutable storage.
Managed vs. standalone deployment
When you deploy Veeam Agent for Linux through VBR, Veeam manages the agent's lifecycle including installation, upgrades, and job configuration. Jobs run on schedules you define in the VBR console and backup results land in a repository you control from the same place. The Linux server running the agent is added to a protection group and can be rescanned automatically to pick up new machines as your environment grows.
The standalone path installs the agent directly on the Linux machine and manages it locally through the Veeam Agent CLI or its own local UI. Standalone agents can target Veeam Cloud Connect repositories or local storage, but they do not appear in your central VBR infrastructure view. For environments with more than a handful of Linux machines, the managed path is worth the setup time.
Veeam Agent for Linux comes in two variants: the standard kernel module version and the Nosnap version. The Nosnap variant is for environments where loading kernel modules is restricted, such as certain hardened or containerized Linux deployments. Check your kernel policy before deciding which version to deploy. The standard version is appropriate for most physical and virtual Linux servers.
Creating a protection group in VBR
Protection groups are how VBR organizes machines for agent-based backup. Before you can deploy an agent to a Linux server, you need a protection group that includes it.
Open the Physical Infrastructure section
In the VBR console, go to the Inventory view. You will see a Physical Infrastructure section in the left pane. Right-click Protection Groups and select Add Protection Group.
Choose the group type
For manually managed Linux servers, choose Individual computers. If you want VBR to automatically discover machines in an IP range or pull from Active Directory, those options are available here but require additional access configuration. Individual computers is the most straightforward starting point.
Add the Linux machines
Click Add, enter the FQDN or IP address of the Linux server, and select or create SSH credentials for it. VBR needs an account that can either run commands as root or has the necessary sudo permissions for Veeam operations. The credentials are used once during deployment and are not stored in the agent configuration after that. Click OK and add as many machines as needed.
Configure automatic deployment
On the Options page of the wizard, decide whether VBR should automatically install the agent during rescan. Enable this if you want a fully automated push deployment. Leave it off if you prefer to trigger installation manually after reviewing the target machine. Set the rescan schedule to something sensible, daily or every few hours, so new machines added to the group are picked up promptly.
Deploying the agent from VBR
Once the protection group is saved, VBR performs a rescan. During rescan, it checks connectivity, validates SSH credentials, and installs the agent on any machines where automatic deployment is enabled and the agent is not yet present. You can trigger a manual rescan at any time by right-clicking the protection group and selecting Rescan.
If automatic deployment is disabled, right-click the target machine in the protection group and select Install Agent. VBR generates the agent setup files appropriate for the machine's distribution and architecture, transfers them over SSH, and runs the installer. The whole process takes about a minute on a machine with a package manager and internet access. Air-gapped machines need the setup files pre-staged, which VBR supports through the manual pre-installation path.
Veeam Agent for Linux in the managed mode supports a broad range of 64-bit distributions. The current v13-compatible list includes: RHEL 6, 7, 8, and 9; CentOS 7 and CentOS Stream 8/9; Rocky Linux 8 and 9; AlmaLinux 8 and 9; Oracle Linux 7, 8, and 9 (RHCK and UEK); Debian 10, 11, and 12; Ubuntu 18.04, 20.04, and 22.04; SLES 12 SP4+ and SLES 15; and openSUSE Leap 15. Oracle Linux with UEK kernels is supported but check the compatibility matrix — specific UEK versions have kernel version constraints. Always verify the full matrix at helpcenter.veeam.com before deploying to anything unusual, as new GA releases of supported distros may require a Veeam patch to support.
When VBR deploys the agent automatically via push, it uses the distribution's native package manager. For RHEL, Rocky, AlmaLinux, and Oracle Linux this is dnf or yum. For Debian and Ubuntu this is apt. For SLES and openSUSE this is zypper. If the Veeam software repository is not already configured on the target machine, VBR adds it during the push deployment. For air-gapped machines, download the packages from repo.veeam.com and pre-stage them before triggering installation.
For RHEL-family distributions that require DKMS to build the kernel module, the dkms package must be available. On RHEL, Rocky Linux, and AlmaLinux the dkms package comes from the EPEL repository, not the base OS repos. Either pre-install EPEL or use Veeam's pre-built binary kernel module packages instead, which bypass the DKMS requirement entirely on supported kernel versions.
Per-distro install command sets
When push deployment from VBR is not an option, install the agent manually. The steps below cover the most common distributions. All commands run as root or via sudo. The Veeam repository must be added first on each machine before installing packages.
RPM-based with dnf (RHEL 8/9, Rocky 8/9, AlmaLinux 8/9, OL 8/9)
Add the Veeam repository and install. The epel-release package is needed for DKMS if you are not using Veeam pre-built binary packages:
rpm --import https://www.veeam.com/downloads/v/veeam_public.gpg.key
curl -o /etc/yum.repos.d/veeam.repo https://repository.veeam.com/backup/linux/agent/rpm/el/veeam.repo
dnf install epel-release -y
dnf install veeam -y
On Oracle Linux with UEK, also install the matching kernel-uek-devel package if DKMS compilation is needed: dnf install kernel-uek-devel-$(uname -r) -y
RPM-based with yum (RHEL 7, CentOS 7)
rpm --import https://www.veeam.com/downloads/v/veeam_public.gpg.key
curl -o /etc/yum.repos.d/veeam.repo https://repository.veeam.com/backup/linux/agent/rpm/el/veeam.repo
yum install epel-release -y
yum install veeam -y
Debian-based with apt (Ubuntu 20.04 LTS, 22.04 LTS)
curl -O https://repository.veeam.com/apt/conf/veeam-release
dpkg -i veeam-release
apt-get update
apt-get install veeam -y
On Ubuntu you may need linux-headers-$(uname -r) for DKMS to build the kernel module. If it is missing: apt-get install linux-headers-$(uname -r) -y
Debian-based with apt (Debian 10 Buster, 11 Bullseye, 12 Bookworm)
curl -O https://repository.veeam.com/apt/conf/veeam-release
dpkg -i veeam-release
apt-get update
apt-get install veeam -y
Debian may also require linux-headers-$(uname -r): apt-get install linux-headers-$(uname -r) -y
SUSE-based with zypper (SLES 12 SP4+, SLES 15, openSUSE Leap 15)
rpm --import https://www.veeam.com/downloads/v/veeam_public.gpg.key
zypper addrepo https://repository.veeam.com/backup/linux/agent/rpm/sles/veeam.repo
zypper refresh
zypper install veeam
On SLES, kernel-default-devel matching your running kernel is required for DKMS. Install it before running the Veeam installer: zypper install kernel-default-devel
After any manual installation, run veeamconfig --version to confirm the installed version and veeamconfig mode show to confirm the agent is in managed mode if you intend for VBR to control it. A standalone-mode agent will not appear in VBR's protection group inventory until it re-registers.
Creating the agent backup job
Create a new Agent Backup job
From the Home view, right-click Jobs, select Backup, and choose Linux computer. Give the job a name. On the Computers step, click Add, navigate to the protection group you created, and add the machines you want this job to cover. You can mix machines from multiple protection groups into a single job.
Choose the backup mode
Select between Entire computer, Volume-level backup, or File-level backup. Entire computer creates a full image backup of all attached volumes and is the right choice for bare-metal recovery scenarios. Volume-level lets you choose specific volumes, useful if a server has separate data volumes you do not need to back up. File-level is for granular file and folder protection and is not suitable for bare-metal recovery.
Set the destination repository
Select the VBR-managed backup repository where backups should be stored. If you have a Hardened Repository configured, targeting it here gives you immutable backups for these Linux machines automatically. Set retention to a restore point count that fits your RPO and storage budget. Enable active full or synthetic full on a weekly cadence.
Configure pre and post job scripts
If the Linux server runs databases, message queues, or other stateful applications, configure pre-job scripts to flush application state before the snapshot is taken. VBR will run the script on the protected machine over SSH before initiating the backup snapshot. Post-job scripts can restart services or run cleanup steps after the backup completes.
Set the schedule and finish
Set a daily or more frequent backup window. Agent backups of Linux servers are relatively lightweight after the first full, so running them multiple times a day for critical machines is practical. Enable email notifications so failures reach you promptly.
Hardening the Linux server being protected
The agent protects data on the Linux server, but the server itself also needs to be a difficult target. These are the steps worth taking on any Linux machine that holds data important enough to back up.
Lock down SSH access
Disable root login over SSH by setting PermitRootLogin no in /etc/ssh/sshd_config. Use key-based authentication and disable password authentication with PasswordAuthentication no. Restrict SSH to specific management IP ranges using firewall rules rather than relying on AllowUsers or AllowHosts directives alone. Restart the SSH daemon after any config change to apply it.
Limit sudo permissions
VBR does not require the Veeam service account to have full sudo access. Veeam documents the specific granular sudo permissions needed for the agent to operate. Create a dedicated sudoers entry that grants only those permissions rather than granting unrestricted sudo. This limits blast radius if the Veeam credentials are ever compromised.
Restrict inbound network access
Use iptables, nftables, or firewalld to allow inbound SSH only from known management IP addresses. VBR communicates with the agent over TCP 6160 (Veeam Installer Service), TCP 6162 (Veeam Data Mover Service), and TCP 2500 to 3300 (data transfer channels). Open those ports only to your VBR server address. Block everything else inbound by default.
Keep the OS and agent current
Enable automatic security updates where your change management policy allows it. Kernel exploits and privilege escalation vulnerabilities are the most common path an attacker uses to reach backup data on a protected host. Keeping the kernel patched closes those doors. For the Veeam agent itself, VBR handles updates automatically during rescan when agent auto-upgrade is enabled in the protection group settings.
Veeam Agent for Linux must not be installed on a machine that is also serving as a Hardened Repository. The agent and the repository isolation model are incompatible and the combination is explicitly unsupported. Keep these roles on separate machines.
Restoring files and volumes
For file-level restore from an agent backup, right-click the backup in the VBR console, select Restore guest files, and choose Linux. Veeam mounts the backup on the mount server and opens a file browser where you can select and restore individual files. Files are restored directly to the original path or to an alternate location you specify.
For volume-level or full machine restore, you have two main options. Instant VM Recovery mounts the backup image and registers it as a VM on a connected hypervisor, so the machine can boot immediately from backup storage while the data migrates to permanent storage. Bare-metal recovery uses a Veeam Recovery Media ISO booted on the physical target machine to restore the full image directly to disk. Both paths are initiated from the VBR console or, for bare metal, from the recovery boot environment.
Monitoring and alerts
Agent backup jobs report session results to the VBR console the same way VM backup jobs do. Go to Home and look at the Last 24 Hours section to see all job sessions including agent jobs. Failures and warnings appear here first. Set up email notifications under Veeam settings with your SMTP details and enable per-job notifications in each job's settings so failures generate an alert immediately rather than being discovered during the next manual review.
If you have Veeam ONE in the environment, it provides deeper reporting and trend analysis for agent-based backups including capacity forecasting for the repositories those agents write to.
- Protection group covering target Linux servers in VBR
- Managed Veeam Agent for Linux deployed via push from VBR
- Agent backup job targeting a VBR-managed repository
- SSH hardened, sudo-restricted, firewall-locked Linux server
- File and volume restore paths tested and understood
Linux server backup gets overlooked more than it should. Hypervisor admins tend to assume the hypervisor-level backup covers everything, and then someone provisions a bare-metal database server or a cloud instance and it falls through the gap. The managed agent deployment in VBR makes it easy to close those gaps from the same console you use to manage everything else. The hardening steps add maybe an hour of work per server and significantly raise the cost for an attacker trying to reach backup data through a compromised application.